Active Directory doesn’t replace a relational database or the registry, so what kind of data would you store in it?
- With Active Directory you get hierarchical data. You can have containers that store further containers and objects, too. Containers themselves are objects as well.
- The data should be used for read-mostly. Because of replication occurring at certain time intervals, you cannot be sure that you will read up-to-date data. You must be aware that
in applications, the information you read is possibly not the current up-to-date information.
- Data should be of global interest to the enterprise, because adding a new data type to the schema replicates it to all the servers in the enterprise. For data types of interest to only a small number of users, the domain enterprise administrator normally wouldn’t install new schema types.
- The data stored should be of reasonable size because of replication issues. It is fine to store data with a size of looking the directory, if the data changes only once a week. However, if the data changes every hour, data of this size is too large. Always think about replicating the data to different servers: where the data gets transferred to and at what intervals. If you have larger data, it’s possible to put a link into Active Directory and store the data itself in a different place.
To summarize, the data you store in Active Directory should be hierarchically organized, of reasonable size, and of importance to the enterprise.
Active Directory objects are strongly typed. The schema defines the types of the objects, mandatory and optional attributes, and the syntax and constraints of these attributes. As mentioned earlier, in the schema, it is necessary to differentiate between class-schema and attribute-schema objects.A class is a collection of attributes. With the classes, single inheritance is supported. As you.can see in Figure 46-3, the user class derives from the organizational Person class, organizational.Person is a subclass of person, and the base class is top. The class Schema that defines a class describes the attributes with the system May Contain attribute.
Figure 46-3 shows only a few of all the system May Contain values. Using the ADSI Edit tool, you can easily see all the values; you look at this tool in the next section. In the root class top you can see that
every object can have common name (cn), displayName, objectGUID, when Changed, and when Created attributes. The person class derives from top. A person object also has a userPassword and a telephoneNumber. organizationalPerson is derived from person. In addition to the attributes of person, it has a manager, department, and company, and a user has extra attributes
needed to log on to a system.