6/17/2013 1:14:32 PM
Topic:
Reports
 Joshua C Administrator Posts: 78
|
Hi Peter,
Sorry to hear that you are having trouble. When a users Secret Server contains more than 30 active users Secret Server switches from a drop-down selection to a search bar with auto-fill. This is down so that administrators do not have to go through long scroll boxes. To use the search box begin by typing the name of the user (both the short and long user name works) highlight the desired name and hit Enter to add/select the user. If you are still having troubles please give us a call at 202-233-6680 We are open 9:00AM-5:30PM EST Monday-Friday and I would be glad to assist you.
Kind Regards, Joshua Conroy
|
|
|
6/17/2013 1:10:15 PM
Topic:
Desktop Client
 Joshua C Administrator Posts: 78
|
Hi Peter,
The Secrets are encrypted and cached on the device(computer or mobile device) and will stay there till cache is cleared whether that is done manually or by a built in timer that can be set within Secret Server. The Desktop Client and Mobile Apps are good solutions should your Secret Server become inaccessible.
Kind Regards, Joshua Conroy
|
|
|
6/17/2013 9:40:01 AM
Topic:
Desktop Client
 Peter C Posts: 34
|
Hi Joshua, Yes it's working now! Reading and understanding the help really .... well helps ;-) Thank you!
Just another question: where and how are the secrets cached?
My boss wants to have offline access to all secrets in case the network ans storage are completely down. Is the Desktop client a useful solution for this requirement?
Thanks, Peter
|
|
|
6/17/2013 9:32:39 AM
Topic:
Desktop Client
 Joshua C Administrator Posts: 78
|
Good Morning Peter, Just checking with you, using the correct URL were you able to use the Desktop Client?
Kind Regards, Joshua Conroy
|
|
|
6/17/2013 7:57:02 AM
Topic:
Reports
 Peter C Posts: 34
|
Hi,
When i try the Report "What Secrets can a user see?" or "What Secrets have been accessed by a user?" i cannot change the User! First of all the user string is in an unusable format "Domain\Full User Name (User)" it should be "Domain\User" (User = Short user name). Then it always inserts the current user, which is not the most needed usecase ;-)
I would like to select a user, not enter it manually.
I would like to have reports that show:
- Permissions and Template for a a specific Secret (i don't have access to).
- Secrets a specific User can view.
- Secrets a specific User has created.
- Activity in a specific Folder (who created which secrets with template and permission)
Thanks Peter
|
|
|
6/17/2013 6:18:31 AM
Topic:
Desktop Client
 Peter C Posts: 34
|
Hi, SORRY, IGNORE the following text, i found the correct URL!
I have a need for the Desktop client, but i get an Error when i try to login. Version 1.1.1 I tried bot urls (https://..../winauthwebservices/SSWinAuthWebService.asmx and webservices/SSWebservice.asmx) Powershell and Remote Desktop Manager access work. Please see attached Screenshot.

Thanks! Peter
|
|
|
6/13/2013 4:13:46 PM
Topic:
Web Password Filler - Not configured message
 Jessica M Posts: 6
|
Hi Michael,
Each Secret that is used by the Web Password Filler must have the required fields mapped before it is considered "configured" for this purpose. Because a user must be an Owner of the Secret to configure the Web Password Filler mappings, this must be done for a Secret before non-Owners may use it in this way.
If you have any further questions, please note that you may submit a ticket at any time by going to support.thycotic.com.
Thanks! Jessica
|
|
|
6/13/2013 2:36:02 PM
Topic:
Web Password Filler - Not configured message
 Michael H Posts: 1
|
Hello! We just upgraded our Secret Server installation in order to use the Password Filler feature, but have run into an issue. The way our secrets are setup, the admin account is the owner of all the secrets and users are just giving view/edit permissions.
If a user tries to go to a login page and clicks the password filler link, a window pops up with all the logins related to that site. So far so good. However if they try to select a login on that window, an error message pops up "This secret is not configured. Please contact the secret owner."
Through testing I have discovered that if I login with the admin (secret owner) account, go to the login page and use the password filler then the users are then given the option to use that login from the password filler.
We have a few thousand passwords stored, is there a way to avoid having to use every login from the admin account first before the password filler will work for the users?
|
|
|
6/12/2013 3:07:39 PM
Topic:
Currently possible or feature request?
 Jessica M Posts: 6
|
Hi Erich,
Thanks for the post. Secret Server does allow you to use one Secret Launcher for multiple servers, however it will only provide Remote Password Changing and Heartbeat capabilities for the server primarily listed on the Secret. We recently posted an article in our blog that provides more detailed information on this capability:
http://blog.thycotic.com/2013/05/03/restricting-user-input-for-launcher/
As best practice, we encourage using unique local account passwords rather than universally identical local accounts. This brings us to your second question:
Secret Server Enterprise Plus edition provides a feature called Discovery Rules. This allows you to create rules that can be applied to Local and/or Domain accounts. Configuration of each Rule allows you to specify criteria for importing the account information such as domain, computer name and account name. You may also specify how the information will be formatted within Secret Server by declaring a Secret Type, Folder destination, Secret Name, and Secret permissions. Lastly, you are given the option to change the password to a predetermined or randomly generated new password as the information is imported.
If you have any further questions, please feel free to submit a web ticket at support.thycotic.com.
Thanks! Jessica
|
|
|
6/12/2013 2:01:15 PM
Topic:
Currently possible or feature request?
 Erich B Posts: 3
|
Hello,
I have a couple of items that came up in our discussions. Was wondering if Secret Server has these very particular features. - Is it possible to have one secret for multiple servers? For example, a local admin account for many servers, all in one secret. - Is there a way to automatically create a secret for a newly discovered account, either local or domain? Maybe a conditional rule for "all local accounts in server that are added to something OU auto-get this custom created secret". Make sense?
These things aren't a priority for us, but still interested in the possibilities.
|
|
|
6/11/2013 2:11:08 AM
Topic:
API Code Examples
 Christopher B Posts: 1
|
Hey Frank
I made this a couple of days ago, maybe you'll find it useful, it's based off of the example here on Thycotics site.
function GetFieldId($template, [string]$name) { Return ($template.Fields | Where {$_.DisplayName -eq $name}).Id }
function CreateNewSecret { param($accountUserName, $accountPassword) #fill in username, password, and baseUrl for your Secret Server. $username = 'SS_Account' $password = 'SS_Account_Password' $domain = 'yourDomain' $baseUrl = 'https://yoursecretserver.com' $url = $baseUrl + '/SecretServer/webservices/SSWebService.asmx' $proxy = New-WebServiceProxy -uri $url -UseDefaultCredential $tokenResult = $proxy.Authenticate($username, $password, '', $domain) if($tokenResult.Errors.Count -gt 0) { $msg = "Authentication Error: " + $tokenResult.Errors[0] echo $msg Return } $token = $tokenResult.Token $templateName = "yourTemplateName" $template = $proxy.GetSecretTemplates($token).SecretTemplates | Where {$_.Name -eq $templateName} if($template.id -eq $null) { $msg = "Error: Unable to find Secret Templete " + $templateName echo $msg Return } $domain = "yourDomain" if( $accountUserName -eq $null) { $accountUserName = "New User" } $msg = "Creating Account: " + $domain + "\" + $accountUserName; echo $msg #If no password is set, it will generate a new password if($accountPassword.length -lt 1) { #echo "Generating New Password for account" $secretFieldIdForPassword = (GetFieldId $template "Password") $accountPassword = $proxy.GeneratePassword($token, $secretFieldIdForPassword).GeneratedPassword } $secretName = $domain + "\" + $accountUserName $secretItemFields = ((GetFieldId $template "Username"), (GetFieldId $template "Password"), (GetFieldId $template "Notes")) $secretItemValues=($accountUserName,$accountPassword, "")
$folderName = 'yourSecretsFolder' $folderObject = $proxy.SearchFolders($token,$folderName) $folderId = $folderObject.Folders | Foreach-Object {$_.Id}
$addResult = $proxy.AddSecret($token, $template.Id, $secretName, $secretItemFields, $secretItemValues, $folderId) if($addResult.Errors.Count -gt 0) { $msg = "Add Secret Error: " + $addResult.Errors[0] echo $msg Return } else { $msg = "Succesfully added Secret: " + $addResult.Secret.Name + " (Secret Id:" + $addResult.Secret.Id + ")" echo $msg Return }
}
$newSecretName = 'test3' $newSecretPassword = '12345678' CreateNewSecret $newSecretName $newSecretPassword
|
|
|
6/6/2013 1:53:01 PM
Topic:
Feature Request: Secret Sharing Steps
 Kevin Administrator Posts: 223
|
Hi Ralph,
I am not aware of any behavior changes around that particular functionality. I am going to create a support ticket for you so that we can investigate this problem with you. A support engineer will be in contact soon.
Thanks!
|
|
|
6/6/2013 12:31:27 PM
Topic:
Feature Request: Secret Sharing Steps
 Ralph A Posts: 2
|
Since a recent upgrade, we noticed that the sharing process seems to have changed. We have several users who claim that they shared a secret, but it's not shared, and it's increasing out support calls. We noticed that there appears to be an extra step in the process that's not intuitive.
You have to add the user or group and then click 'Add user or Group' again for them to populate in the grid. We found that our users are clicking 'Save' and there is no change to the sharing. Is there any way the user could be warned when clicking 'Save' that they are not finished, or have the user or group automatically add to the grid when they click the name from the drop down?
|
|
|
6/4/2013 4:22:45 PM
Topic:
Feature Requests: Add user to secret
 Kevin Administrator Posts: 223
|
Hi Joel,
This is an interesting idea, thanks for the feature request. I've entered your feature request into our tracking system for review by our product owner.
Thanks!
|
|
|
6/4/2013 3:29:11 PM
Topic:
Feature Requests: Add user to secret
 Joel S Posts: 2
|
We utilize SS in such a way that sometimes we give access to certain secrets for a specific reason. While I can view reports about when access was granted or removed, there is no audit trail as to why I added the user at that time.
To be able to make a note when adjusting a permission on a secret would be helpful.
|
|
|
6/4/2013 10:10:14 AM
Topic:
Feature Request: Personal Secret Defaults
 Kevin Administrator Posts: 223
|
Hi Peter,
Great! I've captured a feature request. We'll reach out to you when we have a better idea of where this feature request fits in our timeline.
Thanks, Kevin
|
|
|
6/4/2013 4:34:14 AM
Topic:
Feature Request: Personal Secret Defaults
 Peter C Posts: 34
|
Hi Kevin, Exactly! Your summarized perfectly what i wanted to explain with my feature Request!
An override of the default behaviour (from the global option) at the folder level would be great.
Thanks, Peter
|
|
|
6/3/2013 11:58:18 AM
Topic:
Feature Request: Personal Secret Defaults
 Kevin Administrator Posts: 223
|
Hi Peter,
I think I understand what you are asking for, please let me re-iterate it to make sure I understand what you are looking for.
Currently, in configuration your "Default Secret Permissions" are set to "Secrets inherit permissions from folder" because, in most circumstances, this is the desired behavior.
However, for your "Personal" folder, this behavior is not desirable. Users are having to modify the permissions every time they create a Secret to not inherit from the folder and to explicitly give themselves the only access.
A potential work around would be to have an Administrator create a folder for each user that only the user has access to. So the structure would be something like Root > Personal > UserName. Users would only have access to their folder, so they would only ever see their personal folder.
I realize this could be a tall task for a large number of users, so I think what we want is to improve that "Default Secret Permissions" to actually be specified at the folder level, not a global option. That way when users save Secrets into that folder, it does not inherit permissions from it - by default.
Does that seem like a reasonable way to improve things for you?
Thanks!
|
|
|
6/3/2013 8:06:57 AM
Topic:
Feature Request: Personal Secret Defaults
 Peter C Posts: 34
|
Hi Jessica, Unfortunately not, since we usually want the inheritation as default except for this one folder. If i could set this in folder level we would be happy. Thanks, Peter
|
|
|
5/28/2013 9:42:34 PM
Topic:
Password Reset Server 2.3.000000 Released
 Ben Posts: 95
|
Release notes: http://www.thycotic.com/products_passwordresetserver_releasenotes.html
How to Upgrade Password Reset Server: http://support.thycotic.com/KB/a123/upgrading-password-reset-server.aspx
|
|
|