http://www.thycotic.com/forums/messages.aspx?TopicID=470 Thycotic Community - Secret Server - Sharing seems hampered--am I missing something? - Messages en-us http://blogs.law.harvard.edu/tech/rss Jitbit AspNetForum Wed, 17 Oct 2012 12:59:13 GMT Wed, 17 Oct 2012 12:59:13 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
Thanks a lot for your comments here.

Nick Sulivan pointet me on your conversation here.

I´ve just gone thru your conversation with
him and it sounds very interesting.

I have to think about it, but it sounds practical and
tackling exact 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 English (as a German)

]]> Wed, 17 Oct 2012 12:59:13 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
I've been brainstorming with some of my staff.

This type of folder structure and mentality sounded good to them. It'd be nice if we could order the folders in ways other than alphabetic (feature request submitted!).

Mentality:
- Security is on the secret not the folder
- No one sees your secrets by default: you are the only owner.
- Feels more like a "mailbox" almost


Folders (still thinking this over but the guys liked it...):
- Service Accounts
- SQL
- Web
- Kiosk
- Testing
- Appliance/Device
- Other


Old Mentality:
- Security is on the folder, secrets inherit
- Your whole group sees all secrets by default
- Feels like a file share that everyone has access to

Old Folders: hierarchy of our IT dept.]]> Fri, 24 Aug 2012 15:38:42 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
The report I use would be so much better if Thycotic would allow a drop down for me to select the secret alone (you'll see what I mean when you get the sql).]]> Fri, 24 Aug 2012 14:58:46 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470 Fri, 24 Aug 2012 14:49:55 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
I may have to retool and retrain the few groups I have gotten to so far.

I'm actually starting to turn towards a much flatter structure and turning off inheritance.

I'm also thinking about switching to secrets not inheriting and that the owner by default is the only one who gets access.

I could then do something like provision four simple folders: High, Medium, Low, Other

Let my individual users use them like they "own" the folder but in reality they are all contributing secrets to the various folders--they just don't know they are in a "shared area". When they need to share individual secrets with others or a group they can.

They could almost treat the software like a "password mailbox" for themselves and I don't have to get them even thinking about the concept that some folders could be provisioned so that entire groups see the contents.

Really got me thinking, again, thanks Nick. Appreciate the thought. It may make it both simpler for my users and simpler to maintain.]]> Fri, 24 Aug 2012 14:45:42 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
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

]]> Fri, 24 Aug 2012 11:03:23 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
As I probably saw, I was incorrect originally, sharing is working as described.

However, your comments make me think I may have too deep a folder structure.



While I didn't provision out each role within a department, each department does have it's own folder and perhaps that is over kill.

Let me ask this: do you let your users provision their own folders for organizational purposes at all?

Here's an example while I was training our client support department (who has about 12 employees within it).

One guy within the group manages the kiosk accounts at my company... there are probably 120 kiosk accounts that run various machines globally.

He would like to import them into secret server but doesn't want to muddy up their departments folder with all these accounts. His thought was to allow users to provision their own folders. Perhaps he'd call one called Kiosk Accounts and throw all these in there.

Do your teams do stuff like that? How do they overcome storing a bunch of stuff within a "smaller world"? Does the lack of inheritance for secrets tend to keep things organized/clean without subfolders?

Again, Nick, I really appreciate the detailed response! Thanks much! If I could give you some karma or a upvote I would ]]> Fri, 24 Aug 2012 10:21:18 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
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).]]> Fri, 24 Aug 2012 10:07:51 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
User error on my part made me think otherwise.

PHEW!

]]> Fri, 24 Aug 2012 09:51:12 GMT http://www.thycotic.com/forums/messages.aspx?TopicID=470
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?

]]> Fri, 24 Aug 2012 09:47:37 GMT