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.
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.
Note: Shadow groups
You will not find an Add Shadow Group command
in Active Directory Users and Computers. A shadow group is simply an
ordinary global security group that contains all the user accounts in
one or more OUs. When you apply a PSO to a shadow group, you are
effectively applying it to users in the corresponding OU.
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.
To use smart card authentication, you must also
add the Client Certificate Mapping Authentication role service in Server
Manager. This is part of the Web Server (IIS) server role. Your next
step is to configure the authentication method in IIS. Perform these
steps to do so.
1. | In
Internet Information Services (IIS) Manager, expand the server name in
the console tree and, in the results pane of the server Home page,
double-click Authentication to open the Authentication page.
|
2. | In
the results pane of the Authentication page, right-click Active
Directory Client Certificate Authentication, and then choose Enable.
|
3. | Enable
client authentication for the Web site that is hosting AD RMS. In IIS
Manager, expand the server name in the console tree, expand Sites, and
then expand the Web site that is hosting AD RMS. By default, the Web
site name is Default Web Site.
|
4. | In
the console tree, expand_wmcs, right-click either the certification
virtual directory (to support RACs) or the licensing virtual directory
(to support user licenses), and then choose Switch To Content View.
|
5. | In the results pane, right-click certification.asmx or license.asmx as appropriate, and then choose Switch To Features View.
|
6. | In
the results pane on the Home page, double-click SSL Settings, and
choose the appropriate client certificates setting (Accept or Require).
Accept client certificates if you want clients to have the option
to supply authentication credentials by using either a smart card
certificate or a username and password. Require client certificates if
you want only clients with client-side certificates such as smart cards
to be able to connect to the service.
|
7. | Click
Apply. If you want to use client authentication for both certification
and licensing, repeat this procedure but select the alternate virtual
directory the second time.
|
8. | Close IIS Manager. If you are using an AD RMS cluster, repeat the procedure for every other server in the cluster.
|
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.
1. | Open an elevated command prompt, and change the directory to %windir%\system32 \inetsrv\config.
|
2. | Enter notepad applicationhost.config and locate the section similar to Default Web Site/_wmcs/certification/certification.asmx.
|
3. | If you want to allow smart card authentication in addition to Windows authentication, change:
access sslFlags="Ssl, SslNegotiateCert, SslRequireCert, Ssl128"
to:
access sslFlags="Ssl, SslNegotiateCert, Ssl128"
|
4. | Add a new line under windowsAuthentication enabled=“true.“ In this line, type:
clientCertificateMappingAuthentication enabled="true"
|
5. | If
you want to allow only smart card authentication, ensure that SSL
client authentication with IIS is required. Add a new line under windowsAuthentication enabled=“true.” In this line, type:
clientCertificateMappingAuthentication enabled="true"
|
6. | Change:
windowsAuthentication enabled="true"
to:
windowsAuthentication enabled="false"
|
7. | Click File, choose Save, and then close Notepad.
|
8. | In the command prompt window, enter iisreset.
|
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.