Active Directory

Definition of Active Directory in The Network Encyclopedia.

What is Active Directory

The directory service for the Microsoft Windows 2000 network operating system. Active Directory consists of both a database and a service.

Active Directory is a database of information about resources on the network, such as computers, users, shared folders, and printers. It is also a service that makes this information available to users and applications.

Active Directory provides the basic features needed for an enterprise-level directory service, including an extensible information source, naming conventions for directory objects, a common set of policies, and tools for administering the service from a single point of access. Administrators can configure Active Directory to control access to network resources by users and applications.

How it works

The basic element of Active Directory is the object. An object can represent a user, computer, printer, application, file, or another resource on the network. Active Directory objects possess attributes, which are their properties. For example, some user attributes might include first name, last name, e-mail address, and phone number. Some attributes must have mandatory values, while others can be left undefined. Attributes of a printer might include the location of the printer, the asset number of the printer for accounting purposes, the type of printer, and so on.

A special type of Active Directory object is the organizational unit (OU). An OU is a type of object that can contain other objects. An OU can either contain a specific object, such as a user or an application, or it can contain another OU. Using OUs, you can organize Active Directory into a hierarchical directory of network information based on the X.500 directory recommendations of the International Telecommunication Union (ITU). You can assign users permissions on subtrees of OUs for management and resource access purposes.

Organizational units are contained within domains, which are the basic security and organizational structure for Active Directory. Every object in Active Directory must belong to a domain. Domains usually mirror the organizational structure of your enterprise and act as a security boundary in your enterprise. For example, privileges granted in one domain are not automatically carried over to another domain. Domains can be joined into larger structures called domain trees using two-way transitive trusts, and these tree structures can be grouped into domain forests for larger enterprises.

Discretionary access control lists (DACLs) and system access control lists (SACLs) protect Active Directory objects. DACLs and SACLs specify which user or application has permission to access attributes of directory objects, and work in a similar fashion to access control lists (ACLs) that are implemented in the version of NTFS used in Windows NT 4.0. DACLs and SACLs can be used to propagate their permissions to connected directory objects. They also provide a simple way for administrators to grant access and usage rights for Active Directory to users and groups.

Active Directory has a set of rules governing which objects can be stored in the directory and which attributes these objects can possess. This set of rules is known as the schema.

Information in Active Directory is maintained for each domain on the network. Active Directory database information is stored and maintained on machines called domain controllers. This information is replicated automatically between domain controllers to ensure that every portion of the distributed directory is up-to-date. By default, the replication of updates to Active Directory occurs automatically every five minutes. Automatic replication of Active Directory information occurs only within the security boundary of a specific domain. Domain controllers in one domain do not automatically replicate with those in another domain.

Active Directory provides network administrators with centralized administration of all information about resources on the network, and it provides both users and administrators with advanced search capabilities for locating resources on the network.

The default naming convention for objects stored in Active Directory is an Active Directory canonical name of the object. This defines the object’s position in a domain tree from left to right, starting with the object’s name and delimited by slashes. For example, the User Account MSmith in the Marketing organizational unit of the northwind.microsoft.com domain would have the Active Directory canonical name:

msmith\users\marketing\northwind.microsoft.com

Active Directory supports non-DNS naming conventions for interoperability with non-DNS environments. An example is the Lightweight Directory Access Protocol (LDAP) naming convention. An LDAP URL is composed of the name of the server with the distinguished name of the object appended to it. Other naming conventions include the following:

  • User principal name:
    This convention consists of the user’s Security Accounts Manager (SAM) account name with an object’s user principal name suffix appended to it. The user principal name suffix is the name of the domain tree or the name of the domain above the object in the domain tree.

     

  • Request for Comments (RFC) number 822 Name:
    This naming convention is essentially the user’s e-mail address.

     

  • Universal Naming Convention (UNC):
    This convention can be used for shared resources.

     

Before implementing Active Directory in your enterprise

Before implementing Active Directory in your enterprise, you will need to gather information about the structure of your organization because Active Directory usually mirrors this structure in some fashion.

A good way to proceed is to use a centralized planning approach with a team consisting of both technical and management representatives. You must develop a naming strategy, plan your domain structure, and consider how you will delegate administrative duties concerning Active Directory.

When you delegate administrative control to Active Directory, do so at the OU level instead of at the individual object level. This makes it easier to control portions of the OU hierarchy within Active Directory. In particular, you probably want to delegate control to individuals responsible for creating users, groups, computers, and similar objects.

Want to know more about Active Directory? Try this list of Active Directory books from Amazon: active directory

Consider the speed

Consider the speed of the various links between your different geographical locations, and how any systems that are not interoperable with Active Directory will be integrated into your new system.

You should also profile your user community to determine what sort of domain hierarchy you will be implementing. Also consider integrating your Domain Name System (DNS) zone information into Active Directory because this will store your DNS zone information in the distributed Active Directory.

Plus, it will facilitate and simplify updates of zone information through replication of domain controllers.

Where to locate domain controlers

An important planning issue is determining where to locate domain controllers and global catalog servers for your enterprise. This is because after Active Directory is installed and configured, the majority of Active Directory traffic is related to Active Directory clients querying Active Directory for information.

Directory replication traffic is usually a less important consideration, unless the organization is in a constant state of flux. Placing a domain controller at each site will optimize queries but can increase replication traffic. Nevertheless, placing a domain controller at a site that has users in that domain is usually the best solution.

If the domain tree is large, you should not place a global catalog server at each site because this can create a lot of replication traffic. Place global catalog servers only at large regional sites.

Remember that replication of modifications made to your Active Directory might take some time to propagate throughout your enterprise. For example, if you create a new user account object, it might be a few minutes before the user can actually log on to the network using the account.