1

Because active directory security groups can...

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!

2
  • I should point out that the original idea came to me while attempting to document the many aspects of our servers? What applications are on a server. What servers does an application live on? Do one of the applications depend on another server? How do you maintain the server list? I'm sure there are inventory applications to handle this, but most of the data is already in AD. All that it lacks is the relationships. Which is where the tagging comes in. With the added benefit that the groups can be used for many other things. Oct 20, 2010 at 3:16
  • +1 for a really well written question. I don't know if it will work out for you but it seems to me to be a very high maintenance approach to cataloging your systems. Perhaps it would make more sense if we knew what your final objectives are. Jan 14, 2011 at 1:13

2 Answers 2

1

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.

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .