Save My Schema

Reading Time: 4 minutes

So working a lot with customers and their *interesting environments I often get called in to fix blotched permissions on important aspects of Active Directory. Which important aspects you ask well how about THE SCHEMA NC!

I have seen this in many news groups and many times I have had to fix this so to help others I am blogging about it.

Prevention is better than any cure in my mind so first of all. There should be no NORMAL reason for you to be altering the Schema NC ACL with some arbitery ACE’s unless you have a special need which should be discussed with a trusted Microsoft employee first before continuing.

The schema is a very important part of Active Directory as it’s the architecture room of the directory. It has all your blue prints for all your little objects in your directory, its like the DNA factory. If you secure your DNA factory so “Well” that not even the factory manager can access the blue prints to create objects you have a problem.

So I hope I am getting the point across about being extremely careful with touching the precious (I sound like golem from Lord of the rings here) ACL on the Schema NC.

But for those of you that don’t read the README or don’t take notice of warnings like these here are some “save my ass” procedures on how to return your schema ACL back to a working state.

**I just want to note that I am not the master mind of these procedures, there was a lot of discussions with many MVP’s (Paul Williams _awesome AD MVP), Microsoft employee’s (who always remain anonymous hey Tomek;) I wont mention number 2 he always likes remaining anonymous but he is truly one of the ultimate AD gods) So credit goes to all these wonderful and talented people.


Save my A$$ Procedures

This posting is provided "AS IS" with no warranties, and confers no rights.


  1. Don’t screw with your Schema NC ACL.
    1. If you have already screwed with your Schema NC ACL – go to step 2
  2. At this point you have already screwed with your Schema but to further protect you from screwing the network, disable OUTBOUND REPLICATION for that server. **NOTE**: -> PLEASE first asses the impact of disabling OUTBOUND REPLICATION, do not just disable it, if you running other FSMO roles or Exchange 5.x or 200x on that machine disabling OUTBOUND REPLICATION could cause some unexpected effects. So please asses what needs to be done before disabling OUTBOUND REPLICATION.
  3. First thing examine the current ACL that you have, make sure that all ACE’s on your schema objects (classSchema, attributeSchema) are inherited and that you have no explicit ACE’s on any of your classSchema or attributeSchema objects, if you do note these down as you will have to reset them too.
  4. Use an account that has Take Ownership permission, and take ownership of the Schema NC.
  5. Now many people ask why you cant just use dsacls /T and lets look why you shouldn’t use it. First of all what does /T do, it restores the security on the TREE of objects to the default ACL for that object class (NOTE the OBJECT CLASS PART), secondly you have to use the /T switch with the /S switch. The /S switch restores the security on the object based on the default ACL defined for that object class in the Schema. Now can you see the problem with that?
    1. What if you CANT get to the schema cause you just screwed with the ACL how is dsacl’s going to find out what the default ACL for that object is if it cant get to the object?
    2. What if you CAN get to the schema BUT you have changed a ACE in the ACL for that object class, now dsacl’s goes and tries to “fix” that by restoring “corrupt” ACL you back in the same place
  6. So you get the point why not to use dsacl’s /T /S
  7. Download, beg or borrow the LDP version that comes with Windows Server 2003 R2.

LDP -> Connection -> Connect -> “Server (make sure it’s the Schema Master)” , Port: 389 *this can differ

Connection -> Bind -> user administrator ….

View -> Tree -> DomainDN (Dc=Domain,dc=Com)

  1. Important to note here, you need to bind to the Schema NC using one of the two users:
    1. BUILTIN\Administrator
    2. Account with TAKE_OWNERSHIP privilege
  2. Why? – Being the owner gives you  implicit ReadControl and WriteDac permissions on object in the directory
  3. Once you have successfully connected and bound to the directory, you can then assign an inheritable FULL_CONTROL ACE to the Schema Admin group.
  4.  Now Paul Williams has posted a complete list here (but for sake of completeness I have posted the list here *Note these are just the DACLs I will update the article with the SACLs that are needed on there ASAP, but in order to get you up and running you can add your DACL’s;




SYSTEM — Full control (this object and all child objects)
Schema Admins — Full Control (this object only) — Special (this object and all child objects): — List contents — Read All Properties — Write All Properties — Read Permissions — Modify Permissions — Modify Owner — All Validated Writes — All Extended Rights — Create All Child Objects — Change Schema Master — Manage Replication Topology — Replicating Directory Changes — Replication Synchronization — Update Schema Cache
ENTERPRISE DOMAIN CONTROLLERS — Manage Replication Topology (this object only) — Replication Synchronization (this object only) — Replicating Directory Changes (this object only)
Authenticated Users — Special (this object and all child ojects) — List contents — Read All Properties — Read Permissions
Administrators — Manage Replication Topology (this object only) — Replication Synchronization (this object only) — Replicating Directory Changes (this object only)

  1. For your convenience I have included a video on how to use LDP to set an ACE download it here.
  2. Now try access your Schema NC as a Authenticated User (use LDP to connect, and bind and view).
  3. Now – IF YOU DISABLED OUTBOUND REPLICATION — ENABLE OUTBOUND replication so that all the changes and replication can take place.

Moral of the story, DON’T PLAY WITH YOUR ACL’s unless you need to, and if you not sure ask a friendly Microsoft employee 😉