One of the problems with AD Permissions is that AD is sort of like a garage or attic. You start out with a solid plan for organization and how things will be positioned. However over time you put something[1] here, you stack something[1] there, you push something[1] back into the corner over there all with the intentions of straightening out soon but then down the road a few years later when for whatever reason, you are forced to sort it all out again[2], you have no clue where these “somethings” came from and often why you would even consider having/saving them in the first place[3].
Identifying where the “somethings” are is usually only a small,though often challenging, part of the battle. Understanding years down the road after life events, re-orgs, employee turnover, mergers, aquisitions, divestitures, and outsourcing/insourcing why they are there and the backgrounds behind all of those “somethings” can almost hit the levels of “impossible” to figure out because it depends on data that is not collected within the system itself, it is myth and tribal lore and very often misconceptions on what was needed now or in the future[4].
Having run into this type of scenerio in several companies over the last 10 years, I am starting to think that my recommendations from years ago that people keep logs/spreadsheets with this info wasn’t listened to or possibly just doesn’t work because that all gets lost too in the same churn of life and miscellaneous happenings around the office.
Maybe, I am just spitballing here, we need to maintain a little more meta data in the directory. And by that I mean data about the data, not literally AD metadata. Start creating instances of some custom objectclass in the NC (and specifically the OU) that has the one off permissions that has a description and info attributes fully populated with the info indicating the reasoning, etc for the permission. Do it for each special one off ACE granted/denied. That way we don’t have to worry where the documentation is at, it is right there with the product. When the OU is deleted, so is the object describing the deviations. Just have to remember to update the object if the ACE changes.
Now I hear the naysayers saying… hey hey that doesn’t belong in the directory… and to be perfectly fair, 10, 8 or even maybe 5 years ago I likely would be in that grouping… But in all reality, the amount of space this would take would be minimal compared to the value it could add.
joe
[1] A permission…
[2] Say you are moving or trying to find that old DVD player or the ceiling is going to cave in or your can’t get the lawn mower out or you are outsourcing or have been reorged or are being audited, whatever…
[3] Really, when were you going to use those black nylon Michael Jackson inspired parachute pants again?
[4] Seriously, again… You saved black nylon parachute pants that you never really wore in the first place?
I completely agree that AD and any system like it needs to have some way of tracking changes.
I’ve had the opportunity to create one AD from scratch and two years later I was trying to figure out why the heck I made a choice that I did. I’ve also had a chance to take over an AD from a departed employee and I’ve spent the past three years making adjustments here and there to make some sense of it and still have a long way to go.
It would be nice to have an integrated tracking system. It would be nice that when you go in to make a change, it requires you to state why you made each change before committing it. That way, the guy after you doesn’t have to search through dozens of 3-ring binders or 100s of files on the shared folder or a bazillion emails that MIGHT have a reference that COULD point to a reason why you chose to create a field to store employee ID numbers and you called it IDS but then you never seemed to actually use it.
Sorry. Bit of a rant.
No problem Justin, that is EXACTLY what I am talking about. Kind of tough to implement the “document this change before you make it” piece but with proper process and maybe even some scripting you could maybe enforce it after the fact for at least parts of it. It would be challenging though and likely never 100%. 🙂
It’s a good idea, Joe. AD is the classic example of a system that’s handed down, and handed down, and handed down yet again – and everyone has their own ideas of what they should do with it. Re the metadata, there should also be some kind of serial number or GUID associated with the changes, so if some for example permission change was inherited down the tree one could see what the entire change was at the macroscopic level, not just the change at the individual object.