Thycotic Community Forum

9/14/2011 10:47:33 AM Nick D Posts: 8

I'm hoping we can find a solution to this without changing our folder structure. Since secret server allows us to ACL secrets, unlike other password managers where you ACL (password protect) the database file and have access to all the secrets within in (i.e. KeePass), we determined that there is no longer the need to break the password manager out into Department folders. What we did is design a structure of top level folders that are named after the logical domains in our company, so for example; ADDomain1, ADDomain2, ADDomain3...etc. Within each of these top level folders are the business environments that we use, so for example, TEST, DEV, PROD Domain1 -TEST -DEV -PROD Domain2 -TEST -DEV -PROD Domain3 -TEST -ENT -DEV With this setup, any secret someone creates should fit within one of the environents. It doesnt matter if you are a member of the Security, Networking, Server, or Helpdesk teams. This setup is clean and prevents a ton of folders. The problem though!! In order to create a secret in a folder you need VIEW and EDIT on that folder. When you create a secret it carries the default permissions of the folder to the secret. This is BAD. With this model it puts the trust in the person creating the secret to adjust the secret permissions when making it. For the most part, secret server users understand this. However, time to time, a user will just click "Save" instead of "Save and Share". We have a request for a team at our company to be able to create secrets in a bunch of folder. However, we do not want this group to be part of the default permissions when creating the secret. My question(s): 1.) Is there any way to achieve what I want? 2.) If not, any plans for future versions to seperate folder permissions from default secret permissions? 3.) If no to either of the above, is my only choice to seperate out into team folders, which to us would get ugly, and have a lot of redundant secrets. 4.) Recommendations?

0 • link

---