Historically, both Active Directory (AD) administrators and IT managers have been fearful of extending the AD schema. Much of this fear stems from Microsoft documentation in the Windows 2000 era that made schema extensions appear to be dangerous and something best done with extreme caution. However, with a bit of planning and due diligence, extending your AD schema doesn’t have to be something to fear.
The AD schema defines the structure of the data stored in the directory. Out of the box, AD supports many different types of objects (e.g., users) and attributes (e.g., first and last name). When the base schema that comes with AD doesn’t lend itself well to data you need to store in the directory, you can extend the schema with custom objects and attributes.
Typically, the AD schema is extended for a number of reasons. For many organizations, the most common reason is the implementation of an application that requires a schema extension. Microsoft Exchange is a perfect example of this. Third-party software vendors also sometimes require schema extensions to support their application. Also quite common is extending the schema to support an internally developed application, or to provide a location to store proprietary data in AD.
Data Storage Options
The first things you should evaluate when considering a schema extension, particularly for an inhouse application, is whether or not the data is appropriate for storing in AD. Particularly well suited to AD is data that is relatively static (i.e., it doesn’t change often), that is necessary across your organization (because it will replicate across domains), and that isn’t highly sensitive (e.g., you shouldn't store birth dates, social security numbers, and so on in AD).
If you have data that doesn’t match this criteria but still needs to be in an LDAP directory, a second option might be a good fit for you. AD Lightweight Directory Services (AD LDS, formerly ADAM) is a standalone version of AD that can run as a service on a member server (or domain controller—DC) and be queried via LDAP, just like AD. Rather than being constrained by the need to place AD DCs to support enterprise authentication and application requirements, you can tightly control who can read data and where that data is replicated by only placing AD LDS instances in appropriate locations.