One important thing I learnt from the ADs and domains I’ve worked with is the importance of naming conventions.  It is often overlooked, or poorly chosen.  While my naming convention for my test environments might not suit everyone, but a well structured naming convention makes automating things a lot simpler which in turn helps with creating tools down the road, as identifying and enumerating the AD objects you need will be simple.

Picking naming conventions is one thing, enforcing them is quite something else.  My solution to this was to automate everything that requires naming an AD object.  Users, Computers, OUs, Groups, the lot.  Even I don’t create objects by hand any more, it’s not worth the time.

I will start posting the functions soon, but I thought it would be a good idea to explain our group structure and naming conventions first.  I feel it is quite self-explanatory, but I designed them so I guess I would, wouldn’t I?

Group Structure

Resource < Resource Access Group < Role Group < User

For a user to authenticate to a resource, they will need to be a member of a role group. The role group will be a member of a resource access group which is then given permission to the resource.

The role group will only hold user or computer objects.  The role group will always be a Global Security group.  It will not grant access to anything by itself.

For a Role group to grant access to a resource (in this example a resource called Sage) it will need to be a member of a Resource Access group.  The Resource Access group is assigned permissions on the service.  This could be to a front-end (web/application), or nested into a RBAC group on a system that has them (System Center, for instance).  A Resource Access group is always a local group.

This might seem like a massive pain, but becomes seamless pretty quickly, especially when setting them up is automated.  It is also the best way to cover for any future scaling/merging.

Naturally, there are some caveats.  Some systems are poorly written and can only manage user lookup with LDAP, and can’t deal with nested groups.  In these cases, you might need to use the global group to grant access to the resource.  If you have to do this, make sure you do it with a frown.

Naming Conventions

Now I’ve tried to explain how I do groups, I think I can explain how we name them, and why.

It basically looks like this for all groups with few exceptions:

<Scope><Type>-<Resource Type>-<Resource Name>

And the ‘homepage’ field for each group is just the Resource Name.  This is so I can populate a combobox with the resource names.  Then I can quickly jump to the group I want by typing the resource name, rather than the entire suffix and resource name.  Once you get a few hundred groups this really starts to pay off.

And some examples:

GS-APP-Sage User

GS-APP-Sage Administrator

LS-ADMIN-VM Operator

GS-RDP-Sage Remote

LS-RDP-Sage Remote

Some exceptions are:

Distribution lists, which are just the list name

File Services access uses 5 similarly named groups with suffixes (R, RW, O(owners)) for each shared folder so they are more like:

GS-FILE-Finance Management R

GS-FILE-Finance Management RW

GS-FILE-Finance Management O

LS-FILE-Finance Management R

LS-FILE-Finance Management RW

But I will cover this and the reasons why in another post where I explain how I set up file services.

Beyond the literal name, there are other things that need naming.  For our work site, I put the core group name (the bit that is not the prefix) in the homepage field of all groups.  This way if I am listing groups in a GUI, or a report, I can use the shorter names for display purposes, as a list of group names with the prefixes attached looks rough.  We could pull the core name out programatically, but as the result of that will always be the same, you might as well just put it in a field once and save yourself the calculations.

So, why?

Well, because it is tidy and it allows me to do some awesome things in PowerShell.  Like to pull all the File Services owners groups, I just run a regex match like:

 $ownergroups = Get-ADGroup -properties homepage | Where-Object name -match 'GS-FILE-.+ O$' 

And there I have it.  If I wanted to send a mail to each folder owner letting them know who has access to their folders, I have all the information I need in the above variable $ownergroups.  Shortnames for the folder groups, descriptions from the groups, I can easily pull up memberlists of the read and read/write groups for each owner folder.

This can be done with any sort of naming convention or even none at all, but having a good naming convention will give you more confidence when running bigger tasks.