13.1 What Is Active Directory?

Active Directory is the directory database used by Windows Server 2003 to control the collection of user, group, and computer accounts used for authentication and authorization. Active Directory centralizes the administrative task of creating, modifying, removing, troubleshooting, and securing all accounts in the IT infrastructure.

Active Directory consists mainly of domain controllers, member servers, client computers, user accounts, and group accounts. Some objects represent physical objects, such as a computer account representing a person's laptop, while other objects represent logical entities, such as groups, which help administrators control access to resources throughout the IT infrastructure.

The chief purpose of Active Directory is to provide centralized administration and access control over accounts and other objects, plus ultimate control over your desktops with the use of Group Policy.

13.1.1 Benefits of Active Directory

With so many companies moving to Active Directory over the past four years, there must be compelling and overwhelming reasons for the mass migration. There are indeed, especially if you are coming from a Windows NT environment. Next, I'll describe some of the most compelling reasons to move to Active Directory in case you haven't already.

13.1.1.1 Extensible database

A Windows NT domain is not very elaborate and is very static. The Security Accounts Manager (SAM) offers no options to add additional information to user, group, or computer accounts. The only real option is to use Exchange 5.5 to extend the information that we associate with user accounts. Active Directory fixes this by giving the administrator the flexibility to add custom properties (or as they are more properly referred to, attributes) to almost any object that is stored in the Active Directory.

Active Directory user accounts have dozens of attributes ranging from employee ID to fax number. These new attributes are added to the schema and then populated by using Active Directory Services Interface (ADSI) or a Lightweight Directory Access Protocol (LDAP) interface. With some of the new attributes that are added, such as social security number, you will need to ensure that these attributes are secured. This can be accomplished by using the built-in security that is associated with Active Directory. Each Active Directory object has its own access control list (ACL), which controls who has permission to modify or read the object.

13.1.1.2 Multimaster domain

The multimaster domain concept is a radical new approach for a Microsoft directory service. With Windows NT domains, you were limited to having only a single computer in the domain on which administrators could perform updates to objects. This computer is called the primary domain controller (PDC) in the Windows NT domain. The biggest problem with this was that if the PDC was offline, or unavailable due to network problems, you could not update the database.

Active Directory eliminates this problem by allowing an administrator to add, modify, or delete objects on any domain controller in a domain. Therefore, as long as there is at least one domain controller online, updates can be made to the database. On the backend of the multimaster domain model is a new replication technology that can reconcile multiple changes to a single object from different sources by accepting only the latest change. When you boil it down, the last domain controller to make a change to an object wins.

13.1.1.3 Object support

Windows NT by default could support only a very limited number of objects; somewhere around 20,000 user, computer, and group accounts. For many organizations, this 20,000-object limit was reached quickly, forcing administrators to take the chance of modifying the registry size for the domain or to create additional domains just to accommodate the number of objects.

With Active Directory, the number of objects that is supported is in the millions, which should accommodate almost any company. There have been tests that have taken the number of objects in Active Directory to nearly a billion. Granted, there will be some overall performance degradation with this many objects, but the possibility exists.

13.1.1.4 Software deployment with GPOs

Most companies have hundreds of applications that they must support throughout the organization, so ideally they need a simple and efficient method to deploy software. Active Directory, in conjunction with Group Policy Objects (GPOs), provides that solution. By using GPOs, you can target software to specific user or computer accounts. What this means is that you can ensure that all users in the marketing department have the special marketing software package, without having to manually install that software on each computer.

From a security or management standpoint, since the software is deployed using GPOs, only the user or computer accounts that are targeted by the GPO will be able to use the software application. This ensures that you not only meet the software licensing agreements but also control which users have access to potentially dangerous software or to software that is used to access private and confidential data for the company. Group Policy was covered in more depth in Chapter 5.

13.1.2 Security Benefits of Active Directory

Beyond the directory service and administration benefits that Active Directory provides are some security benefits that have persuaded many companies to make the move to Active Directory. However, like almost anything else that is security related, you really have to know how to use the security features to take greatest advantage of them after Active Directory is installed. In other situations, a security feature might require specific operating systems, which may prevent other legacy operating systems from running properly.

13.1.2.1 Kerberos

Kerberos was first introduced for a Microsoft domain with Windows 2000 Active Directory. Having Kerberos as the authentication protocol for your domain provides better security than its predecessor, NTLM. Here are the main benefits that Kerberos provides for Active Directory:

Efficient authentication to member servers: Because the client computer receives information from the domain controller when it initially logs on and by subsequent touches to the domain controller, the member servers that the client is communicating with do not need to connect to a domain controller to authenticate each client. The member server will rely on the credentials that the client computer initially obtains from the domain controller for accessing the resources located on the server. The client computer needs to obtain credentials for a particular server only one time, and then it can reuse these credentials for the duration of the logon session.
Mutual authentication: The Kerberos protocol process is responsible for ensuring that the client computer is who it says it is and the server is who it says it is. This provides a much more secure environment than NTLM authentication, which did not provide any mechanism for client computers to verify a server's identity. This promotes a more secure environment and reduces the possibility of someone pretending to be a server in the domain.
Delegated authentication: Kerberos has a built-in proxy option that will allow a client to pose as a user identity when connecting to certain network services. This allows a frontend service to connect to a backend service with a client impersonation. Both Kerberos and NTLM provide this option when they are impersonating the client locally, but only Kerberos provides this option for services that reside on different computers.
Interoperability: Now that Microsoft supports industry standards for name resolution (DNS), directory structure (LDAP), and authentication (Kerberos), interoperability with other platforms and devices is more easily achieved.

13.1.2.2 Trusts

Kerberos is the foundation for the trust model in an Active Directory forest. For those of you who are coming from a complex array of Windows NT domains that needed to trust one another, this is wonderful news. The old Windows NT trusts are:

Manual: Any trust created between Windows NT domains is manual. This means that the trust must be established by the administrator. During the creation of the trust, both domain names need to be known, and a trust password is established to verify the trust. The password is not needed after the initial creation of the trust.
One-way: The trust allows traffic to flow in only one direction for resource access. For example, if DomainA trusts DomainB, then the user accounts in DomainB could be given permission to access the resources in DomainA. However, the user accounts in DomainA could not be given permission to access the resources in DomainB, unless another trust was established from DomainB to DomainA.
Nontransitive: A transitive trust allows a common domain to span two nonadjacent domains. Figure 13-1 illustrates nontransitive trusts: DomainA trusts DomainB and DomainB trusts DomainC. If the trusts were transitive, DomainA would also trust DomainC. Windows NT trusts are nontransitive. This means that the only way that DomainA would trust DomainC is to create another explicit trust between DomainA and DomainC.

Figure 13-1. Nontransitive trusts

NTLM authenticated: The trusts used by Windows NT use NTLM authentication, which is proprietary to Microsoft and reduces the interoperability needed to communicate effectively with other operating systems. Any external trust that goes from a Windows Active Directory domain to any domain (Windows NT, Windows 2000, or Windows Server 2003) outside of the forest will use NTLM trusts.

Active Directory domains break almost every rule that the Windows NT domain trust exhibited. The trusts internal to the forest that are inherent to Active Directory domains are:

Automatic: When a domain is introduced into an Active Directory forest, it is placed in the hierarchy of the namespace. This placement also produces a trust relationship. If the domain is a child domain to an existing domain, the child domain has an automatic trust established with the parent domain. If the domain is the first domain in a new tree of domains, then the domain automatically has a trust relationship with the adjacent domain at the top of the next tree in the forest.
Two-way: To reduce the administrative overhead and logical connections required to maintain one-way trusts, Active Directory implements two-way trusts. These trusts allow users in both domains that are involved in the trust to have the ability to be given permission to access resources in the other domain. This in no way compromises any security; it only provides an easy solution for administrators to have an option to give users access to resources if they need to.
Transitive: All trusts within an Active Directory forest are transitive. This produces an environment that allows all users the ability to gain access resources in every domain in the entire forest. This feature reduces the number of trusts needed, as well as reduces the administration requirements to create, maintain, and troubleshoot nontransitive trusts.
Kerberos authenticated: Kerberos is the driving force behind the other benefits of the Active Directory trusts. Because Kerberos provides the mutual authentication, the trusts can be two-way and transitive.

13.1.2.3 Smart card support

Active Directory, Windows 2000, Windows XP Professional, and Windows Server 2003 all support smart card authentication. When a smart card reader is installed on a computer, a new graphical identification and authentication (GINA) will be presented to the user, allowing for the PIN to be input after the smart card is inserted into the reader. I covered smart card technology in depth in Chapter 10.

13.1.2.4 Group Policy Objects

It is impossible to talk about providing security for Active Directory without a lengthy discussion on Group Policy Objects (GPOs). There are two default GPOs in every domain. These GPOs always configure the same settings by default. This provides an administrator with a starting point for additional settings in these GPOs, as well as the foundation to create additional GPOs, if necessary. The two default GPOs are:

Default Domain Policy: This GPO is linked to the domain and is responsible for establishing the Account Policies for domain user accounts. This GPO is unique in that it is the only location in which you can configure account policies for domain users.
Default Domain Controller Policy: This GPO is linked to the only OU in a freshly installed domain, the Domain Controllers OU. This GPO applies only to domain controllers and is designed to configure the user rights for the domain controllers. This provides the base security of who can do what on a domain controller.

GPOs are so integral to the security of the Active Directory and computers on the network that Chapter 5 is dedicated to them. It should provide an in-depth understanding of what a GPO is and what GPOs can do in your Active Directory domain.

13.1.2.5 Delegation

The lack of delegation options has frustrated more than one domain administrator during the Windows NT era. The ability to give users just a few privileges has never been a viable built-in option before Active Directory. With groups that provide widespread capabilities over the entire directory, it was almost impossible to implement delegation in a Windows NT domain. Groups such as Account Operators and Server Operators gave too many privileges for the accounts and servers over which they had reign.

With Active Directory delegation (or delegation of administration as it is sometimes called), the administrators responsible for Active Directory have the capabilities to provide almost any degree of granular delegation they desire. This is accomplished by configuring security permissions on objects within Active Directory in such a way that only a few user accounts have the privilege to control a limited set of options for the objects.

For example, assume that you are the domain administrator for an Active Directory domain. The marketing department is constantly working on new projects, which require different employees from that department to be moved from group to group. These groups are used to assign permissions to access the resources for the new projects. However, when these new projects are developed, you are asked to create and configure the members of these groups. It is always the marketing director who walks you through who should be in what group, as well as the group structure itself. What you would like to do is remove your role from the creation, modification, and deletion of groups for the marketing department projects. Of course, you don't want the "standard marketing groups" to be controlled by the marketing director, but these special project groups are an ideal opportunity for your control to be delegated to the director. The standard marketing groups are used by the administrative staff to control access to network resources both in the marketing group, as well as for the entire company. For the solution to this problem, you can give the marketing director delegated permission to control just the groups for the marketing projects but not the standard marketing groups. This delegated privilege can include creation, modification, and deletion of these groups, and you can always remove some of the delegated privilege if the director can't seem to control creation or deletion of the groups. If that happens, you can restrict the director to modifying the group membership, which still removes much of the administrative burden from your plate.

This is just one example of delegation. Delegation can include control over user accounts, group accounts, computer accounts, GPOs, organizational units, and more. Delegation is a very powerful feature of Active Directory, and planning for its design is essential to a secure implementation. I will go further into delegation later in this chapter.