Thycotic Community Forum

8/24/2012 9:47:37 AM Nick S Posts: 25	I'm having a hard time understanding the sharing concept with a large IT department. I have each department with their own folder within Secret Server. The folder is tied down to the security group associated with that department. Secrets, by default, inherit permission from their folder. I imagine a lot of deployments look like this. However, as you can imagine, departments need to cooperate and share credentials. A database administrator in the "Production Support Group" will need to share SQL accounts with the individuals within the "Applications Development" group for instance. However, if a DBA provisions a secret within their own departments folder, hits share, and shares it with Joe Developer outside their department it appears there is no way for Joe Developer to see or ever access the secret. I do have the feature "Require View Permission on Specific Folder for Visibility" set to NO. Do I have to give everyone read permissions to everyone elses folders?! Doesn't that mean they can view all their secrets? I had the expectation that you could share individual secrets and (at a minimum) they could be found by searching even if I didn't have explicit access to the folder the secret lives in. I don't want to give explicit access to everyone to every departments folder. I want to be able to share individual secrets with anyone that (at a minimum) has a secret server account. How do others use this product in scenarios such as mine where groups want their own little world but from time to time would like to share secrets with other groups (without giving them view access to all their secrets)? I'm hoping for an easy answer, not "you need unique permissions for each secret". Thanks for any advice. What are others doing with the product when it comes to this?
	0 • link
8/24/2012 10:07:51 AM Nick D Posts: 58	So a couple things... 1.) Regardless of folder permissions, if someone has permissions to view/edit/own a secret, they should be able to search for it, even if they dont have access to the folder. Make sure you are at the top level root folder when doing the search. I can confirm this. 2.) The way you have Secret Server setup (folders for each department), in my opinion, doesn't scale with how Secret Server is designed. I had the same challenge when I deployed Secret Server for my org (which is all employees globally in 19 sites, not just IT...yes, any employee can use it granted we have the licensing). IMO, using a folder structure is required at a very high level, but breaking folders down into teams within a specific org is keeping with habits of password managers that dont have the same capabilities as Secret Server. For example, there should be a folder for whatever your IT org is called (i.e. at my company its called Capabilities Operations). Within that org are many other teams, like Networking, Security, Storage, DBA, VOIP, Helpdesk...etc. You should NOT make a folder for those teams. This would be a nightmare to maintain especially with how Secret Server is designed. Secrets are where the permissions should happen. No need for a complex folder structure. What we did was break down each org globally into the different environments we have. Most companies (at least I have worked for) has logical environments like, TEST, QA, DEV, Production, Enterprise...etc. So we created a top level folder called "Capability Operations" with sub folders of TST, DEV, PRD, ENT. The entire Capability Operations team globally has access to that top level folder and sub folders. When creating a secret it defaults to NOT inherit permissions. They must specify the users/groups that can access the secret (which are also synced from AD). This keeps a very neat folder structure that doesnt need to be constantly touched. Using reports the admins can keep an eye on new secret permissions (and with the latest release schedule these reports for emailing!!!). One thing I might change however is removing the local environment folder structure and adding a field in the secret templates (drop down) to choose the environment. We do this for domain name also. For secrets that use an Active Directory template, there is a mandatory drop down for them to pick witch AD domain the account is in. This allows searching and also heartbeating (we have many AD domains). I would say to get away from trying to build secret server like many other password management solutions that have no way to classify secrets except by folders. Make "the world" appear small to the users but leverage the power of the secret permissions. As, if you are not doing it already then you need to start...use reports and event subscriptions! You have no way to know whats going on with secrets unless you audit. Our Secret Server implementation is so well put together (HA, acl's folders, roles, reports, alerts..etc) that we use it for some very important company processes like key rotation (i.e. 2 keys required to launch the nuke).
	+1 • link
8/24/2012 11:03:23 AM Nick D Posts: 58	Let me actually clear up that there is no right or wrong way in general to use Secret Server (Folders may work for you)...that being said, there is a right and wrong way to use Secret Server when it comes down to using it effectively and more important organized. If i answer your questions its based on how we would use it here (which i think is what you are asking). We dont let users provision there own folders because there is no need to. We focus on permissions of the secret not the folder. If we were to focus on permissions of the folder and let permissions of the secret inherit from the folder then we wouldn't have a way to prevent someone from accidentally making a secret that should only be seen by a few people. I look at it like Least User Privileged. Access to a secret should be have no permissions except to those that need access to it. This is why we dont inherit. Of course by doing it this way it allows us to not have a large folder structure. If you have the need for secrets to inherit permissions then perhaps you need that folder structure. It also comes down to training. Lets say you have a folder called "IT Operations" and everyone in IT Operations has access to create secrets in this folder. You also configure the folder so new secrets inherit the permissions (keep in mind you need VIEW and EDIT on the folder level to view and create secrets in that folder). Now some user in your IT Operations team creates a secret for something like the Domain Admin account in your Active Directory. The way it is setup, anyone in IT operations will by default inherit the permissions to VIEW/EDIT that secret and only you will be the Owner (unless you have other permissions inherited with Owner). The creator of that Domain Admin secret "forgets" about the inherited permissions. In my implementation, the same folder structure applies (folder IT Operations with all IT Operations employees VIEW/EDIT to folder). New secrets however do NOT inherit permissions. So now when some IT Employee adds the Domain Admin secret only he/she has V/E/O to it, which is safer. this user needs to explicitly add people to the secret. This is where reporting and alerts come into place. Setup schedules to email you reports on all new secrets added in the past 24 hours with only the creator with permissions. You can then email them and mention "Hey you created a Domain Admin secret and didnt give anyone permissions to it, is that by design?". By doing this, why do you even need folders? the permissions are on the secret. I think the pro/con to each is something like this: 1. Basic folder structure without secrets inheriting permissions. * Pro. Clean/basic folder strucutre * Pro. Secrets "by default" will not accidentally be shared with people that shouldn't have access to it. * Con. Requires auditing users and secret creation to make sure they are doing things right. ** By the way, you can edit the asp pages to remove the ability to just 'Save' a secret and only allow the option to 'Save and Share". 2. Deeper folder structure with secrets inheriting permissions. * Pro. All secrets created in that folder will have permissions set for all people that are allowed to VIEW/EDIT secrets in that folder. Doing away with someone not having access to the secret. * Con. Deeper tree's to move around. No so much a con really as it is just an eye sore. Searching for a secret is where its at. I dont recall a single one of my users that navigate the tree to find a secret at all. * Con. Using my Domain Admin example. Accidental sharing of a secret with everyone when they shouldn't. Alerts when a secret is viewed/edited comes in handy here, but this is something the owner of the secret has to configure on the secret itself or in the global user settings. Does the lack of inheritance for secrets tend to keep things organized/clean without subfolders? only with proper training of the users of Secret Server and auditing. At my company, I hold a classroom session once a month on Secret Server training. My class is called "Secret Server: Corporate secure storage and sharing of passwords." and users sign up for it using an internal portal. I provide laptops to all users and we walk through a syllabus i put together...(i.e. logging in, the interface, viewing/creating/editing secrets...etc). I also have a custom report that users will use to local secrets they dont have access to and who the owners are so they can reach out. We dont want to hide the fact that a secret exists, we just want to hide the contents of the secret
	+1 • link

---