If you manage an Active Directory (AD) forest, schema changes may or may not be a touchy subject. In my case it is. I've seen too many AD schema changes that have gone haywire. To better understand what I'm talking about lets first review a couple of facts about AD's schema:
Note: Schema changes can actually be reversed, after all AD is based on LDAP. However, Microsoft prevents schema changes from being reversed. While, you could modify some permission in Windows 2000 and hack away, Microsoft corrected that issue in SP2 or SP3. I just simply don't remember.
Anyhow, I'm providing this list to illustrate some very critical concepts when it comes to the AD schema in relation to changes that may be imposed upon it. My goal by doing this is to hopefully, help people understand why a proper change control process should be in place for AD schema changes (hey here is one - Link). In other words, be wary, of requests to make changes on the fly. So, next time some developer at your company asks to be dropped into the Schema Admins group. You might want to ask some questions or at last review what changes will be made. Chances are, they don't even know and are just hacking their way through whatever project they are trying to complete.
If I haven't conceived you yet, let me try to make a better argument. Microsoft has tons of code samples on MSDN. There was one particular code sample that walked developers through making their very first LDF file to extend AD's or ADAM's schema (for some reason I can't find the link right now). In the example were some OIDs. What do you think most people that saw this example did? Yes, copy, paste, modify and away they went without changing the OIDs. At some point MS decided to use one of those OIDs (I believe it was the Windows Server 2003 schema update, again my memory is failing me tonight), and some people then had a hard time updating their schema.
Want another example? Ok, one of our clients recently ran into a problem attempting to test the OCS schema update (yes, notice I used the word test). While performing the test, in a lab environment, the update failed with a conflicting LinkID error. After researching the issue, we found that another previous schema update (from a well known software vendor whose name I shall not mention) used a LinkID that was reserved for Microsoft (or maybe it was the other way around, we are still looking into this). In other words, I would even scrutinize schema updates that come from well known sources, this includes Microsoft.
Hopefully, this post has been helpful...
With more than ten years of experience in IT, Tyson Kopczynski has become a specialist in Active Directory, Information Assurance, Windows automation, PKI, and IT security practices. Tyson is also the founding author of the Windows PowerShell Unleashed series and has been a contributing author for such books as Microsoft Internet Security and Acceleration (ISA) Server 2006 Unleashed and Microsoft Windows Server 2008 Unleashed. He has also written many detailed technical papers and guides covering various technologies. As a consultant at Convergent Computing, Tyson works with and provides feedback for next generation Microsoft technologies since their inception and has also played a key role in expanding the automation and security practices at CCO. Tyson also holds such certifications as the Certified Information Systems Security Professional (CISSP), the SANS Security Essentials Certification (GSEC) and SANS Certified Incident Handler (GCIH), and the MCTS (Application Platform, Active Directory, and Network Infrastructure).
Certifications:
Publications:
Other Stuff:
The Leader in Network Knowledge
