Thycotic Community Forum

10/16/2012 12:21:12 PM Christoph H Posts: 3	Hello Are there any best practises or templates how to setup a folder structure for secrets as well as groups for persmissions to that folder? Example: I am sure everywhere is a Helpdesk,groups of Networkers, Microsoft and Linux admins, Database admins, web admins, security guys, etc. Schould folders be named by e.g. geolocation, with sub structures such as application, DB, OS, Network, etc. and then assigne AD groups of the networkers, the helpdesk people, DB admins etc, to it? Or are there other ideas? How is this structure undermined by access requests to secrets of users? Can that password requesting mechanism be deactivated? Thanks Christoph
	0 • link
10/16/2012 6:45:22 PM Jonathan Administrator Posts: 591	Christoph, You should read the Secret Server Best Practices Guide. It is available on the Support page: http://www.thycotic.com/products_secretserver_support.html It discusses roles, folders, permissions and lots more. Just get in touch with your Account Manager (Sierra) if you need free trial licenses so you can access these documents. Best. -- Secret Server 8.1 - Web Password Filler, SAP support, advanced discovery capabilities with rules. Need a free trial license?  Send an email to sales@thycotic.com
	0 • link
10/17/2012 8:26:44 AM Nick S Posts: 25	I learned a lot from a discussion with Nick Duda on this forum Christoph. http://www.thycotic.com/products_secretserver_forums.html I went with a structure that did not factor in much organizational structure. Instead I provided folders that allowed users to organize their secrets into bucks (AD accounts, test accounts, SQL accounts, etc.). Disabling inheritance and putting the permissions on THE SECRET instead of THE FOLDER made a lot of sense. Even within an individual group there are often secrets which only like 2 of the 6 guys need to know. This is much more common than a secret that all 6 guys need to know.
	0 • link
10/17/2012 12:56:59 PM Christoph H Posts: 3	Hello Nick Thanks a lot for your reply I´ve just gone thru your conversation with Nick Duda and it sounds very interesting. I have to think about it, but it sounds practical and tackling exect the issues you run in with inheritance on folders... One question is left. Is there a single secret owner existing? Or once the creator has given permissions to others, they can grant further permissions to others again, such as a "snowball effect"?. And with other words: Can Secret Server audit trail who has given permissions to whom and when? Thanks again very much for your reply! ...and excuse my bad Englich (as a German)
	0 • link
10/17/2012 1:06:31 PM Nick D Posts: 58	Glad you found that thread helpful. As far as the owner, yes there is a snowball effect. If you are an owner of a secret you can give ownership rights to someone else. We had a scenario where we didnt want to do this for a very important process at my company. Basically, all secrets require an owner. No way around it. We have an internal application for our ecommerce site that requires key rotation. This key is simply a password. We had a requirement that no one ever know this key/password. So we developed an internal tool (although there are many free ones available) that would take 2 strings of text, combine them, and generate another string of text (hash). This final hash becomes the password for this internal eCommerce tool. What we did was create 2 secrets in Secret Server. For simplicity lets call it "Super Secret #1" and "Super Secret #2". We gave 3 unique employees access to #1 and 3 other employees access to #2 (View/Read). Under no circumstance are the employees with access to #1 allowed to view #2 and vice versa. Since secrets require an owner, what we did was make a local user in secret server called "Phantom Owner". The password for phantom owner is unknown, as we just smashed all the button on the keyboard during creation. We then added the "Phantom Owner" to each of the secrets #1 and #2. Since no one knows the password to Phantom owner, no one can log in as that user to change the permissions on the secret. The only way to address this is by going into Unlimited Admin mode, which we built a very strong process around doing (internal process as well as roles, auditing, event subscriptions...etc). This was a huge success for a major internal process we have. have fun!
	+1 • link
10/17/2012 1:07:58 PM Nick D Posts: 58	I also forgot to answer your question on auditing. Yes, Secret Server audits EVERYTHING. Getting the audit trail on who has given permissions to whom and when is super trivial.
	0 • link
10/17/2012 3:08:13 PM Nick S Posts: 25	Your English is great Christopher! The way we set it up is that the creator of the secret is the only owner until that person decides to share it with someone else. We explain in training the difference between granting someone "edit" versus "owner" permissions. Also some other features can help prevent the "snowball effect" a bit. For passwords you really need to keep secure consider activating the DoubleLock capabilities. Even if someone mistakenly shared a password with DoubleLock activated with a person they shouldn't have, they can't view it without the additional information. Consider it like 2-factor authentication for your secrets. http://www.thycotic.com/products_secretserver_doublelock.html
	0 • link

---