Executive Summary:
Microsoft’s Windows password policies let you enforce password quality requirements for the passwords of user accounts. Windows Server 2003 and Windows 2000 Server password policies let administrators define only one password policy that applies to all user accounts in a domain. Windows Server 2008, Microsoft’s upcoming Server OS, resolves this limitation.
|
One of Windows’ most important
security policies that every
Windows administrator is
certainly familiar with is the
password policies. These policies
let you enforce password
quality requirements (e.g., minimum password
length, maximum password age) for the
passwords of local or domain user accounts.
As you might know, Windows Server 2003 and
Windows 2000 Server password policies have
some important limitations. In this article I
explain these limitations and discuss how Windows Server
2008—Microsoft’s upcoming Server OS—resolves them. I
also explain how you can configure and use Server 2008’s
password policies. At press time, Microsoft had released
Server 2008 Release Candidate 0 (RC0) and was planning to
launch the Server OS on February 27, 2008.
A Flexible
Solution for a
Serious Problem
A serious limitation of the password policies in Windows
2003 and Win2K is that administrators can define only
one password policy that applies to all user accounts in a
domain. You can define this global domain password policy
from the Default Domain Policy Group Policy Object’s (GPO’s) Password Policy settings or from any other GPO
that’s linked to the Active Directory (AD) domain object. To
access the Password Policy configuration interface, go to
the \Computer Configuration\Windows Settings\Security
Settings\Account Policies GPO container. Even though you
can define different password policies in the GPOs and
link them to AD organizational units (OUs) or computer
accounts, these password policies don’t apply to domain
accounts—instead, they apply to the local accounts that are
defined in the security databases of the computer accounts
to which the GPOs apply.
Organizations typically want to impose different password
quality requirements for certain categories of domain
accounts. A classic example is having a different password
policy for administrator accounts and regular user
accounts. The security rationale is simple: Administrator accounts have more powers (permissions and
rights) than plain user accounts, so you might
want a higher quality authentication process
for administrators than for regular users.
Another way to provide stronger authentication
is to enforce the use of smart card logon
for administrator accounts.
Windows 2003 and Win2K provide two
workarounds for organizations that want to
define different passwords policies in a single
domain, although both workarounds are
difficult to implement. One workaround is
to deploy separate domains for each of the
account categories that you want to define a
special password for. The other workaround
is to develop a special “password filtering”
DLL that you then deploy to all your domain
controllers (DCs). The second solution is rarely
used because it’s even more complex and time
consuming than the first solution.
Server 2008 comes to the rescue by introducing
fine-grained password policies that let
administrators define different password policies
for different domain account categories in
a single domain. This new fine-grained password
policy functionality can be applied only
to domain accounts—not to local accounts.
Server 2008 introduces the same functionality
for the account lockout policies that in
earlier Windows Server versions were crippled
by the same limitation (i.e., you could
define only a single account lockout policy for
all domain accounts). Account lockout policies
ensure that user accounts automatically
become unusable after a user enters a certain
number of incorrect passwords. The administrator
must define a bad password threshold to
configure the account lockout policy.
Configuring Fine-Grained
Password Policies
Configuring Server 2008’s fine-grained password
policies is entirely different from defining
the classic domain account or local account
password policy in earlier Windows versions
(which I described previously). You can’t use
GPO settings to configure fine-grained password
policies, because Microsoft uses a different
(non–GPO-based) mechanism to store and
enforce these policies.
Server 2008’s fine-grained password policies
are stored in a new AD container called
the AD Password Settings Container, which
is located in the System container of the AD
domain naming context. To define a new
fine-grained password policy, you must create
a new AD object of the msDS-PasswordSettings
object class in this container. Objects of
this class are referred to as Password Settings
objects (PSOs) in the Microsoft documentation.
By default, only members of the Domain
Admins group can create PSOs, because only
members of this group have the AD Create
Child and Delete Child permissions on the
Password Settings Container. (I discuss the
tools you can use to create and configure PSOs
in a later section.)
To apply the PSOs you created, you must
link the PSO to an AD user or group object. To
do so, you don’t need permissions to the AD
object itself; you simply need Write permissions
on the PSO. By default, only members of
the Domain Admins group have this permission.
Therefore, only members of the Domain
Admins group can link a PSO to a group or
user—although you can obviously delegate
these permissions to other administrators.
Table 1 summarizes the attributes that are
linked to Server 2008 PSOs. Note that a PSO
can store not only password policy settings
but also account lockout policy
settings. Remember that Server
2008 supports both fine-grained
password and account lockout
policies. Two important PSO
attributes are the msDS-PSOAppliesTo
and msDS-PasswordSettingsPrecedence
attributes.
The msDS-PSOAppliesTo
PSO attribute is a multi-valued
attribute that determines what
AD user accounts or groups
the PSO will be linked to. Even
though password and account
lockout policies can be linked to
any AD user, group or computer
object, or OU, PSOs are effective
only for the user accounts and
global groups they are linked to.
In addition, PSOs are effective
only if your AD domain is in the
native Server 2008 domain functional
level—which means that
all the DCs in your domain must
be running Server 2008.
The msDS-PasswordSettingsPrecedence
PSO attribute
holds an integer value that
is used to resolve conflicts if multiple PSOs are applied to a
user or group object. A low value
for the msDS-PasswordSettings
Precedence attribute indicates
that the PSO has a higher priority
than other PSOs. For example,
imagine that a user object has two
PSOs linked to it: one PSO that
has an msDS-PasswordSettings
Precedence value of 10 and
another PSO that has a value of
40. In this case, the PSO that has
the msDS-PasswordSettingsPrecedence
value of 10 (the lower
value) has a higher rank and will
be applied to the user object. If
multiple PSOs are linked to a user
or group, the logic that Server
2008 uses to determine the resultant
PSO is as follows:
- A PSO that is linked directly to
the user object is the resultant
PSO. If more than one PSO is
linked directly to the user object,
the PSO with the lowest msDS-Password-
SettingsPrecedence value is the resultant
PSO.
- If no PSO is linked to the user object, but
PSOs are linked to global groups the user
is a member of, Server 2008 compares the
msDS-PasswordSettingsPrecedence values
of these different global group PSOs. Again,
the PSO with the lowest msDS-Password-
SettingsPrecedence value is the resultant
PSO.
- If no PSO is obtained from these conditions,
the “classic” Default Domain Policy
is applied.
To let administrators easily determine the
PSO that’s ultimately applied to a user,
Microsoft added a new attribute called
msDS-ResultantPSO to each AD user object.
This attribute holds the distinguished name
(DN) of the PSO that’s applied to a given
user.
Continue to next page
Previous
Register
