Lesson 2: Working with Active Directory Domain Accounts and Security Groups | MCSA/MCSE Self-Paced Training Kit (Exam 70-214): Implementing and Administering Security in a Microsoft Windows 2000 Network (Pro-Certification)

Lesson 2: Working with Active Directory Domain Accounts and Security Groups

A domain is a group of computers that share the same database of security accounts. In Windows 2000, domain user accounts are stored in the Active Directory directory service on domain controllers, along with domain security groups, computer accounts, and numerous other security objects such as Group Policy Objects and sites. Domains allow administrators to manage user accounts and security groups centrally for all computers that are members of the domain. User accounts in the domain are valid on all computers that are members of the domain and need not be established individually on each computer. This lesson will teach you how to manage and administer domain user accounts and domain security groups for optimal use in large environments.

After this lesson, you will be able to

Create and manage domain user accounts
Create and manage domain security groups
Select the correct type of domain security group for a specific purpose

Estimated lesson time: 30 minutes

Working with Domains

Domains are the mechanism within the Microsoft Windows 2000 operating system for achieving Single Sign On (SSO) functionality throughout a network. Single Sign On means that an individual can use a single account name and password on every computer throughout a network (although including computers running non-Microsoft operating systems in an SSO environment requires third-party software). By creating a domain and joining workstations to it, you are telling workstations to trust the accounts stored on domain controllers as if they were local accounts on the computer.

When multiple domains are created in the same Active Directory service, the domains automatically trust each other's user accounts. Therefore, security principals from one domain may be included in the ACLs and security groups of the trusting domain. This is called a trust relationship, and you can explicitly change the trust relationships that are automatically created to determine exactly how accounts can be used in other domains.

Like local accounts, domain user accounts and security groups are represented internally by SIDs. Domain SIDs are constructed in exactly the same way as local SIDs are constructed, except that the Active Directory service stores user account data instead of the SAM.

Authenticating Domain User Accounts

Domain user accounts are stored in the Active Directory database. When a client is a member of a domain and a user attempts to log on using a domain user account, the Winlogon process on the local machine sends the user's name and encrypted password for authentication to the Active Directory authentication server. The Active Directory authentication server checks the credentials against those stored in the Active Directory database and, if they match, sends back a Kerberos ticket containing the user's SID and domain group SIDs, so that the local computer can create an access token for the user. Kerberos tickets are explained in the next section.

Only computers that are members of the domain or a trusted domain can authenticate in the domain. Domain client computers have computer accounts stored in the Active Directory that also have computer names, secret keys (like passwords that are automatically created by the system), and SIDs. A computer that is not a member of a domain cannot directly authenticate with a domain controller because it does not have a computer account in the domain. When you join a computer to a domain, the domain controller automatically creates the computer's account. The domain controller and the computer negotiate to create the SID and the computer account's password automatically when the computer account is created.

Domain controllers themselves do not have local user accounts or local groups. The SAM is disabled when Active Directory is installed on a domain controller. Therefore, only Active Directory domain account holders can log on to a domain controller.

Kerberos

Understanding logon authentication in Windows 2000 requires an understanding of Kerberos. Kerberos is an authentication service developed at the Massachusetts Institute of Technology (MIT) for use in multi-vendor distributed networks of any size. Kerberos works very similarly to many manual authorization methods you may already be familiar with. For example, to gain access to a county fair, it is common to pay a fee at the gate for an all-day pass. You can then take your day pass to a ticket booth to receive tickets for a specific attraction, such as a Ferris wheel. Once you have your ride-specific tickets, you can provide them to the operator to gain access to the ride.

In Kerberos, the all-day pass is called a ticket-granting ticket (TGT), and it is provided to you when you log on to the domain by the Active Directory authentication service (the front gate). A TGT is valid for a specific period of time, usually eight hours. The attraction-specific tickets are called session tickets (or just tickets), and they are presented to you by the ticket-granting service (the ticket booth) on the domain controller whenever you request access to a specific service on a server. The servers themselves allow access if the session tickets are valid, and these tickets expire very rapidly, usually within five minutes. In Windows 2000, both the authentication service (AS) and the ticket-granting service (TGS) functions of the Kerberos Key Distribution Center (KDC) are run on domain controllers, so KDC is simply the Kerberos term for a domain controller. Figure 2.6 shows the Kerberos logon process.

In UNIX and Kerberos documentation, you'll see the term "realm" used to describe a domain. The terms are synonymous.

figure 2-6 the kerberos domain logon process

Figure 2-6. The Kerberos domain logon process

Now that you have an overview of the process, the specific details will make sense. Kerberos uses secret key encryption to prove the identity of valid client computers. Client computers must have been joined to the domain through a trusted process during which a secret key can be exchanged. In Windows 2000, this key exchange occurs automatically when a client computer is joined to the domain:

The client uses its secret key to encrypt the credentials of the user who is logging on. Because the server can decrypt them, it knows that the client computer that transmitted them is a member of the domain. The domain controller then compares the user's credentials to the information stored in the Active Directory. If they match, the user must have known the account holder's password and is assumed to be the account holder.
Once the KDC (the domain controller) has authenticated the user, it generates a ticket-granting ticket, which is essentially a ticket that proves to any computer in the domain that the user has already logged on. The TGT is encrypted using a secret key known only to the KDC, so its contents are not susceptible to compromise even by the client computer that holds it.
When a user needs to access a service on any server throughout the domain, the client computer sends its TGT to the TGS, which is also running on the KDC, and requests a ticket for the service in question. The TGS inspects the TGT, determines whether it is valid, and sends the client computer a service-specific session ticket that can be decrypted only by the destination server (and not by the client).
The client computer then presents this session ticket to the destination server, which is able to decrypt it because it was encrypted by the KDC using a secret key known only to the two servers. Because the client has a valid session ticket, the server trusts that it received the ticket from the KDC that it trusts, so trust is conferred upon the client, and access is granted to the service.

This process is shown in Figure 2.7.

figure 2-7 the kerberos resource access process

Figure 2-7. The Kerberos resource access process

Because Kerberos tickets are encrypted with a number derived from the current time, they can be decrypted only for a short period, five minutes by default.

Servers must be time synchronized within a domain because a difference of more than five minutes between the KDC and a server will cause tickets to expire and prevent users from accessing services on that server. Limiting the decryption time to short periods also prevents replay attacks where a hacker could sniff the contents of a session, decrypt a ticket, copy the ticket's contents, and then re-use it to gain access to a server.

Domain Transitive Trust

Kerberos also provides the ability for clients who are trusted in one domain to be trusted in another domain. When a user requests a session ticket from its KDC for a server in a foreign domain, the KDC sends a request for a session ticket to the remote KDC as if it were the client. The remote KDC will validate the local KDC's TGT and provide an encrypted session ticket. Because the session ticket is encrypted using the destination server's private key and not the local KDC's private key, the local KDC can provide that ticket to its client, and the client can provide the session ticket directly to the foreign server to gain access to it.

This process works no matter how many domains the trust has to transit. Each KDC in the trust hierarchy receives the request for a service ticket, mimics a client, and passes that request to the next server up. This process continues indefinitely until the KDC that is local to the target server, which creates the valid session ticket, is reached. That ticket is passed back from KDC to KDC until it reaches the KDC that is local to the client computer. That final KDC then passes the session ticket to the client computer, which can then contact the destination server directly using the session ticket. Authentication goes through each intermediate KDC, but once the client computer has been authenticated, access is direct. When the client computer has a valid session key, it contacts the destination server directly and begins to access resources.

These mechanisms are created and handled completely by the operating system. When a domain is added to Active Directory, Windows performs the exchange of cryptographic keys that is required for the two domains to trust one another. When client computers are added to a domain, Windows handles the exchange of cryptographic keys that allows the client computers to prove their participation in the domain to the KDC.

Administrators need not worry about the underlying mechanism of Kerberos, beyond understanding how it works and understanding that time synchronization is crucial to its operation.

Domain Logon Process

The specific sequence of events in a domain interactive log on is as follows:

The Winlogon service of the LSA collects the user name and password.
The client's LSA transmits the password name and encrypted password to the Active Directory KDC authentication service, which is integrated into the domain controller's LSA.
KDC queries Active Directory for the user's SID and the SIDs of domain groups to which the user belongs. KDC also queries the Global Catalog server in the domain for a list of universal security group SIDs to which the user belongs.
KDC AS creates a ticket-granting ticket (TGT) and embeds all the SIDs that apply to the user in the TGT.
KDC AS returns the TGT to the client computer's LSA.
LSA creates an access token containing all the user's SIDs.
LSA launches the local shell and passes the access token to it.

Domain Resource Access

When a client computer connects to a resource server and requests a resource, the client computer first contacts the KDC for the domain and retrieves a session ticket. The client then provides the session ticket to the resource server, which contains all the SIDs that apply to the user in that domain.

The server service for the resource server then constructs an access token to represent the user to local processes. The LSA on the resource server constructs the access token using the authentication data (the list of SIDs) contained in the session ticket, and any additional SIDs that the user is entitled to because of membership in a security group that is local to the domain and not present in Active Directory. The access token will then contain the complete credentials of the logged on user. After the access token has been created, it is associated with the user's session in the server service, and the user can then access resources within the user's own security context on the resource server.

Access tokens never travel over the network only encrypted session tickets containing the user's SIDs do. This ensures that access tokens themselves cannot be introduced to a computer by any means servers only generate them, they do not accept them from any source. This prevents the spoofing (or forging) of access tokens to circumvent security.

The resource server trusts the SIDs contained in the session ticket because it assumes that the session ticket cannot be forged and that it came from a domain controller that the resource server trusts. This trust is implicit because the resource server and the domain controller negotiated the secret key that was used to encrypt the session ticket if the server can decrypt it, it must have been encrypted by a domain controller that knew the correct key.

When a user connects to a resource server and requests resources on it, the service that provides the resource can check the user's credentials and verify the user's permission to access the service. The process works like this:

The client computer sends its TGT with a service request to the KDC.
The KDC validates the TGT (by decrypting it) and copies the user's SID and all universal and global group SIDs into a new session key.
If the client computer is in a different domain than the KDC is (because the ticket has been forwarded through the trust mechanism), the KDC queries its own Active Directory to find additional domain local group SIDs that might apply to the client and adds them to the session ticket.
The KDC encrypts the session ticket using the resource server's key. The session ticket is transmitted back to the client computer.
The client receives the session ticket but cannot decrypt it because it's encrypted with the target server's key. Because the ticket is encrypted, users on the client computer cannot elevate their own privileges by adding SIDs to a ticket.
The client computer forwards the session ticket to the resource server along with the specific service request.
The resource server LSA decrypts the session ticket, extracts the list of SIDs, and creates an access token for the client's use locally.
The resource server creates a service session using the access token created from the session ticket. The session is security-limited to the client's allowed list of SIDs. Any sessions or processes subsequently created will inherit the client's access token and be similarly limited.

Using Domain Security Groups Effectively

Domain security groups are much like local security groups, except that they apply to all computers throughout the domain. They are based on the same theory and have the same effects.

Irrespective of the Active Directory domains or organizational units into which you place domain security groups, they are valid for the entire domain. For example, a security group created inside the Engineering Team Leaders organizational unit (OU) can contain security principals from any part of the domain and can be used to secure resources on computers that are not members of the OU. The only reason for creating security groups within OUs is to keep objects of similar purpose grouped together in the user interface.

Global security groups in a domain can also be members of other domain and local security groups. When a security group is a member of another security group, it inherits access to the parent security group's resources in the same way that a member user account inherits access. Local groups cannot be members of other groups.

Using Security Groups to Set Permissions

As with local groups, only security groups should appear in the ACLs of secured resources. Users change far more often than you should change ACLs. When you use individual user accounts in ACLs, you must change ACLs frequently, which is a disk- and processor-intensive operation. By using security groups, you need only change ACLs when major reorganizations occur, which is quite rare.

Avoid placing user accounts in ACLs, even if a specific ACE applies only to a single user. It is still preferable to create a security group to secure a resource for a single user because, if for some reason you need administrative access to the object, you can place your own account in the group to obtain access rather than changing the secured object's ACL.

Changing permissions within an ACL widely on a single computer is burdensome; in domains with millions of files and tens of thousands of folders, it's practically impossible. Adding an account to a security group is simple and does not get more difficult as a domain or organization grows. Administrators who set permissions using individual user accounts will quickly find orphaned SID numbers in ACL displays, as user accounts are deleted and their older and useless ACEs remain behind.

Creating Effective Domain Security Groups

The proper use of security groups in large environments should be divided into two distinct categories: user groups and resource groups.

A user group is used to combine users into a single security identifier it is the typical way that security groups have always been used. For example, you would put all the engineers in a company into a security group called Engineers.
A resource group is a group that is used to apply permissions to secured objects. These security groups should mimic the names of the objects that they secure. For example, a folder called Customer Profile Data might be secured by a resource group called Customer Profile Data Users.

After you have categorized your security groups, you can apply permissions to users by making user groups members of resource groups. If you place the Engineers group in the Customer Profile Data Users group, all members of Engineers will inherit the necessary SIDs to access those files.

By splitting security groups into user and resource groups, you can manage permissions more efficiently because you won't be tempted to try to force fit an existing group of users to a new resource. For example, you might apply an existing group called Accountants to the Accounts Receivables folder because it already exists. However, if you are in the habit of creating a resource security group like Accounts Receivables Users whenever a new need appears, you will be more likely to properly apply the correct users and thereby minimize the potential for unauthorized use.

In smaller environments with a single domain, creating separate user and resource groups does not increase efficiency, but it is good practice for future growth and is not significantly less efficient.

Optimizing Groups in Large Organizations

Domain security groups have four contexts, depending on where (and whether) they are stored in the Active Directory database:

Local groups are not stored in the Active Directory database, but exist on member servers and workstations in the domain. Local groups can contain any other type of group, but they specify access to resources on the local machine only. Active Directories running in mixed mode treat the local groups of domain controllers as domain groups and do not have true domain local groups.
Domain local groups are specific to a domain in the Active Directory tree. Domain groups cannot contain local groups, and they provide access to resources within the domain only. Domain local groups replace server-based local groups when an Active Directory is switched from a mixed Windows NT and Windows 2000 domain to a native Windows 2000 domain that contains only Windows 2000 domain controllers. Domain local groups are not propagated in a user's session ticket.

For more information about upgrading from mixed to native mode, see the Microsoft Windows 2000 Server Resource Kit (Microsoft Press, 2002).
Global groups are specific to a single domain in the Active Directory as well, and can contain only user accounts and resources within their own domain. Unlike domain local groups, they are added to a user's session ticket at log on.
Universal groups are maintained at the Active Directory forest level and are available to all trees within the Active Directory. An Active Directory forest is the structure that contains Active Directory trees, which are Active Directory structures that contains related domains. Domains in a tree automatically trust one another, and trees in a forest automatically trust one another. Universal groups can contain any security principal in Active Directory from any domain, and can be used throughout the forest to create permissions that should apply across multiple trees and domains.

The primary reason that so many scopes of security groups exist is to make Active Directory replication efficient. In a single domain network that has no trust relationships established with other domains, security group scope is irrelevant because there are no scopes beyond the domain the choice of using a domain local group, a global group, or a universal group has no difference in effect.

Small businesses should use universal groups routinely so that, as they grow, familiar groups will be available to all domains when those domains are spun off. Larger businesses should use universal groups for security that pervades the entire organization, and global groups for teams and working groups that are local to the domain.

In large networks, making security groups efficient is a key problem. Remember that when a user logs on, the groups that the user is a member of are added to that user's access token. When a user is a member of groups in other domains, the network traffic required to move domain memberships around can become significant. The different group scopes exist to make this process efficient.

Domain local groups and global groups are similar in scope: the group SID (but not its members) is propagated to the Global Catalog, and both group types can contain only security principals from their own domains. There is one key difference between them: global groups are contained in session tickets while domain local groups are not.

Global group SIDs are added to a user's access token at the time that the user logs on to the domain and are propagated through session tickets irrespective of the resource being accessed.
Domain local groups are added only to access tokens that are created when resources are accessed on servers within the local domain in other words, when a user accesses a server in a resource domain, the server will add SIDs that apply to the user from its own domain as well as adding the SIDs contained in the user's session ticket.

Refer to Figures 2.6 and 2.7 to see precisely where in the logon process these two different types of groups are accessed.

Because global groups are contained in session tickets while domain local groups are not, a natural division of labor between them emerges.

User accounts should always be placed in global groups because they will carry this membership with them in their session tickets. Global groups can be thought of as "groups of users."
Resources like shared files and printers should be secured using domain local groups, because they never move among domains their position is fixed. Domain local groups can be thought of as "resource groups," the groups you use when you're adding permissions to resources.

When users need access to resources in a local domain, you can give the global group to which the user belongs access to the resource by placing it in the domain local group. This methodology can dramatically reduce the number of SIDs floating around your network in session tickets, which will speed domain logon and resource access in extremely large networks.

Practice: Creating User Accounts and Security Groups

In this practice, you create user and group accounts in Active Directory.

Exercise 1: Managing Domain User Accounts in Active Directory

In this exercise, you practice managing domain user accounts. You populate Active Directory with multiple user accounts. When this is accomplished, you then move, disable, and delete domain user accounts.

Perform this exercise while logged on to the domain controller as Administrator.

To create a user inside an OU in Active Directory

Click Start, point to Programs, point to Administrative Tools, and click Active Directory Users And Computers.

The Active Directory Users And Computers management console appears.
Expand the Departments and Engineering OUs you created in Chapter 1.
Click Engineering Team Leaders, and click New User on the toolbar. The New Object dialog box appears as shown in Figure 2.8.

figure 2-8 the new object dialog box

Figure 2-8. The New Object dialog box

Type Robert in the First Name box.
Type Lengel in the Last Name box.
Type rlengel in the User Logon Name box.
Click Next. The password properties panel appears.
Type the same random password in the Password and Confirm Password boxes.
Select the User Must Change Password At Next Logon check box.
Click Next, review the summary of your input, and click Finish to add the user.

To populate Active Directory with user accounts

Using the following list of OUs, create domain user accounts in the specified OU for the user names appearing after them. Create user names based on the first initial plus last name method. Assign a random password to each user.

Designers: Syed Abbas, Kim Abercrombie, Humberto Acevedo.
Design Leaders: Pilar Ackerman.
Engineers: Jay Adams, Terry Adams, Francois Ajenstat.
Engineering Team Leaders: Kim Akers, Amy E. Alberts., Robert Lengel.
Accounts Payable: Gregory F. Alderson.
Accounts Receivable: Michelle Alexander.
Accounting: Sean P. Alexander, Michael Allen.
Finance: Gary E. Altman.
Human Resources: Nancy Anderson.
Help Desk: Pamela Ansman-Wolfe.
Network Administration: Karen Archer.
Support Technicians: Zainal Arifin, John Arthur.
Sales Managers: Chris Ashton.

To move a domain user account

In the Active Directory Users And Computers management console, expand Departments, Information Technology, and then Support Technicians OU.
Right-click the Zainal Arifin user account, and choose Move.
In the Move dialog box, expand Departments, Information Technology, and select Network Administration.
Click OK. User Zainal Arifin is now located in the Network Administration OU.

To disable a domain user account

In the Active Directory Users And Computers management console, expand Departments, Engineering, and then the Engineers OU.
Right-click the Francois Ajenstat user account, and click Disable Account. A message box announces that the account has been disabled.
Click OK to acknowledge the message.

A red X now appears over the user account's icon.

To delete a domain user account

In the Active Directory Users And Computers management console, click Departments, Engineering, and then Engineers OU.
Right-click the Francois Ajenstat user account, and click Delete. A delete confirmation message box appears.
Click Yes to confirm that the account should be deleted.

The account disappears from the list of user accounts.

Exercise 2: Managing Domain Security Groups

In this exercise, you create a domain security group and then add members to the group. Finally, you delete a domain security group.

Perform this exercise while logged on to the domain controller as Administrator.

To create a domain security group

Open the Active Directory Users And Computers management console.
Expand domain.fabrikam.com, and expand Departments.
Click Engineering, and click New Group on the toolbar. The New Object dialog box appears.
Type Engineering CAD Files Users in the Group Name box, as shown in Figure 2.9.

Figure 2-9. Creating a domain security group
Click OK to accept the default Global group and Security group options.

The Engineering CAD Files Users group now exists in Active Directory.

To add members to a domain security group

Double-click the Engineering CAD Files Users group. The Engineering CAD Files Users Properties dialog box appears.
In the dialog box, click the Members tab, and click Add.

A list of domain users and groups appears.
Select Robert Lengel from the list of users, as shown in Figure 2.10, and click OK.

User account rlengel is now a member of the Engineering CAD Files Users group.

Figure 2-10. Adding a member to a group

You can use Shift+Ctrl to select multiple user accounts and add them all to the group at the same time.

To delete a domain security group

Right-click the Engineering CAD Files Users security group and click Delete. A delete confirmation dialog box appears.
Click Yes to confirm.

The security group is now deleted.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

What is the difference between a global group and a domain local group?
Are access tokens ever transmitted across the network?
What are universal groups?
What is the purpose of separating groups into user groups and resource groups, when you can use the same groups for both purposes?

Lesson Summary

The domain logon process is similar to the local logon process, except that user account and security identifier information comes from the Active Directory service on domain controllers rather than from the SAM on the local machine.
Membership in a domain is actually a one-way trust relationship. Clients trust domain controllers and allow the accounts stored in domain controllers to log on locally to the client computer. This trust is created automatically when the client computer is joined to the domain and can be revoked only by removing the client from the domain.
Client computers and member servers have local user and security accounts. Domain controllers do not have local accounts, which are replaced by Active Directory accounts when Active Directory is installed.
Kerberos is the mechanism used to manage trust between clients and servers in a domain. When clients log on, they receive a ticket-granting ticket that can be used to obtain session tickets valid for authentication on all servers throughout the domain. These tickets contain the user's SID and the SIDs of global groups that the user belongs to, and they are used to construct access tokens on servers when sessions are established.
There are four primary types of security groups in a domain: local groups that do not exist on domain controllers; domain local groups that are used to secure resources; global groups that are used to create groups of user accounts within a single domain; and universal groups, which are global groups that are propagated to all domains in the Active Directory tree.