Windows Server : Designing Enterprise-Level Group Policy Strategy (part 3) - Planning Authentication and Authorization

3. Planning Authentication and Authorization

Authentication involves checking that users are who they say they are. It uses username and password or a security certificate installed on a smart card. Authorization determines whether a user has access to resources through permissions or administrative rights through group membership and delegation. Authorization can happen within a domain, across a domain tree, or between forests. It involves the SAM, access control lists (ACLs), and protocols such as Kerberos v5.

Multifactor Authentication and Authorization

The network community is always happy to debate when a scenario involves multifactor authentication and when it involves multifactor authorization. Ignore such debates. You have an examination to pass.

Multifactor authentication occurs when you must use two or more distinct methods to authenticate an identity. For example, you are logged on to a domain with an administrative-level account. You need to access a standalone Berkley Internet Daemon (BIND) server through Remote Desktop. You are asked for credentials. They are the same credentials that you used to log on to the domain, but you need to enter them again. This is multifactor authentication.

Multifactor authorization occurs when you need to authenticate two people to accomplish a stated aim. For example, you need to create a two-way forest trust between the contoso.internal and litware.internal forests. You create one end of the trust logged on to the contoso.internal forest as Kim_Akers. To create the other end, you need to provide the credentials for Tom_Perry in the litware.internal forest. This is multifactor authorization.

Using Password Authentication

You can authenticate a user through a username and password. Before you plan a password policy, you need to know what the default settings are. Figure 9 shows the default settings for the contoso.internal domain.

Figure 9. Default password settings

As an experienced administrator, you should be familiar with password settings. However, you might not be aware of the fine-grained password policies in Windows Server 2008.

Configuring Fine-Grained Password Policies

As a first step in planning fine-grained password and account lockout policies, decide how many password policies you need. Typically, your policy could include at least 3 but seldom more than 10 Password Settings Objects (PSOs). At a minimum, you would probably want to configure the following:

• An administrative-level password policy with strict settings: for example, a minimum password length of 12, a maximum password age of 28 days, and password complexity requirements enabled.

• A user-level password policy with, for example, a minimum password length of 6, a maximum password age of 90 days, and password complexity requirements not enabled.

• A service account password policy with a minimum password length of 32 characters and complexity requirements enabled. (Service account passwords are seldom typed in.) Because of their complexity, service account passwords can typically be set not to expire or to have very long password ages.

You also need to look at your existing group structure. If you have existing Administrators and Users groups, there is no point creating new ones. Ultimately, you need to define a group and Active Directory structure that maps to your fine-grained password and account lockout policies.

You cannot apply PSOs to OUs directly. If your users are organized into OUs, consider creating shadow groups for these OUs and then applying the newly defined fine-grained password and account lockout policies to them. A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password and account lockout policy. Add OU users as members to the newly created shadow group and then apply the fine-grained password and account lockout policy to this shadow group. If you move a user from one OU to another, you must update user memberships in the corresponding shadow groups.

Microsoft applies PSOs to groups rather than to OUs because groups offer better flexibility for managing various sets of users. Windows Server 2008 AD DS creates various groups for administrative accounts, including Domain Admins, Enterprise Admins, Schema Admins, Server Operators, and Backup Operators. You can apply PSOs to these groups or nest them in a single global security group and apply a PSO to that group. Because you use groups rather than OUs, you do not need to modify the OU hierarchy to apply fine-grained passwords. Modifying an OU hierarchy requires detailed planning and increases the risk of errors.

If you intend to use fine-grained passwords, you probably need to raise the functional level of your domain. To work properly, fine-grained password settings require a domain functional level of Windows Server 2008. 

By default, only members of the Domain Admins group can create PSOs and apply a PSO to a group or user. You do not, however, need to have permissions on the user object or group object to be able to apply a PSO to it. You can delegate Read Property permissions on the default security descriptor of a PSO to any other group (such as help desk personnel). This enables users who are not domain administrators to discover the password and account lockout settings applied through a PSO to a security group.

You can apply fine-grained password policies only to user objects and global security groups (or inetOrgPerson objects if they are used instead of user objects). If your plan identifies a group of computers that requires different password settings, consider techniques such as password filters. Fine-grained password policies cannot be applied to computer objects.

If you use custom password filters in a domain, fine-grained password policies do not interfere with these filters. If you plan to upgrade Windows 2000 Server or Windows Server 2003 domains that currently deploy custom password filters on DCs, you can continue to use those password filters to enforce additional password restrictions.

If you have assigned a PSO to a global security group, but one user in that group requires special settings, you can assign an exceptional PSO directly to that particular user. For example, the CEO of Northwind Traders is a member of the senior managers group, and company policy requires that senior managers use complex passwords. However, the CEO is not willing to do so. In this case, you can create an exceptional PSO and apply it directly to the CEO’s user account. The exceptional PSO will override the security group PSO when the password settings (msDS-ResultantPSO) for the CEO’s user account are determined.

Finally, you can plan to delegate management of fine-grained passwords. When you have created the necessary PSOs and the global security groups associated with these PSOs, you can delegate management of the security groups to responsible users or user groups. For example, a human resources (HR) group could add user accounts to or remove them from the managers group when staff changes occur. If a PSO specifying fine-grained password policy is associated with the managers group, in effect the HR group is determining to whom these policies are applied.

Using Smart Card Authentication

If you are using smart cards in your organization to provide additional security and control over user credentials, your users can use those smart cards with authentication credentials to obtain rights account certificates (RACs) and use licenses from an Active Directory Rights Management Services (AD RMS) server (or more commonly in the enterprise environment, an AD RMS cluster), provided a Secure Sockets Layer (SSL) certificate has already been installed.

Your next task is to force the authentication method to use Client Certificate Mapping Authentication for the AD RMS cluster. Before you do that, back up the applicationhost.config file in the %windir%\system32\inetsrv\config folder.

access sslFlags="Ssl, SslNegotiateCert, SslRequireCert, Ssl128"

access sslFlags="Ssl, SslNegotiateCert, Ssl128"

clientCertificateMappingAuthentication enabled="true"

clientCertificateMappingAuthentication enabled="true"

windowsAuthentication enabled="true"

windowsAuthentication enabled="false"

Note that running iisreset from a command prompt will restart the services associated with IIS.

Again, if you are using an AD RMS cluster, you repeat the procedure for every other server in the cluster.

After you have configured these settings, a user who attempts to open rights-protected content published by the AD RMS server or cluster is prompted to provide authentication credentials before the server or cluster provides the user with an RAC or user license.