Lots of companies use secret server, including us.
Would be good if we could use those secrets in royal server documents locked down so users can't see them.
Then we can have one place to manage passwords.
We investigated Secret Server and their API. Unfortunately there's no fast way to gather all credentials (including passwords) to generate a intermediate document with credentials (like we do in LastPass or KeePass). We provided feedback to Thycotic and asked them to implement the necessary API (changes). Their competitor PasswordState, for example, has an API for this and we will look into their product as well. When Thycotic offers such an API, we can further investigate the integration with Royal TS.
Any development / update on this?
as mentioned in my previous comment, it's up to Thycotic to provide better APIs which allows us to integrate it into Royal TS. So far, we haven't heard anything from them and doubt that there will be any improvement soon. I'm sorry I have no better news for you.
Interesting, as other competitors have been able to integrate okay with the Thycotic. I assume you guys are in contact with them. Reason is we're looking for a proper remote management solution in the next financial year (Australia) - it would be nice if you guys support it.
I found this on their website, https://thycotic.com/products/secret-server/features/api-web-services/
Looks like they might have made an API available in late January?
Not sure if thats helpful or not.
I know that other products have successfully integrated Thycotic. In our case it's a bit different because our current architecture does not allow us to do the same. If you look at our lastpass integration, for example, all credentials will be pulled into a temporary dynamic document and our connections will use those credentials just like any other credential from your documents.
We are facing two issues with Thycotic:
1. They are using numbers as IDs, not GUIDs. To make this work in Royal TS we have to massively re-architect many of our core components.
2. Their API does not allow us to pull in all credentials to this temporary document. With their API it will take minutes to get this into the temporary document.
Since resolving the above two issues is a huge effort, we will not be able to implement such a support soon. I'm sorry I have no better news for you.
Unfortunately this doesn't solve the main issue. The way their data is structured requires us to do at least one or two subsequent calls for each entry. This makes the whole process very slow.
Is this also the case for the API of Password Manager Pro (by ManageEngine) or could this be implemented as a password source?
I suggest you create a dedicated entry for Password Manager Pro. If possible with the link to the API documentation. Let's keep this thread dedicated to Thycotic Secret Server.
I'm Thycotic Engineer, and I'm actually interested in knowing who you've talked to at Thycotic regarding that?
We had contact with Trevor Sieburgh, Ben Yoder and Kaitlin Moran.
I understand your issues with Thycotic integration in the above thread, but I wanted to put our customer view from a security perspective.
We keep all secrets in a fully audited vault which includes logs of who accessed which secrets and when. In your architecture our audit logs would be horribly polluted every time a RoyalTS instance was launched, as the process of grabbing all credentials into a temporary document would trigger an entry for each credential.
We prefer an integration where RoyalTS is configured with the credential ID in a document, and a reference to an external system or API where the credential itself can be retrieved only when it is actually needed.
This also addresses the issue of credentials becoming stale in the temporary document - people who rely on RoyalTS will usually leave the app open for days (weeks?) and it's quite likely that on any particular day some credentials would be changed. Users shouldn't have to restart the application or refresh the document to get the new credential from Thycotic before they can log in.
Lastly, having cached credentials in a temporary document has a security weakness as it does not reflect changes in access permissions. If we remove a user's permission to a particular credential in Thycotic they should no longer be able to use that credential - if it's cached in the RoyalTS temporary document they can still use it until the document is refreshed.
I hope these examples make sense to you, and I understand they probably don't fit with your current architecture for RoyalTS but I thought it would be helpful to describe them to you.
I fully support Matthew's philosophy on how Royal should handle any integration. I use RoyalTSX and Thycotic on a daily basis, and love the benefits that each provide. I completely agree that any static sync that pulls in all credentials to a temporary document would be against the privilege control model that everyone should be adopting.
I would love to see integration between Royal and Thycotic, and I hope you all can work through the kinks as any integration would provide TREMENDOUS value to both customer bases.
I look forward to seeing a working relationship between the two companies that benefits their customers.