Because active directory security groups can...
- hold objects regardless of OU.
- be used for reporting, documentation, inventory, etc.
- be referenced by automated processes (Get-QADGroupMember).
- be used to apply policy
- be used by WSUS
I would like to use security groups as hierarchical tags, representing various attributes of a computer or user. I am thinking of (computer centric) tags something like these:
/tag/vendor/vendorName
/tag/system/overallSystemName
/tag/application/vendorsApplicationName
/tag/dependantOn/computerName
/tag/department/departmentName
/tag/updates/Group1
Before fumbling through implementing this, I thought I would seek comments from the community. Specifically in the areas:
- Does this make sense?
- Would it work?
- Has anyone else attempted this?
- Is there a good reference on the matter I should read?
- How best to implement the hierarchy?
- Tag_OU\Type_OU\GroupName (limits quantity in OU, uniqueness not guaranteed)
- Tag_OU\Type_OU\Tag-Type-GroupName (limits quantity in OU, uniqueness guaranteed, verbose)
- etc ...
Thanks in advance!
We're doing similar things for Users, actually. Our ERP database spits out "Eligible for Accounts" lists that our identity-management routines turn into new/deleted accounts. Those same lists include variables that allow us to auto-create groups based on employee type, and since we're a University, Major and enrolled-classes groups as well. The last two are very useful for setting permissions on things like classroom file-shares.
One of the key things we've found is that the group naming-convention has to be such that it is OBVIOUS that they're generated groups rather than manually maintained ones. This discourages mistakes.
The other thing to keep in mind is that AD allows nesting groups, which is VERY handy when setting up a file-share location where "anyone taking Geology classes" can get to; there is a group that contains the class-groups of all GEOL classes. It is less handy when an application or something doesn't support nested groups (such is the case with VB-Script).
Doing it with Computers will take more effort since you can't rely on your IDM system to do the heavy lifting for you. We're just parsing CSV files. You'll have to periodically inventory all of your equipment to generate yours. Those sorts of inventory systems can be made through a WMI script that sweeps across the entire enterprise, a WMI-script that runs on-startup that dumps config in a special place for parsing and upload, or (for commercial products) an actual agent that takes periodic inventory and updates a database.
I understand what you're trying to do, and it makes sense, but something about strikes me as a little off. It seems like provisioning of users and computers could get awfully time-consuming and complex.
Some of your tags look like inventory type items. I wonder if there isn't a better solution to this, perhaps WMI scripting like sysadmin1138 recommended.
I also wonder about logon time effects on users if they are now in maybe 15-20 groups.
Overall, a good idea, I'm just not sure if it is the way to get what you're looking for.