Historically, organizations are hesitant to extend their Microsoft Active Directory schema. And they have good reason to be cautious. After all, Microsoft documentation from the early Windows 2000 days contained verbiage that made a schema extension appear dangerous and something that should only be attempted with extreme caution.
However, since that time, thoughts on schema extension have evolved. The fact of the matter is that Active Directory was designed to be extensible. So, when my customers come to me with this very same apprehension, I do my best to ease their concern by sharing a little bit of knowledge. Here are the questions I help answer:
Why extend your Microsoft AD Schema?
The AD schema simply defines the structure of data stored in the directory. When the AD base schema does not contain the data you need to store in the directory, you can extend the schema with custom objects and attributes. Microsoft Exchange is the most discernible example, since it extends the schema drastically (and with positive effects) to perform its job.
The first thing you should always consider when extending a schema is whether the data being stored is suitable to be stored in AD. In the case of the Crossmatch DigitalPersona platform, it is storing relatively static credentials such as fingerprint templates, pin codes, recovery questions, etc., which are very well-matched to be stored in AD. Personally, I take it a step further and provide my customers with an LDIF file, providing exactly what directory content is being added to their schema. An LDIF file is a standard plain text data interchange format for representing LDAP (Lightweight Directory Access Protocol) directory content.
What causes issues with a Schema Extension?
It would be immensely helpful if Microsoft released a statement that a schema extension just adds new classes and attributes and should not have any impact on your applications and services. This way everyone could breathe a sigh of relief and not have to worry about taking this critical, and often necessary step. However, we just do not have that luxury. Therefore, it’s imperative to do our due diligence and research what potential issues could arise from a schema extension.
Most issues caused by schema changes are due to poor application practices and coding. For instance, an application has a dependency for a specific schema version, or an application that has its own extension to the AD schema that has been improperly implemented. Unfortunately, most vendors do not clearly document what changes their application makes to the AD schema. Therefore, when deciding on extending your schema, you should consider doing the following checklist:
- Review the schema extension changes of the proposed application prior to performing the extension to your AD your schema.
- Build a test environment that closely resembles production and include all the applications identified as having schema changes.
- Test, test, and test some more!
You can also make use of tools like SchemaAnalyzer to export and compare Active Directory schemas with different versions of Windows Server and different enterprise applications installed.
Still apprehensive to do a schema extension?
Active Directory Lightweight Directory Services (LDS) is a Lightweight Directory Access Protocol (LDAP) directory service that provides data storage and retrieval support for directory-enabled applications. It does all of this without the dependencies that are required for Active Directory Domain Services (AD DS). You can use AD LDS to store required custom objects and attributes from applications and proxying authentication for your application to AD DS. Besides having to perform slightly more management and issue additional resources to the new virtual machines hosting the LDS server role, this is not a bad idea at all. Deploying AD LDS like this can allow you to keep your AD schema as pristine as possible and ease all the worries of future implications.