When you break it down, Active Directory is a type of database, but one built as a “directory.” The difference between a relational database and a directory is that the former is optimized for updating, while the latter is optimized for reading. In this manner, Active Directory was developed with the understanding that the objects contained within the directory would not be changing often, but would be used for users, computers and administrators to control, manage, and discover the organization’s resources.
One of Active Directory's most basic functions is that it provides a centralized repository for user account information. When an administrator creates a user account, the account information is held on a domain controller within the domain in which the user resides. All of the domain controllers within the domain will receive an identical copy of the user account so that the user is able to authenticate using any domain controller in the domain.
Any changes to the user account are made on one of the domain controllers and then sent to every other domain controller within the domain. This transfer of data is called replication. Replication of information can be a burden on the network, especially in environments with several thousand users, groups, computers, and other objects. To alleviate the replication burden on the network, Active Directory replicates only the attributes that have been changed, and not the entire object.
To get a good understanding of how Active Directory works, you must first understand what the schema is and the role it plays in the directory service. The following section will outline the major roles of the schema.
Schema
The schema (i.e., a structured framework or plan) acts as the building blocks of Active Directory, much like DNA molecules are the building blocks for our bodies. Just as our DNA holds all of the information necessary to build our leg, ears, hair, ear hair, etc., the schema holds all of the information needed to create users, groups, computers, and so on within Active Directory. The schema defines how each attribute can be used and the properties associated with the attribute. Take, for instance, a child’s toy that we have grown up with: LEGOs. When you first take a look at LEGO bricks, you see hundreds of tiny pieces that really don’t seem to represent anything. Some are short, some are long, and some are special shapes. These are the individual pieces, or building blocks, that will go into creating the buildings, cars, airplanes, and dioramas.
The Active Directory schema is pretty much the same thing. If you look within the Active Directory Schema snap-in you will see hundreds of entries that are used when creating objects within Active Directory. As you expand the Active Directory Schema section of the tool, you will see the window that contains classes and attributes. The entries known as attributes allow you to create new objects or modify existing objects within your directory. To add the Active Directory Schema snap-in to a Microsoft Management Console (MMC), you will first need to register the dynamic link library. To do so, open the Run line or use a command prompt on the domain controller and type in regsvr32 schmmgmt.dll.
Attributes
To standardize Active Directory, the schema defines the attributes that can be used when creating objects. Unlike our LEGO bricks, however, these attributes are defined only once and can be used for any object. Defining the attribute once and using it for multiple objects allows for a standardized approach of defining objects, especially when searching for the attribute. Take the name attribute, for example; whenever an object uses the Name attribute you know that the name has to be at least one character in length and cannot exceed 255 characters. You would know this because of the syntax and rules that are applied to the attribute. There is a lot of information within this page, but right now we are interested only in the Syntax and Range area. Notice that the attribute is a Unicode string that has to be at least one character in length and cannot exceed 255 characters. Each attribute within the schema is defined in such a manner, although the syntax for each of the attributes could be different.
The properties for Bad-Pwd-Count are another attribute that makes up a user object. Notice that the X.500 Object Identifier (OID) is different from that of the name attribute.
Each attribute within the schema has to have a unique OID. These are registered and maintained by the Internet Assigned Numbers Authority (IANA). Once assigned, the OID should not be used by any other attribute. Within Active Directory, the default attributes are already assigned OIDs, and those OIDs are protected in a way that will not allow another application to overwrite them. New attributes will need to be assigned an OID. If you are adding an attribute for use in an object, you should register it with the IANA to safeguard the attribute and to make sure that it does not step on any other attributes. Registration is free, and as long as your OID is unique, you should be issued an OID for your attribute. The attributes that Microsoft uses are all within their own OID range, which starts with 1.2.840.113556. For a complete list of the registered OIDs, visit
http://asn1.elibel.tm.fr/oid/index.htm and perform a search on the OID. If you have registered an OID, it will appear in this database once the entry is added.
Within an attribute’s properties, you will find several check boxes that you can select. Each of them is described in the following list:
Attribute Is Active
You can deactivate attributes that you no longer need within Active Directory. Note that the default attributes cannot be deactivated, nor can attributes that are still in use within an object.
Index This Attribute
If this is an attribute on which you are going to allow searches, you may want to index the attribute to increase the search responsiveness.
Ambiguous Name Resolution (ANR)
When you select this option, you allow a Lightweight Directory Access Protocol (LDAP)–based client to resolve a request when only partial data is available.
Replicate This Attribute to the Global Catalog
Not every attribute needs to reside within the global catalog. The rule of thumb is, if you need to locate an object based on an attribute or if the object’s attribute is needed within another domain, you should add it. Otherwise, to reduce the total size of the domain partition you should not add in any superfluous attributes.
Attribute Is Copied When Duplicating a User
When you copy a user account, several attributes are copied from the original account to the new account. If you want the attribute to copy, select the box. Do note that many attributes are unique to a user, so select this option with care.
Index This Attribute for Containerized Searches
If you select this option, the attribute can be indexed for searches within containers, such as organizational units (OUs), in Active Directory.
Object Classes
An object class is a defined grouping of attributes that make up a unique resource type. One of the most common object classes is the user class. Use the user object class as the template for a user account. When you create a user account, the attributes that are defined for the user object class are used to define the new account. Information that you populate within the Add User wizard or enter within the command line become the properties within the attributes. If we go back for a minute to the LEGO metaphor, you can use some of the brown blocks available to create a roof on a house, some red bricks to make the walls, and tan bricks to make a door.
The clear pieces can be used as windows and the white pieces form the porch. Each of these individual items (the bricks, the color of the bricks, the shape of the bricks, and the placement of the bricks) is considered an attribute. Putting these attributes together forms the object class “house.” When you build your first house, you have built your first object. Subsequent houses will have the same attributes, but you may build the porch with tan pieces instead of white ones. So, when I create a user account for Maria, that user account will have unique values stored within the attributes for her user account. Bob’s user account will be created using identical attributes, but will not have the same values within each attribute. Maria’s phone number may be 555.1234, and Bob’s 555.9876.
Not all of the attributes that make up an object class are shown within the administrative tools. Many of them hide behind the scenes and will rarely, if ever, need to be changed. One such attribute is the user’s Security Identifier or SID. The user’s SID will change when a user is moved from one domain to another, but will not change while the user remains within a domain. The Active Directory Users and Computers management tool does not have the ability to change this attribute. A default set of attribute fields appears within the utilities, and if you decide to make an attribute available for updating, you may need to programmatically add the fields to the utilities.
Attributes are defined as mandatory or optional. Mandatory attributes have to be populated, or the object will not be created. One such attribute is a computer’s name. Optional attributes do not necessarily need to have values. Attributes such as Manager within a user object does not need to be populated, but it is always nice to include that information. The more complete the information, the more useful Active Directory becomes.
The Two Sides of AD
Active Directory has both a logical side and a physical side, and each one plays a very important role. The physical side is made up of the domain controllers and physical locations where the domain controllers reside. When you promote a system to domain controller status, you will usually place that domain controller close to the user population that will use it for authentication and access. Domain controllers need to communicate with one another to share the information they have. The logical side is a little more nebulous; as well as containing the objects that define how the resources are organized and accessed, the logical side contains objects within Active Directory that define how the domain controllers will communicate with one another. Active Directory sites and site links define which domain controllers will replicate directly with each other and which ones will have to communicate indirectly through other domain controllers.
Domains dictate the replication scope. When you create a domain, the domain partition is replicated only to domain controllers from the same domain. The domain partition is not copied to domain controllers outside of the domain. This allows you to partition your directory service and reduce the size of the database file that holds all of the forest’s objects.
Organizational units are used to organize objects for easy administration and to manage those objects easily using group policies. To have efficient administration of resources, you should design your Active Directory with administration in mind. If you are in the process of rolling out Active Directory, be sure to develop a detailed plan for the rollout. Without a good design, Active Directory may not work efficiently for your environment. If your design does not meet the needs of your organization, you may be faced with either suffering through working with an inadequate design or rebuilding your Active Directory infrastructure from the ground up. Neither of these options will sit well with your user base or the management of the company.
Source of Information : Sybex Mastering Active Directory for Windows Server 2008
No comments:
Post a Comment