Active Directory Permissions Go Missing

The other day I encountered a situation with an obscure Active Directory process called “AdminSDHolder” that, by design, is intended to keep things protected and secure but is not well known by Administrators and can cause a real headache.

The Situation

A user reported a permissions problem with an Active Directory group they manage. Normally, the user can control membership of the group but they’d be denied access and couldn’t perform this operation.

Looking at the Advanced Security Settings of the group, I found the setting to “Include inheritable permissions from this object’s parent” had been disabled and that all the Access Control Entries (ACEs) in the groups Discretionary Access Control List (DACL) where set to a generic list. Since the user was assigned permissions through inheritance their rights where effectively denied and removed resulting in the inability to perform any functions on the group.

The Workaround

The fix was to check the inheritance box and apply the permissions from the parent. Checking with the user all things where back to normal and they could do their work.

Or so I thought…

Later that day, that same user reported the same problem. Looking again at the DACLs on the Advanced Security Settings I found the same condition as before…Inheritance was denied and ACEs where set back to generic.

I set up an Audit Policy on the Domain Controllers to audit all Directory Service Access and applied an audit control setting to the group to monitor all access and changes made to the group. I then tested my settings by making modifications to the group and saw an audit entry in the security log showing where I had made the change and what change I had made.

A few hours later, I checked the object again and saw the same conditions as before; inheritance was unchecked and security entries where reset.

Looking through the security log there was no evidence of anything done…no entries showing changes or access to the group in question. If there are no entries in the security log for either users or services making changes to Active Directory then it’s a process operating outside of normal user-mode.

The Cause

As it turns out, Active Directory has an internal process called “AdminSDHolder” that runs every hour to maintain the security settings of protected groups and their nested groups (i.e., groups that are members of protected groups). The permissions settings used are defined by the security-descriptor of the AD object cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com.

When this process runs it check all “protected groups” in Active Directory for an attribute known as adminCount. If the value of adminCount is greater than 0, it changes the permissions on this object and resets the flag to disable inheritance of parent objects. It does this on all protected groups and the groups nested within the membership of these groups.

While it makes sense to have an automated process to keep standard permission levels set on protected groups within Active Directory, it can become a challenge to Administrators when they begin to nest groups and users together to form chains of permissions on objects.

Active Directory protects the following built-in groups by default:

  • Enterprise Admins
  • Schema Admins
  • Domain Admins
  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Cert Publishers

Any groups affiliated with these protected groups through membership are automatically flagged as protected by AdminSDHolder.

So back to my situation with the user group losing permissions. It turns out that the group being managed was a member of a protected group and therefore was having its permissions reset every hour. By removing the group membership from the protected group it was no longer subject to the AdminSDHolder process.

More Information:

http://blogs.technet.com/b/askds/archive/2009/05/07/five-common-questions-about-adminsdholder-and-sdprop.aspx

http://support.microsoft.com/?id=817433

Advertisements

Love Affair with the AD Recycle Bin

Microsoft has finally made something amazing without a lot of hype and publicity.  I’m talking about the Active Directory Recycle Bin.

Image you delete a user object in Active Directory without much thought.  I know it’s a sin but it happens.  Now if you are on Windows Server 2003 Functional Level you can “Reanimate” that object.  Which basically means you’ve resurrected it from the graveyard of deleted objects and brought it back into operation.  You’ve gone from Hero to Goat and then back to Hero (or at least not goat).  Congratulations!!!

All of a sudden that previously deleted user tries to log on and access some files or permissions assigned to him/her but cannot.  You look at the AD account permissions and attributes and see that they’re are no longer a member of the Accounting, Marketing, Operations, etc. groups and many custom attributes are gone.  What the heck…after all you brought them back from the dead!!!

Well yes..BUT!!!

By default, Active Directory, strips many of the attributes of an object when it is deleted and places it in a “tombstoned” state until it gets physically removed.

During that time you can successfully restore the object but the problem is many of the important attributes are gone including user-group memberships.  In a pinch, you can restore these objects authoritatively from a system state back-up which works but is complex and disruptive since the DC has to go offline.

Now fast forward to Windows Server 2008 R2 AD Recycle Bin.  Prior to physically removing the object and the old “tombstone” (which is now called “recycled” state) there is the “deleted” state.  This allows for a period of time that an object can be fully restored and brought back without any loss or disruption.

The Deleted Object Lifetime is defined in the AD schema and sets the time an object will remain in the recycle bin until it is finally removed when the Garbage Collection process cleans things.

It is simple yet elegant.

For more: http://technet.microsoft.com/en-us/library/dd392261(WS.10).aspx