Chapter 4. Active Directory
Summary of Active Directory Requirements
Rationale
Many customers will deploy Active Directory in a geographically dispersed environment spanning WAN and LAN links. Hundreds or thousands of Active Directory servers that replicate with each other may be deployed in many of these environments to achieve availability and scalability.
These requirements help:
Prevent inefficient usage of network resources.
Ensure consistency among Active Directory-enabled applications.
Improve supportability of Active Directory-enabled applications.
Ensure peaceful co-existence of applications that extend the schema.
Customer benefits
As network computing evolves to become more dynamic, static binding models become increasingly restrictive. Active Directory provides a globally available infrastructure for finding binding information by key attributes of services.
Integrating your application with Active Directory offers your customers:
Easier Management. By utilizing Active Directory, you can eliminate the need for administrators to update information on the client machine whenever services are added or moved in the network.
Robust distributed management framework. Because Active Directory supports multi-master replication, you can enable distributed management of your application by storing configuration information in Active Directory with built-in redundancy.
Granular delegated administration. The attribute level access control in Active Directory allows your customers to delegate administration of different parts of your application to the appropriate people.
Requirements
Use Active Directory appropriately
Document the storage and replication impact of your application
Document your application's use of objects and attributes in the-base schema
Information stored in Active Directory must be "globally interesting"
Attribute values must not exceed 500KB in length and the total object size must not exceed 1MB
If you extend the schema, adhere to Active Directory Schema extensibility rules
References
The Active Directory Programmer's Guide
http://msdn.microsoft.com/library/en-us/netdir/adsi/active_directory.asp
SchemaDoc.exe utility for documenting Active Directory schema extensions
https://msdn.microsoft.com/certification/download.asp
How to Comply with Active Directory Requirements
1. Use Active Directory Appropriately
This requirement helps:
Eliminate the need for administrators to manually update applications containing client components when administrators change the network location of server components.
Ensure that applications consume the most up-to-date information regarding network resources.
Minimize the need to enter and maintain duplicated information about network elements.
A. If your application comprises multiple components that run on different machines, and there are 'client components' that request services from 'server components' (see Endnote 2) then:
If Active Directory is available in the environment where your application is deployed, the server components of your application must store information in Active Directory so the client components can locate and connect to the server. This information can be a server name, Remote Procedure Call (RPC) end point, IP address and port number or a combination of these. For client/server applications where the client and server can be developed by different vendors, it is important for the server vendor to publish information about how clients can find binding information in Active Directory.
Applications must not store binding information in such a way that updating the network location of server components requires administrators to update each client component individually. For example, applications must not keep authoritative binding information in text files on client machines.
Examples
Client/Server applications where client components are on many desktops that connect to a database server to read and write data
'3-Tiered' applications where client components are on many desktops that connect to middle-tier servers that make RPCs or other remote requests
Client/Server applications where server components on workstations publish their availability to a client component on a server for periodic actions, such as virus checking or file backup
A mail server that extends the user object with an attribute that is used to store the domain name service (DNS) name of the e-mail server the user is hosted on-e-mail client uses this attribute to connect to the e-mail server hosting the user.
The following table lists examples of typical resources that can be stored in Active Directory.
Resource Binding Information Example File Service UNC path for a share. \\MyServer\MyShare Server DNS name Myserver.example.com Web Service URL www.microsoft.com/ RPC Service RPC binding: special encoded information used to connect to the RPC server. RPC bindings can be converted to and from strings with the RPC APIs ncacn_ip_tcp:server.microsoft.com Please see the following sections of Active Directory Programmer's Guide for more information on how to use Active Directory to locate network resources required by your application:
Service Publication-How to publish resources in Active Directory
Searching Active Directory-How to find resources published in Active Directory
Extending the Schema-How to extend Active directory schema to store application-specific information
B. If the customer maintains authoritative information in Active Directory and your application uses this type of information, your application must be capable of using this information from Active Directory.
This applies to applications that utilize information about network elements such as users, machines, or devices. In these cases, your application must be capable of extracting this information from Active Directory. Your application must either:
Obtain this information directly from Active Directory
- or -
If your application maintains a duplicate copy of this information, then it must provide a means to synchronize its local copy with what is in Active Directory. Specifically, your application must either:
Offer a synchronization mechanism within your application
- or -
Expose APIs (or similar mechanism) that enables an external meta directory or directory synchronization product to keep the information in your application consistent with what is in Active Directory. You must document this mechanism.
Example
- Applications that print reports containing information about users should enumerate the list of users by querying Active Directory. Applications should not keep duplicate lists of active Windows 2000 users in a database where administrators are required to manually keep the lists up-to-date.
2. Document the Storage and Replication Impact of Your Application
To provide customers with the necessary information to evaluate how your application will impact their network environment, you must document the following:
A. The incremental disk storage that your application requires for its directory objects on full replicas.
B. The incremental disk storage that your application requires for its directory objects on partial replicas (global catalog servers.)
C. The network traffic that your application requires to replicate its updates to full replicas.
D. The network traffic that your application requires to replicate its updates to partial replicas (global catalog servers.)
Specific details below.
A. Incremental disk storage that your application requires for its directory objects on full replicas
Consider a deployment of your application on a directory that consists of a single domain running on a single domain controller. Quantify the incremental disk storage that your application requires for its directory data, i.e., the expected increase in space used in the NTDS.DIT file. If this increase is related to some parameters (e.g., the number of User objects or the selection of certain deployment options in your application), then give the storage as a function of those parameters.
If your application stores data in the configuration container then estimate configuration container usage separately from domain usage.
The formula should give an upper bound on the storage used, and as such need not be precise. If your application never uses more than, say, a megabyte of storage, you can say that.
In making your estimate, assume the default tombstone lifetime of 60 days.
When performing experiments to provide this estimate, use the esentutl utility to measure the space used in the NTDS.DIT file. Do not rely on the size of the file itself, because the file size includes unallocated space within the file.
To use esentutl, boot into Directory Services restore mode, open a command window, and type:
C:> esentutl /ms /8 c:\winnt\ntds\ntds.dit(substituting the actual path name of your DIT file into the line above.) The "owned" pages listed in the output are the ones in use. Each page is 8 k bytes.
The results will be more consistent/meaningful if you perform an offline defragmentation (in Directory Services restore mode, run ntdsutil, select "files" mode, run the Compact To command) first, then run esentutl on the file that results from the defragmentation.
B. Incremental disk storage that your application requires for its directory objects on partial replicas (global catalog servers)
Consider a deployment of your application on a directory that consists of two domains, A and B, running on two domain controllers. Suppose your application stores all its data on the first domain controller, for domain A. This data then replicates to the second domain controller, for domain B, which is a global catalog server and, therefore, holds a partial replica of domain A.
Estimate the incremental disk storage that your application requires for its directory data on the second domain controller, as in the previous item.
If your application stores data in the configuration container then subtract out its configuration container usage; the estimate is of the increased size of the partial replica of domain A on the global catalog server.
C. Network traffic that your application requires to replicate its updates to full replicas
Consider a deployment of your application on a directory that consists of a single domain running on two domain controllers in one site. Suppose that your application performs all its updates against one domain controller, and Active Directory replicates those changes to the other domain controller.
Quantify the network traffic that your application requires to replicate its updates. If this traffic is related to some parameters (e.g., the number of User objects or the number of times certain application-specific operations are invoked by users), then give the traffic as a function of those parameters.
If your application stores data in the configuration container, then estimate configuration container replication separately from domain replication.
The formula should give an upper bound on the network traffic, and as such, need not be precise. If your application never uses more than, say, 100 kilobytes of network traffic per day, regardless of how your application is used, you can just say that.
If the network traffic generated at the time your application **** is installed is significantly different than the network traffic in steady-state operation of your app, then estimate the two conditions separately.
To perform this measurement, use the "DRA outbound bytes total since boot" performance counter under the "NTDS performance object." Because this counter is a total, you want to report the difference in the values its holds before and after replication.
D. Network traffic that your application requires to replicate its updates to partial replicas (global catalog servers)
Consider a deployment of your application on a directory that consists of two domains, A and B, running on two domain controllers in one site. Suppose your application performs all its updates against the first domain controller, for domain A, and Active Directory replicates a subset of those changes to the second domain controller, for domain B, which is a global catalog server and, therefore, holds a partial replica of domain A.
Estimate the network traffic as in the previous item.
If your application stores data in the configuration container, then do not include configuration container replication traffic; the estimate is of the replication traffic to maintain the partial replica of domain A on the global catalog server.
Note If your application only writes a small fixed set of objects (under 100 K bytes of data total) to the directory and only updates these objects under unusual circumstances (e.g., only when a service is moved from one machine to another), then you can just say so without providing more detailed documentation.
3. Document Your Application's Use of Objects and Attributes in the Base Schema
Directory-enabled applications often leverage information already present in the directory; sometimes they extend this information. Customers want to understand these dependencies to help anticipate and avoid bad interactions between applications.
If your application depends upon directory objects that it does not create, you must document these dependencies:
What optional attributes does your application read from objects that it does not create?
What attributes does your application write to objects that it does not create?
If your application creates all of its own directory objects, this documentation requirement does not apply. However, if you create or modify anything in the configuration container, then you must fully document your usage. In this case you must specify object class, reason for the modification and/or addition, and location within the configuration container.
4. Information Stored in Active Directory Must Be "Globally Interesting"
Information in Active Directory must be "globally interesting," meaning the information is useful to a large number of users in the enterprise and needs to be highly available to those users. Examples include service connection points for enterprise resources such as printers and "white pages" information such as telephone numbers, pager numbers and e-mail addresses, so users in the enterprise can find the information easily and efficiently.
By contrast, Active Directory is not an appropriate store for information that is of local interest only, because replication of Active Directory consumes network bandwidth. For example, items that should not be stored in Active Directory include the names of local files on the user's computer, the user's currently selected e-mail message, and perfmon data.
5. Attribute Values Must Not Exceed 500KB in Length, and the Total Object Size Must Not Exceed 1MB
Active Directory does not support streaming of attribute values and is not appropriate for very large data. For this reason, the maximum length of an attribute value stored in Active Directory must not exceed 500KB in size, and the total object size must not exceed 1MB.
6. If You Extend the Schema, Adhere to the Schema Extensibility Rules
The purpose of this requirement is to ensure that applications that extend the schema do so in a consistent manner and that schema extensions are well documented. Schema extensions can be a potential source of conflict among applications because schema extensions are designed independently by different software vendors and application writers. Microsoft recommends that customers strictly control schema updates in their organization.
If your application extends the Active Directory schema, it must adhere to the rules specified in this section to prevent such conflicts. The rules are divided into the following categories:
A. Installation of schema extension
B. Documentation of the schema
C. Specification of the Schema-ID-GUID
D. Schema Object Naming
E. Specification of Link ID
Please see the "Extending the Schema" chapter of Active Directory Programmer's Guide for more information on schema extensibility.
A. Installation of schema extensions
If your application requires schema extensions:
The installation of the schema extension must be performed either by a separate program or with a separate option in your regular installation program.
The schema installation program must allow the user to exit the program prior to making changes to the schema.
This allows customers to perform the schema update separately and in advance of the rest of the installation.
We recommend that schema extensions be made programmatically in most cases, though other methods, such as use of LDIF scripts, may be used.
B. Documentation of the schema
You must provide documentation of your schema extensions in the form of a well-formed and valid extensible markup language (XML) document (see Endnote 3). This documentation must be available on your Web site. A pointer to this Web site must be present in the product documentation that accompanies the application.
You must use the utility schemadoc.exe to generate the XML-formatted documentation for your schema extensions. This tool is available at https://msdn.microsoft.com/certification/download.asp. Given the DNS name used to name your schema elements, this utility will generate a well-formed XML file with information about your schema extensions and a tag representing each of the three pieces of information that you need to provide.
Description of each new class and attribute with its expected use.
Expected update frequency and expected size of the attribute, which allows the customer to make calculations of replication impact.
Envisioned security privileges required to administer (create instances, make changes to values, delete instances) the attribute/class.
Note To help customers identify the impact of installing an application in their environment, reduce the time to deployment, and reduce support calls to you, Microsoft will provide a directory of schema extensions made by Windows 2000 Certified applications. This directory will contain links to your schema documentation on your Web site.
C. Specification of the schema-ID-GUID
For efficiency reasons, each Active Directory schema object is identified by a Globally Unique Identifier (GUID) in addition to an Object Identifier (OID). GUIDs are fixed length and can be dealt with more efficiently than OIDs. Active Directory uses OIDs for interoperability with external clients and GUIDs internally for efficiency.
When extending the schema, you must specify the value of the schemaIDGUID attribute on each classSchema and attributeSchema object in addition to the OID. This ensures the schemaIDGUID attribute is identical across Active Directory installations.
D. Schema object naming
You must adhere to the following rules with respect to schema naming for both the common-name (cn) and the LDAP display name (ldapDisplayName) of schema objects.
Start with the name of your company in lower case.
The next token in the CN must be a hyphen.
Following the hyphen, specify an attribute or class name that is unique within your company.
The following table illustrates an example:
| Company Name | Attribute or Class Name |
Common-Name (cn) | LDAP-Display-Name (lDAPDisplayName) |
| Microsoft | VoiceMailID | microsoft-VoiceMailID | microsoft-VoiceMailID |
You must register this name with Microsoft, using the following Web site:
https://msdn.microsoft.com/certification/ad-registration.asp. There will be a nominal charge for registration to cover costs; your registration is only complete after you receive notification from Microsoft that it is approved.
Exception If you have existing proprietary LDAP names already established for your application or its predecessor, your application may be exempted from this naming convention, provided that you register the existing proprietary names with Microsoft by June 1st, 2000. To apply for this exception, see https://msdn.microsoft.com/certification/ad-registration.asp.
Note The documentation requirements above still apply.
E. Specification of link-ID
Active Directory supports attribute values which reference other objects in Active Directory. This provides a way of representing relationships among objects in Active Directory. For example, members of a group are linked to the objects that represent the members, or the manager attribute of a user is linked to the object representing the manager of the user. Using linked attributes, you can find the groups that a user is a member of or the direct reports of a manager.
If you require linked attributes, you must obtain a Link-ID from Microsoft using the tool at https://msdn.microsoft.com/certification/ad-registration.asp.
How to Pretest Applications for Active Directory Support
To Pretest Appropriate Usage of Active Directory (Requirement 1A)
Install Active Directory, by running DCPROMO on a Windows 2000 server
Install your application
Verify that the client side of your application binds to the server resource
Modify the server binding information in Active directory so the data is different, but remains valid
Verify that the client side of your application binds to the "new" server resource and not a cached copy of the "old" resource
Modify the server binding information in Active directory so some data is invalid
Verify that the client side of your application does not bind to the server resource
To Pretest That Your Application Is Capable of Using Information from Active Directory (Requirement 1B)
If you are duplicating information that is in Active Directory and Active Directory is the authoritative source for this information:
Ensure that you can synchronize data that is duplicated in Active Directory with information in your application's data store OR
Verify that you have a documented a way of getting at this information from your application data store
To Pretest That Your Application Adheres to Schema Extensibility Rules (Requirement 6)
A. Use the schema extension option of your setup program to install your application's schema extensions. Then on a different machine install the application (this time without running the schema extension option).
B. Use schemadoc.exe to export your schema extensions out of Active Directory and ensure it is the same as that on your Web site and that it is complete. Also, verify that the documentation that accompanies your application includes a link to this Web site.
C. Install your application on a different Active Directory forest and ensure the schema-ID-GUID for each schema extension is the same for the two forests. You can do this by comparing the schema document generated by running schemadoc.exe on each of the forests.
E. Confirm that the link IDs you have used are those you got from Microsoft.