Thycotic Community - Secret Server - Server Admin Passwords - Messages

Message from Michael B

Tue, 09 Feb 2010 14:44:34 GMT

Looking forward to version 7.0

Do you have an expected release date?

The Remote Password Changing Add-On is not going to help us initially where our large server fleet has about 5 well know local admin passwords.

Writing the powershell script will help us add our entire server fleet to Secret Server, and the slightly adapted version will help us ensure that all future servers are added.

Password changing for the local admin on each server is not a huge issue, because they will be set to strong 25 charater passwords. This will certainly encourage our admins to use their OWN credentials, which fixes our audit trail too. The aim is to never need these passwords. If the password is never viewed, I see little point in resetting it.

I love the idea of the Remote Password Change, but in my case its not the right piece to the puzzle.

Message from Jonathan

Tue, 09 Feb 2010 08:38:47 GMT

Folder support in web services will be coming in 7.0 (it is needed to add folder functionality to the iPhone app).

Michael - this problem can be solved using our Remote Password Changing Add-On. You could have the local admin account in Secret Server on an expiration schedule (or force expire when someone leaves) - Secret Server will then reach out to the box and change the password. Besides Windows accounts - we also support changing passwords on AD, Oracle, SQL Server and UNIX/Linux. (Coming soon Sybase and MySQL)

Message from Jeremy A

Tue, 09 Feb 2010 05:17:14 GMT

Have you considered using group policy to set the Local Administrator password?

That way, when a staff member leaves, you just update the single group policy object with a new updated password, and then record that in SS.

Message from Kevin

Mon, 08 Feb 2010 23:24:18 GMT

Hi Michael,

I'm sorry to say that as of the latest version of Secret Server (6.2.000013) - the webservice API does not allow specifying or updating a folder, and nor is there an API for modifying the permissions directly.

I'd send an email to the support team (support [at] thycotic [dot] com) and request it as a feature for a future release.

Message from Michael B

Mon, 08 Feb 2010 23:20:22 GMT

Almost there, I now have the things adding.

But they are not being added to a folder, and therefore are not inheriting permissions and cannot be searched for !?

Any ideas on where you get to specify the folder?

amazing how similar the script looks!

Message from Kevin

Mon, 08 Feb 2010 23:13:42 GMT

And additionally, here is a script for updating an existing secret:

#Helper Function
function SetField($secret, [string]$fieldName, [string]$newValue)
{
($secret.Items | Where {$_.FieldName -eq $fieldName}) | ForEach-Object {$_.Value = $newValue}
}

#The URI of the webservice
$URI = "https://my/secret/webservice/sswebservice.asmx"

#The name of the secret we want to update
$secretName = "My New Combination Lock"

$ss = New-WebServiceProxy -UseDefaultCredential -uri $URI

#Set the correct username and password. It's recommended to use an empty string rather than "Local" for domain
#If you are not using a domain account
$token = $ss.Authenticate("username", "password", "", "")

#Get the secret we are going to update
$existingSecretId = ($ss.SearchSecrets($token.Token, $secretName).SecretSummaries | Where {$_.SecretName -eq $secretName}).SecretId
$existingSecret = $ss.GetSecret($token.Token, $existingSecretId).Secret

#Use the SetField function to set some fields
$existingSecret.Name = "My Not-So-New Combination"
SetField $existingSecret "Combination" "56789"
SetField $existingSecret "Notes" "Updated with new combination."

$ss.UpdateSecret($token.Token, $existingSecret)

Message from Kevin

Mon, 08 Feb 2010 22:26:06 GMT

Hi Micheal,

That error occurs when you don't specify *all* of the fields that are in the secret template. From your example, you are sending 3 fields and 3 values. It should be the same as the template.

Also, this error can occur when you specify a field ID that isn't a field ID that belongs to that template.

For what it's worth, here is one I wrote a while back - not so different from yours.

#Helper Function
function FieldId($template, [string]$name)
{
Return ($template.Fields | Where {$_.DisplayName -eq $name}).Id
}

#The URI of the webservice
$URI = "https://my/secret/webservice/sswebservice.asmx"

#The name of the secret template we are going to use.
$templateName = "Combination Lock"

$ss = New-WebServiceProxy -UseDefaultCredential -uri $URI

#Set the correct username and password. It's recommended to use an empty string rather than "Local" for domain
$token = $ss.Authenticate("username", "password", "", "")

if ($token.Errors.Length -gt 0)
{
echo $token.Errors
Return
}

#Get the template for the secret we are adding
$template = $ss.GetSecretTemplates($token.Token).SecretTemplates | Where {$_.Name -eq $templateName}
if ($template.Errors.Length -gt 0)
{
echo $template.Errors
}

#Build an array of field ID's from the template. Call the Helper function
#To get the ID of the field. Add and change fields as required by the template
#You will be using
$fields = ((FieldId $template "Combination"), (FieldId $template "Notes"))

#Build and array of the values of the field. They must be in the same order as
#the fields in the $fields value.
$fieldValues = ("1234", "Add some more notes here.")

$result = $ss.AddSecret($token.Token, $template.Id, "My New Combination Lock", $fields, $fieldValues)
echo $result.Errors

Message from Michael B

Mon, 08 Feb 2010 21:13:23 GMT

I have hit a snag with using the webservice:

Here is my powershell script:

$URI = "https://secretserver.mycompany.local/webservices/sswebservice.asmx?WSDL"
$ss = New-WebServiceProxy -UseDefaultCredential -uri $URI

$auth = $ss.Authenticate("serviceadd", "Password123","","Local")

#show the token number
#$auth.token

#set the values up
$secretName = "secretblah.mycompany.local"
$secretTypeId = [int] 6010
$secretFieldIds=10,11,12
$secretItemValues="secretblah","admin","pwgoeshere"

$ss.AddSecret($auth.token, $secretTypeId, $secretName, $secretFieldIDs, $secretItemValues)

This is the error:
Errors Secret
------ ------
{Secret Template is out of date.}

Message from Michael B

Mon, 08 Feb 2010 17:29:42 GMT

I would like to request some help in writing a powershell script, I think that it would be very useful for others.

Scenario:
A server is built by an automated process, during the build the "Administrator" password for the server is set to a generic vaule.

Issue:
Staff leave the organisation and take the password with them, staff choose to use the local administrator password instead of their domain credentials.

Fix:
Have each server run a powershell script. This script will run in the context of a domain account. The domain account will have write access to secret server.

The script will:
Generate a password
Reset the Local Administrator password
Submit the password to Secret Server to be stored later.

Admins will find their own way to incorporate the script into their environment, as each orgs build process is unique.

What I need help with:
Submitting details to secret server via powershell