Group Nesting Strategy – stop the madness.

Talk about getting side tracked looking to confirm the syntax of a PowerShell command I came across this post on the Quest One Identity forum and started to answer it, then realised that I should really be posting here not in the forum and then use a shameless plug on the One Identity forum.

This was the question:

“We use the lousy nested structure for shared folder ntfs permissions where a domain local group contains a universal which contains a global and the global has the users.  I want to find a way to create the 3 groups required when a new folder is setup, then add users to the global group”

Woah! 3 groups for every file share!!! I want to scream stop the madness now!

I’ve been trying to explain this for years and I really want to enlist a few people in the guido school of administration

“Our Guido School of Admin Training is a very informal school held outside in the nice, fresh air in the alley between two office buildings. There are no formal registration procedures, however you do have to be nominated to attend.

What to expect: The instructor, Guido, will shake your hand and then gently haul you over to the nearest wall by your collar. Then it becomes really exciting and lots of fun. With a jaunty smile, Guido grabs you securely by the back of the neck and smacks your face against the wall while saying in a firm tone of voice:

Do {smack} not {smack} nest {smack} security {smack} groups {smack} into {smack} protected {smack} groups.”

Only in my case its do {smack} not {smack} just create groups {smack} for the sake of nesting them {smack}!

I’ve never heard anyone recommend a 3 level group nesting strategy suggested in the post 2 is already one too many and possibly two too many.

Use the appropriate groups for the job and NEVER create a group unless you have a good reason to.

The standard Microsoft teaching is to create 2 groups a domain local or universal and a global group nesting the global in the local.

That’s not the idea at all and is why almost every AD I’ve ever seen is a complete mess

Often an Active Directory will have more groups than the company has employees by several multiples which should tell you something is wrong.  Do a quick count in your environment and see how deep you are into this bad practice.

Let’s take a quick look at this.  You create a local group or a universal group,  well which is it ?  A local group can only be used to secure resources in the domain in which it is created.  A universal group is available in all domains in the forest.   Both groups can contain users and groups from all trusted domains.  So which group depends if you have resources in multiple domains or just one.

Now we come to the crux of the problem here.  You create a global group, add the users to the global group and then nest the global group in the local group.

Why not just add the users to the local group?

Good question.  Why not?  There is no real reason but then whats the point of a global group at all? Another good question.

Did you know that a global group takes up less room in the security token so you can be a member of more global groups than you can local groups before you get authentication issues because you have run out of allocated memory space for the security token.

So why not just use global groups then?

If you don’t have any trusted domains then you could just use global groups but we are getting away from the point here.

Why do Microsoft tell us to so the nesting?

Well the short answer is because this is the most flexible way of doing things.

So whats wrong with it then – what are they not telling you on the training courses?

The problem is that if you are creating a local group and a global group and there is a one to one relationship every time, then as shown above you could just use the local or global group.  This happens because when you designed the delegation model you did this in isolation from everything else and your solution is actually quite sound but if you step back a little and perhaps look at the wider picture you might see whats wrong.

What was it Microsoft said the global groups were for?

You add the users to the global groups, right?  Whats the global group called?  The group name should reflect the group of users you just added to it.   If for example we were controlling access to a finance file share the global group could reasonably be expected to be called ‘Finance Users’ now what about the local group, whats that called and what’s it for?  Well the local or universal group should be named after what it’s controlling access to.   I’ve adopted the term ‘capability group’ from a book which I promise I’ll look up and post the name as it’s an excellent book explaining how to delegate properly.  The local group name might be ‘Finance Share’  ( I’m not getting into naming conventions this is simplified just for this post).  Lets also suppose there are some applications the ‘Finance Users’ need installed on their PCs, this could be set up using a local group called ‘Finance Applications’ and we could nest the ‘Finance Users’ group in the two local groups.

A self documenting solution

If I look at a user and I see he is a member of the ‘Finance Users’  group, even if I don’t add HR data to my user objects, e.g. set the department attribute to ‘Finance’ I can see that the user is a finance user.   If I did populate the AD users department value then the ‘Finance Users’ group could be managed automatically by creating an ARS dynamic group or you could write a custom script to manage the group as a scheduled task.  Also when I look at the ‘Finance Users’ group I can see it is a member of two local groups, ‘Finance Applications’ and ‘Finance Share’ so I can now see just from looking at the groups what the ‘Finance Users’ have access to.

Now lets say you build another file server and want to share this out to Sales and Finance.  Create a ‘capability’ group called ‘Sales and Finance Share’, create a global group and add all the sales employees to the group and then nest BOTH the ‘Sales User’ and ‘Finance Users’ in the ‘Sales and Finance Share’ group.

What no one is pointing out is that we want to REUSE the global groups – maybe they just think it’s obvious but trust me in my experience it’s not.

The global groups should be reused and they could be considered role groups, although this is where there possibly is a case for for a 3 group nesting strategy but be careful in a large environment you will hit the group limit.  When you hit the limit the access token will be truncated causing access issues when the group you need to access the resource cannot fit in the allocated memory.  This will cause an ‘access denied’ or WORSE will get access because the DENY group wouldn’t fit in the memory which is another reason to NOT use DENY anywhere just don’t give them access in the first place.

In an ideal world…..

Your ideal is that when a new employee starts they are added to a single group, e.g. the ‘Finance Users’ group, automatically and this group give access to everything they need to do their job either by adding the global group directly to the ACL or by nesting it in a local group that has been applied to the ACL of the resource.  If they move departments, e.g. from ‘Sales’ to ‘Finance’ their group membership automatically gets updated.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.