I recently ran into an issue while working on a project where I needed to disallow users from reading a certain LDAP attribute in Active Directory. Let me give you a little backstory. I work at a school and we are using sha1hexfltr on our domain controllers to capture password changes in AD and store the unsalted hex sha1 hash into the “division” attribute. Google Apps Directory Sync then grabs that hash from all of the users, and creates/updates their Google Apps account with that password.
Unfortunately, the developer hard-coded his application to use only this attribute and has not released the source code. By default, the division attribute is readable by ANYONE in the domain, and the unsalted sha1 hash of EVERYONE’S (CEO, Domain Admins, etc.) password is saved in plain sight. Obviously this is really bad. After some research on the web I figured out how to make this attribute unreadable by anyone other than the user GADS runs as. This should work for any attribute, but I’ll use division as an example. If you follow this whole process, any existing users, as well as any users created in the future, will have their division LDAP attribute hidden from whoever you want.
Each object in Active Directory has an Access Control List, or ACL. What we want to do is modify the ACL for all the users in the domain to have an ACE (Access Control Entry) that says, “Deny members of the ‘Domain Users’ group read access to my ‘division’ attribute.” We also want to add this entry to the default ACL on the ‘user’ object type in the AD schema so all user objects created in the future will have their division attribute hidden as well. The easiest way I’ve found to do this is to modify the schema first.
In order to modify the schema, you need to open the Active Directory Schema MMC snap-in. If it doesn’t show up in your list of snap-ins, open a command prompt and type regsvr32 schmmgmt.dll. It should say “DllRegisterServer in schmmgmt.dll succeeded” and the Active Directory Schema snap-in should show up in the list.
Once you have the Active Directory Schema snap-in opened, expand the “Classes” folder and scroll to the bottom where you will find the “user” class. Right-click on it and click Properties, then go to the “Default Security” tab. Click “Advanced” and then click “Add…”. We said that we want to add a “Deny” ACE that applies to the “Domain Users” group, so type “Domain Users” and click OK. This will bring up the advanced permission entry window. Click on the Properties tab and set Apply to: to “This object only”. Scroll down until you find “Read Division” Click the Deny checkbox and click OK on all windows. If it warns you that a deny entry takes precedence over any allow entries, just tell it that you know that already.
Now you’ve changed the default ACL for all new objects of class “user”, but we haven’t really fixed the problem yet. Now what we are going to do is reset the ACL for all existing user objects in the domain back to the default ACL stored in the schema (which we just modified). We will do this using a tool called dsacls that is included in the Windows Server Support Tools package. It was already installed on the server that I used, so that may be the case for you as well. The syntax this command takes is as follows:
dsacls <DN of starting container> /S /T
The /S switch tells it that you want to reset the ACL to the default ACL stored in the schema for this object class. The /T switch tells it that you have specified a DN to a tree and you want to reset the ACL on all objects in that tree recursively. In my case, this was one of the commands that I used:
dsacls “OU=Students,DC=testdomain,DC=com” /S /T
I ran it on all of the OUs that contained user objects to make sure that I protected everyone’s password. I also needed to remove the GADS user from the “Domain Users” group so the ACL wouldn’t apply to him. After I was done I used LDAP Admin and bound to LDAP as myself (a member of Domain Users) to make sure I couldn’t view anyone’s division attribute. I also bound to LDAP as the GADS user and made sure that he could view everyone’s division attribute.
I hope this helps someone else who is in the same situation that I was. A lot of this AD schema stuff is rather cryptic on the surface.