Tài liệu Windows Server 2008 Inside Out- P25 pptx

A
s an administrator, managing users, groups, and computers will probably be a sig-
nifi cant part of your duties and responsibilities. Managing users, groups, and com-
puters encapsulates the important duties of a system administrator because of the way
you must balance convenience, performance, fault tolerance, and security.
Managing Domain User Accounts
The next part of this chapter is dedicated to helping you plan, manage, and administer
user accounts in a secure and effi cient manner. Microsoft Windows operating systems
have come a long way since the early days of Windows Server and you have many
options for managing users in Windows Server 2008.
Types of Users
It is a good idea to have a solid grasp of fundamental concepts that underpin the
managing of users. In the fi rst part of the chapter, I will describe the types of users
Microsoft Windows Server 2008 defi nes.

User
In Windows Server 2008, you can have local user accounts or domain user
accounts. On a domain controller, local users and groups are disabled. In Active
Directory, the domain user account contains user name, password, the groups of
which the user is a member, and other descriptive information, such as address
and phone numbers, as well as many other user descriptions and attributes, such
as security and remote control confi gurations.

InetOrgPerson
InetOrgPerson is a type of user introduced in Windows Server
2003. InetOrgPerson has attributes based on Request for Comments (RFC) 2798,
such as vehicle license number, department number, display name, employee
number, JPEG photograph, and preferred language. Used by X.500 and Light-
weight Directory Access Protocol (LDAP) directory services, the InetOrgPerson
account is used when you migrate non-Microsoft LDAP directories to Active
Directory. Derivative of the user class, the InetOrgPerson can be used as a secu-

rity principal. The InetOrgPerson is compatible with X.500 and LDAP directory
services.
Managing Domain User Accounts . . . . . . . . . . . . . . . . 1167
Managing User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 1195
Managing User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
Maintaining User Accounts . . . . . . . . . . . . . . . . . . . . . . 1210
Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215
Managing Computer Accounts . . . . . . . . . . . . . . . . . . 1225
CHAPTER 35
Managing Users, Groups,
and Computers
1167
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Contact
Sometime you may want to create an account that will only be used as
an e-mail account. This is when you would create a contact. It is not a security
principal and does not have a security identifi er (SID). There are neither pass-
words nor logon functionality available with a contact account. However, it can
be a member of a distribution group.

Default user accounts
These are the built-in user accounts created when a
Windows Server 2008 installation or stand-alone server is confi gured to be a
domain controller and Active Directory is installed. It is a good idea to rename
the Administrator account for security reasons. The default user accounts are
found by opening Active Directory Users And Computers, then examining
the contents of the Builtin and Users containers. They include the following
accounts:


Administrator This is the account that has full control over the computer
or domain. You should have a very strong password for this account.
The Administrator is a member of these groups: Administrators, Domain
Admins, Domain Users, and Group Policy Creator Owners. In a forest root
domain, the Administrator is also a member of the Enterprise Admins and
Schema Admins groups. The Administrator account can never be deleted.
However, you can disable it or rename it. Either of these actions is a good
practice to ensure a secure domain and network.

Guest The Guest account can be used by users who don’t have an account
in the domain. It is a member of the Guests domain local group and the
Domain Guests global group. The Guest account is disabled by default when
you make a stand-alone Windows Server 2008 server a domain controller.
Naming User Accounts
Think about the naming scheme you plan to use for user accounts. As the organization
changes and grows, the original naming scheme may need to change but not the need
for a naming scheme of some kind. Although account names for operating systems ear-
lier than Windows 2000 are limited to 20 characters for a user name, Windows Server
2003 and Windows Server 2008 have a 256-character limitation for a user name.
Small organizations commonly use a person’s fi rst name and last name initial for their
user account. In a larger organization, it may be a better idea to use their full name for
their user account name. For example, in a small organization, John Smith could have a
user name of JohnS. However, in a larger organization, John Smith should have a user-
name of JohnSmith.
This becomes a problem when an organization has more than one John Smith who
needs a user account. Full names are likely to be an issue; using middle name initials
can solve it. However, administrators may implement a numbering system. For exam-
ple: JSmith1, Jsmith2. Another naming system uses a dot-delimited scheme, such as
Regardless of the naming scheme you choose, the key is
to be as consistent as possible and to allow for exceptions as needed. Keep in mind that

although a user name can be 256 characters in length, a name of this length really isn’t
practical in most cases.
Naming User Accounts
Think about the naming scheme you plan to use for user accounts. As the organization
changes and grows, the original naming scheme may need to change but not the need
for a naming scheme of some kind. Although account names for operating systems ear-
lier than Windows 2000 are limited to 20 characters for a user name, Windows Server
2003 and Windows Server 2008 have a 256-character limitation for a user name.
Small organizations commonly use a person’s fi rst name and last name initial for their
user account. In a larger organization, it may be a better idea to use their full name for
their user account name. For example, in a small organization, John Smith could have a
user name of JohnS. However, in a larger organization, John Smith should have a user-
name of JohnSmith.
This becomes a problem when an organization has more than one John Smith who
needs a user account. Full names are likely to be an issue; using middle name initials
can solve it. However, administrators may implement a numbering system. For exam-
ple: JSmith1, Jsmith2. Another naming system uses a dot-delimited scheme, such as
Regardless of the naming scheme you choose, the key is
to be as consistent as possible and to allow for exceptions as needed. Keep in mind that
although a user name can be 256 characters in length, a name of this length really isn’t
practical in most cases.
Chapter 35
1168 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Confi guring User Account Policies
Because domain controllers share the domain accounts database, user account policies
must be consistent across all domain controllers. The way consistency is ensured is by
having domain controllers obtain user account policies only from the domain container
and only allowing one top-level account policy for domain accounts. The one top-level
account policy allowed for domain accounts is determined by the highest precedence

Group Policy object (GPO) linked to the domain container. This top-level account
policy is then enforced by the domain controllers in the domain. Domain controllers
always obtain the top-level account policy from the highest precedence GPO linked to
the domain container. By default, this is the Default Domain Policy GPO.
When a domain is operating at the Windows Server 2008 functional level, two new
object classes in the Active Directory schema allow you to fi ne-tune the way account
policy is applied:

Password Settings container

Password Settings object
The default Password Settings container (PSC) is created under the System container
in the domain, and it stores the Password Settings objects (PSOs) for the domain.
Although you cannot rename, move, or delete the default PSC, you can add PSOs to this
container that defi ne the various sets of secondary account policy settings you want to
use in your domain. You can then apply the desired secondary account policy settings
to users, inetOrgPersons, and global security groups as discussed in “Creating Pass-
word Settings Objects and Applying Secondary Settings” on page 1173.
Local Account Policy Is Used for Local Log On
Local account policies can be different from the domain account policy, such as when
you specifi cally defi ne an account policy for local accounts in a computer’s local GPO
(LGPO). For example, if you confi gure an account policy for a computer’s LGPO, when
users log on to Active Directory they’ll obtain their account policy from the Default
Domain Policy instead of the LGPO. The only exception is when users log on locally to
their machines instead of logging on to Active Directory; in that case any account policy
applied to their machine’s local GPO is applied and enforced.
As discussed in Chapter 36, “Managing Group Policy,” account policies in a domain are
confi gured through the policy editors accessible from the Group Policy Management
Console (GPMC). When you are editing policy settings, you’ll fi nd account policies
under Computer Confi guration\Windows Settings\Security Settings\Account Poli-

cies. To change group policies, you must be a member of the Domain Admins group
or Enterprise Admins group in Active Directory. Members of the Group Policy Creator
Owners group can also modify group policy for the domain.
Local Account Policy Is Used for Local Log On
Local account policies can be different from the domain account policy, such as when
you specifi cally defi ne an account policy for local accounts in a computer’s local GPO
(LGPO). For example, if you confi gure an account policy for a computer’s LGPO, when
users log on to Active Directory they’ll obtain their account policy from the Default
Domain Policy instead of the LGPO. The only exception is when users log on locally to
their machines instead of logging on to Active Directory; in that case any account policy
applied to their machine’s local GPO is applied and enforced.
Managing Domain User Accounts 1169
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
The account policies for a domain contain three subsets—Password Policy, Account
Lockout Policy, and Kerberos Policy. Although secondary account policies include Pass-
word Policy and Account Lockout Policy, they do not include Kerberos Policy. Kerberos
Policy can only be set at the domain level for the top-level account policy.
Some Security Options Are Also Obtained from the Default Domain
Policy GPO
Two policies in Computer Confi guration\Windows Settings\Security Settings\Local Poli-
cies\Security Options also behave like account policies. These policies are Network
Access: Allow Anonymous SID/NAME Translation and Network Security: Force Logoff
When Logon Hours Expire. For domain accounts, the settings for these policies are
obtained only from the Default Domain Policy GPO. For local accounts, the settings for
these policies can come from a local OU GPO if one is defi ned and applicable.
Enforcing Password Policy
Password policies for domain user accounts and local user accounts are very impor-
tant in preventing unauthorized access. These settings should help enforce your
organization’s written computing policies. There are six settings for password policies

that enable you to control how passwords are managed. When you are setting top-level
account policy for the Default Domain Policy, these policies are located in Computer
Confi guration\Windows Settings\Security Settings\Account Policies\Password Policy
(see Figure 35-1). When you are setting secondary account policy for a PSO, you confi g-
ure these settings using similarly named object attributes.
Figure 35-1 Managing Password Policy in the Default Domain Policy.
The settings are as follows:

Enforce Password History
When users change their passwords, this setting deter-
mines how many old passwords will be maintained and associated with each
user. The maximum value is 24. If you enter zero (0), a password history is not
Some Security Options Are Also Obtained from the Default Domain
Policy GPO
Two policies in Computer Confi guration\Windows Settings\Security Settings\Local Poli-
cies\Security Options also behave like account policies. These policies are Network
Access: Allow Anonymous SID/NAME Translation and Network Security: Force Logoff
When Logon Hours Expire. For domain accounts, the settings for these policies are
obtained only from the Default Domain Policy GPO. For local accounts, the settings for
these policies can come from a local OU GPO if one is defi ned and applicable.
Chapter 35
1170 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
kept. On a domain controller, the default is 24 passwords, on a stand-alone server,
it is zero passwords.

Maximum Password Age
This determines when users are required to change
their passwords. For example, if this is set to 90 days, on the 91st day the user
will be required to change his or her password. The default on domain control-

lers is 42 days. The minimum number of days is 0, which effectively means that
the password never changes. The maximum number of days is 999. In an envi-
ronment where security is critical, you probably want to set the value low—in
contrast, for environments where security is less stringent, you could set the pass-
word age high (rarely requiring users to change passwords).

Minimum Password Age
How long users must use passwords before they are
allowed to change the password is determined by this setting. It must be more
than zero days for the Enforce Password History Policy to be effective. In an envi-
ronment where security is critical, you would probably set this to a shorter time,
and to a longer time where security not as tight. This setting must be confi gured
to be less than the Maximum Password Age policy. The maximum value is 998.
If you enter zero (0), a password can be changed immediately. The default is 1
day on a domain controller and 0 days on stand-alone servers. This setting helps
to deter password reuse by making a user keep a password for at least a certain
amount of time

Minimum Password Length
This is the number of characters that sets the mini-
mum requirement for the length of the password. Again, a more critically secure
environment might require longer password lengths than one with reduced secu-
rity requirements. The maximum value is 14. If you enter zero (0), a password is
not required. As shown in Figure 35-2, the default length is seven characters on
domain controllers. The default is zero characters on stand-alone servers.

Password Must Meet Complexity Requirements
Complexity requirements for
passwords for the domain user accounts are set at a higher requirement than
previously in Windows 2000. If this policy is defi ned, passwords can’t contain

the user account name, must contain at least six characters, and must consist of
uppercase letters, lowercase letters, numerals, and special non-alphabetical char-
acters, such as the percentage sign (%) and the asterisk (*). (Complexity require-
ments are enabled by default on domain controllers and disabled by default on
stand-alone servers for Windows Server 2008.)

Store Passwords Using Reversible Encryption
This is basically an additional
policy that allows for plain text encryption of passwords for applications that may
need it. By default, it is disabled on Windows Server 2008. Enabling this policy
is basically the same as storing passwords as plain text and is used when applica-
tions use protocols that need information about the user’s password. Because this
policy degrades the overall security of the domain, it should be used only when
necessary.
Managing Domain User Accounts 1171
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Figure 35-2 Configuring domain user Minimum Password Length in the Default Domain Policy.
Confi guring Account Lockout Policy
The Account Lockout Policy is invoked after a local user or a domain user has been
locked out of his or her account. These settings are designed to help protect user
accounts from attacks that involve password guessing or other types of attacks where
random passwords are repeatedly entered to try to gain access to an account. There are
three settings for account lockout policies. They are the following:

Account Lockout Duration
If a user does become locked out, this setting deter-
mines how long the user will be locked out before the user account is unlocked.
There is no default setting, because this setting is dependent on the Account
Lockout Threshold setting. The range is from 0 through 99,999 minutes. The

account will be locked out indefi nitely when this is set to 0 and therefore will
require an administrator to unlock it.

Account Lockout Threshold
This setting determines how many failed attempts
at logon Windows Server 2008 permits before a user will be locked out of the
account. The range is from 0 to 999. If this setting is 0, the account will never be
locked out and the Account Lockout Duration security setting is disabled. The
default setting is 0.

Reset Account Lockout Counter After
This setting is the number of minutes after
a failure to log on before the logon counter is reset to zero. This must be less than
or equal to the Account Lockout Duration setting if the Account Lockout Thresh-
old policy is enabled. The valid range is from 1 to 99,999 minutes.
When you are setting top-level account policy for the Default Domain Policy, these
policies are located in Computer Confi guration\Windows Settings\Security Settings\
Account Policies\Account Lockout Policy. When you are setting secondary account
policy for a PSO, you confi gure these settings using similarly named object attributes.
Chapter 35
1172 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Setting Kerberos Policy
Kerberos is an authentication system designed for secure exchange of information as
discussed in “NTLM and Kerberos Authentication” on page 1023. Windows Server
2008 has fi ve settings for Kerberos Policy, which are applied only to domain user
accounts. The policies can only be set for top-level account policy and are located in
Computer Confi guration\Windows Settings\Security Settings\Account Policies\Kerbe-
ros Policy. They are as follows:


Enforce User Logon Restrictions
If you want to validate every ticket session
request against the user rights, keep the default setting enabled.

Maximum Lifetime For Service Ticket
The default is 600 minutes, but this setting
must be greater than 10 minutes, and also must be less than or equal to what is
confi gured for the Maximum Lifetime For User Ticket setting. The setting does
not apply to sessions that have already been validated.

Maximum Lifetime For User Ticket
This is different from the Maximum Lifetime
For Service Ticket setting. Maximum Lifetime For User Ticket sets the maxi-
mum amount of time that a ticket may be used before either a new one must be
requested or the existing one is renewed, whereas the Maximum Lifetime For Ser-
vice Ticket setting is used to access a particular service. The default is 10 hours.

Maximum Lifetime For User Ticket Renewal
This user account security policy
object confi gures the maximum amount of time the ticket may be used. The
default is seven days.

Maximum Tolerance For Computer Clock Synchronization
Sometimes worksta-
tions and servers have different local clock times. This setting allows you to con-
fi gure a tolerance level (defaults to 5 minutes) for this possible difference so that
Kerberos authentication does not fail.
Note
If you change the Minimum Password Length setting to less than seven characters (the
default), you may not be able to create a new user or change a user’s password. To work

around this limitation, set the password length to seven or higher.
Creating Password Settings Objects and
Applying Secondary Settings
When you want to fi ne-tune the way account policy is applied, you need to create a
Password Settings group and add users, inetOrgPersons, and global security groups as
members of the Password Settings group. A Password Settings group is simply a global
security group that applies the desired secondary PSO rather than the default PSO.
Note
If you change the Minimum Password Length setting to less than seven characters (the
default), you may not be able to create a new user or change a user’s password. To work
around this limitation, set the password length to seven or higher.
Managing Domain User Accounts 1173
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Afterward, you have to create a Password Settings object with attributes that defi ne the
desired policy settings and then link this object to the Password Settings group.
Before you start, you should consider how you will organize your Password Settings
groups. In most cases, you’ll want to create Password Settings groups that closely
resemble the OUs in your domain. To do this, you’ll create Password Settings groups
with the same names as your OUs and then add users, inetOrgPersons, and global
security groups as members of these groups as appropriate to refl ect the organizational
structure of your OUs.
You can create the Password Settings group and defi ne its members using Active Direc-
tory Users And Computers, as discussed in “Managing Groups” on page 1215. By
default, only members of the Domain Admins and Schema Admins groups can create
PSOs. You can create a PSO and set its attributes by completing these steps:
1. Start ADSI Edit by clicking Start, clicking Administrative Tools, and then clicking
ADSI Edit.
2. Right-click the ADSI Edit node in the MMC and then select Connect To. This
displays the Connection Settings dialog box as shown in the following screen:

3. Choose Default Naming Context in the Select A Well Known Naming Context list
and then click Advanced. This displays the Advanced dialog box.
4. Select the Specify Credentials check box. In the Credentials panel, type the user
name and password of an account that is a member of Schema Admins.
5. Click OK to close both open dialog boxes.
6. In ADSI Edit, select and then expand the Default Naming Context node, and then
select and expand the CN=System node.
Chapter 35
1174 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
7. In the left pane, select the CN=Password Settings Container entry. A list of any
previously created Password Settings objects appears in the details pane.
8. Right-click the CN=Password Settings Container entry, point to New and then
select Object. This starts the Create Object wizard as shown in the following
screen:
9. On the Select A Class page, choose msDS-PasswordSettings and then click Next.
msDS-PasswordSettings is the internal directory name for PSOs.
10. In the Value text box, type the name of the Password Settings group and then
click Next. If you are naming your Password Settings groups after your OUs, this
should be the name of an OU in your domain.
11. In the Value text box, type the precedence order for the group and then click
Next. When multiple Password Settings objects apply to a user, the precedence of
the group determines which account policy settings are applied. A group with a
precedence of 1 always has precedence over a group with a lower precedence.
12. Set the reversible encryption status for passwords as either false or true and then
click Next. In most cases, you’ll want to turn this feature off to ensure passwords
are stored with strong encryption.
13. Set the password history length and then click Next. The maximum value is 24. If
you enter zero (0), a password history is not kept.
14. Set the password complexity status for passwords as either false or true and then

click Next. In most cases, you’ll want to turn this feature on to ensure users enter
complex passwords.
15. Set the minimum password length for user accounts and then click Next. The
maximum value is 14. If you enter zero (0), a password is not required.
Managing Domain User Accounts 1175
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
16. Set the minimum password age and then click Next. The age must be set in
duration format as DD:HH:MM:SS. The maximum value is 998:00:00:00 (998
days). If you enter zero (0), a password can be changed immediately.
17. Set the maximum password age and then click Next. The age must be set in
duration format as DD:HH:MM:SS. The maximum value is 999:00:00:00 (999
days). If you enter zero (0), passwords never expire.
18. Specify how many failed attempts at logon before a user is locked out and then
click Next. The maximum value is 999. If you enter zero (0), accounts will never
be locked.
19. Specify the number of minutes after a logon failure before the logon counter is
reset and then click Next. The counter time must be set in duration format as
DD:HH:MM:SS. The maximum value is 69:10:39:00 (99,999 minutes). The valid
range is from 1 to 99,999 minutes.
20. Specify how long a user will be locked out before the account is unlocked
automatically and then click Next. The counter time must be set in duration
format as DD:HH:MM:SS. The maximum value is 69:10:39:00 (99,999 minutes).
The valid range is from 1 to 99,999 minutes.
21. Click Finish to create the object with the attributes you’ve defi ned. If you’ve made
any mistakes in setting the attribute values, you’ll see an error message regarding
this and you can use the Back function to make changes to the previously
specifi ed values.
22. In ADSI Edit, right-click the PSO you just created and select Properties. In the
Properties dialog box, scroll through the list of attributes until you see msDS-

PSOAppliesTo. Select this attribute and then click Edit. This opens the Multi-
Valued Distinguished Name With Security Principal Editor dialog box.
23. Click Add Windows Account. This displays the Select Users, Computers, Or
Groups dialog box. Type the name of the Password Settings group you previously
created using Active Directory Users And Computers and then click Check
Names.
24. Click OK three times to close all open dialog boxes.
Note
You can link a PSO to other types of groups in addition to global security groups. How-
ever, when the resultant set of policy is determined for a user or group, only PSOs that
are linked to global security groups, user objects, and inetOrgPerson objects are con-
sidered. PSOs that are linked to distribution groups or other types of security groups
are ignored.
Note
You can link a PSO to other types of groups in addition to global security groups. How-
ever, when the resultant set of policy is determined for a user or group, only PSOs that
are linked to global security groups, user objects, and inetOrgPerson objects are con-
sidered. PSOs that are linked to distribution groups or other types of security groups
are ignored.
Chapter 35
1176 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A user, inetOrgPerson, or global security group can have multiple PSOs linked to it. This
can occur either because of membership in multiple groups that each have different
PSOs applied to them or because multiple PSOs are applied directly to the object. How-
ever, only one PSO is applied as the effective policy and only the settings from that PSO
affect the user, inetOrgPerson, or group. The settings from other PSOs do not apply and
cannot be merged in any way.
Active Directory determines the applicable PSO according to the precedence value

assigned to its msDS-PasswordSettingsPrecedence attribute. This attribute has an integer
value of 1 or greater. A lower value for the precedence attribute indicates that the PSO
has a higher priority than other PSOs. For example, suppose an object has three PSOs
linked to it. One PSO has a precedence value of 5, one has a precedence of 8, and the
other PSO has a precedence value of 12. In this case, the PSO that has the precedence
value of 5 has the highest priority and is the one applied to the object.
If multiple PSOs are linked to a user or group, the PSO that is applied is determined as
follows:
1.
A PSO that is linked directly to the user object is applied. If more than one PSO
is linked directly to the user object, the PSO with the lowest precedence value is
applied.
2.
If no PSO is linked directly to the user object, all PSOs that are applicable to the
user based on the user’s global group memberships are compared and the PSO
with the lowest precedence value is applied.
3.
If no PSO is linked directly or indirectly to the user object, the Default Domain
Policy is applied.
Microsoft recommends that you assign each PSO in the domain a unique precedence
value. However, you can create multiple PSOs with the precedence value. If multiple PSOs
have the same precedence value, the PSO with the lowest GUID is applied. Typically, this
means Active Directory will apply the PSO with the earliest creation date.
The user object has three attributes that override the settings that are present in the
applicable PSO: Reversible Password Encryption Required, Password Not Required, and
Password Does Not Expire. You can set these attributes in the userAccountControl attri-
bute of the user object in Active Directory Users And Computers.

Understanding User Account Capabilities, Privileges,
and Rights

All user accounts have specifi c capabilities, privileges, and rights. When you create a
user account, you can grant the user specifi c capabilities by making the user a member
of one or more groups. This gives the user the capabilities of these groups. You then
assign additional capabilities by making a user a member of the appropriate groups or
withdraw capabilities by removing a user from a group.
SIDE OUT
Understanding PSO precedence
A user, inetOrgPerson, or global security group can have multiple PSOs linked to it. This
can occur either because of membership in multiple groups that each have different
PSOs applied to them or because multiple PSOs are applied directly to the object. How-
ever, only one PSO is applied as the effective policy and only the settings from that PSO
affect the user, inetOrgPerson, or group. The settings from other PSOs do not apply and
cannot be merged in any way.
Active Directory determines the applicable PSO according to the precedence value
assigned to its msDS-PasswordSettingsPrecedence attribute. This attribute has an integer
value of 1 or greater. A lower value for the precedence attribute indicates that the PSO
has a higher priority than other PSOs. For example, suppose an object has three PSOs
linked to it. One PSO has a precedence value of 5, one has a precedence of 8, and the
other PSO has a precedence value of 12. In this case, the PSO that has the precedence
value of 5 has the highest priority and is the one applied to the object.
If multiple PSOs are linked to a user or group, the PSO that is applied is determined as
follows:
1.
A PSO that is linked directly to the user object is applied. If more than one PSO
is linked directly to the user object, the PSO with the lowest precedence value is
applied.
2.
If no PSO is linked directly to the user object, all PSOs that are applicable to the
user based on the user’s global group memberships are compared and the PSO
with the lowest precedence value is applied.

3.
If no PSO is linked directly or indirectly to the user object, the Default Domain
Policy is applied.
Microsoft recommends that you assign each PSO in the domain a unique precedence
value. However, you can create multiple PSOs with the precedence value. If multiple PSOs
have the same precedence value, the PSO with the lowest GUID is applied. Typically, this
means Active Directory will apply the PSO with the earliest creation date.
The user object has three attributes that override the settings that are present in the
applicable PSO: Reversible Password Encryption Required, Password Not Required, and
Password Does Not Expire. You can set these attributes in the userAccountControl attri-
bute of the user object in Active Directory Users And Computers.
Managing Domain User Accounts 1177
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
In Windows Server 2008, some capabilities of accounts are built in. The built-in capa-
bilities of accounts are assigned to groups and include the group’s automatic capa-
bilities. Although built-in capabilities are predefi ned and unchangeable, they can be
granted to users by making them members of the appropriate group or delegated by
granting the capability specifi cally, for example, the ability to create, delete, and man-
age user accounts. This capability is assigned to administrators and account operators.
Thus, if a user is a member of the Administrators group, the user can create, delete, and
manage user accounts.
Other capabilities of accounts, such as permissions, privileges, and logon rights, can
be assigned. The access permissions for accounts defi ne the operations that can be
performed on network resources. For example, permissions control whether a user can
access a particular shared folder. You can assign access permissions to users, comput-
ers, and groups as discussed in Chapter 17, “File Sharing and Security.” The privileges
of an account grant permissions to perform specifi c tasks, such as the ability to change
the system time. The logon rights of an account grant logon permissions, such as the
ability to log on locally to a server.

An important part of an administrator’s job is being able to determine and set permis-
sions, privileges, and logon rights as necessary. Although you can’t change a group’s
built-in capabilities, you can change a group’s default privileges and logon rights. For
example, you could revoke network access to a computer by removing a group’s right to
access the computer from the network. Table 35-1 provides an overview of the default
privileges assigned to groups. Table 35-2 provides an overview of the default logon
rights assigned to groups.
Table 35-1 Default Privileges Assigned to Groups
Privilege Description
Groups Assigned by
Default in Domains
Act As Part Of The
Operating System
Allows a process to authenticate as any
user. Processes that require this privilege
must use the LocalSystem account, which
already has this privilege.
None
Add Workstations To
Domain
Allows users to add new computers to an
existing domain.
Authenticated Users
Adjust Memory
Quotas For A
Process
Allows users to set the maximum amount
of memory a process can use.
Administrators, Local
Service, and Network

Service
Back Up Files And
Directories
Allows users to back up the system
regardless of the permissions set on fi les
and directories.
Administrators,
Backup Operators,
and Server Operators
Bypass Traverse
Checking
Allows users to go through directory trees
even if a user doesn’t have permissions
to access the directories being passed
through. The privilege doesn’t allow the
user to list directory contents.
Administrators,
Authenticated Users,
Everyone, Local
Service, and Network
Service
Chapter 35
1178 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Privilege Description
Groups Assigned by
Default in Domains
Change The System
Time
Allows users to set the time for the

computer’s clock.
Administrators, Server
Operators, and Local
Service
Change The Time
Zone
Allows users to set the time zone for the
system clock.
Administrators, Server
Operators, and Local
Service
Create A Pagefi le Allows users to create and modify the
paging fi le size for virtual memory.
Administrators
Create A Token
Object
Allows processes to create token objects
that can be used to gain access to local
resources. Processes that require this
privilege must use the LocalSystem
account, which already has this privilege.
None
Create Global
Objects
Allows a process to create global directory
objects. Most components already have
this privilege and it’s not necessary to
specifi cally assign it.
Administrators,
Service, Local Service,

and Network Service
Create Permanent
Shared Objects
Allows processes to create directory objects
in the Windows object manager. Most
components already have this privilege and
it’s not necessary to specifi cally assign it.
None
Create Symbolic Link Allows an application that a user is running
to create symbolic links. Symbolic links
make it appear as if a document or folder
is in a specifi c location when it actually
resides in another location. Use of symbolic
links is restricted by default to enhance
security.
Administrators
Debug Programs Allows users to perform debugging. Administrators
Enable User And
Computer Accounts
To Be Trusted For
Delegation
Permits users and computers to change or
apply the trusted account for delegation
setting, provided they have write access to
the object.
Administrators
Force Shutdown Of
A Remote System
Allows users to shut down a computer from
a remote location on the network.

Administrators and
Server Operators
Generate Security
Audits
Allows processes to make security log
entries for auditing object access.
Local Service and
Network Service
Increase A Process
Working Set
Allows an application that a user is running
to increase the memory that the related
process working set uses. A process
working set is the set of memory pages
currently visible to a process in physical
memory. Allowing for increases in memory
pages reduces page faults and enhances
performance.
Users
Managing Domain User Accounts 1179
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Privilege Description
Groups Assigned by
Default in Domains
Increase Scheduling
Priority
Allows processes with write access to a
process to increase the scheduling priority
assigned to those processes.

Administrators
Load And Unload
Device Drivers
Allows users to install and uninstall Plug
and Play device drivers. This doesn’t
affect device drivers that aren’t Plug
and Play, which can only be installed by
administrators.
Administrators and
Printer Operators
Lock Pages In
Memory
In Windows NT, allowed processes to keep
data in physical memory, preventing the
system from paging data to virtual memory
on disk.
Not used in Windows
2000 or later
Manage Auditing
And Security Log
Allows users to specify auditing options
and access the security log. You must turn
on auditing in the group policy fi rst.
Administrators
Modify An Object
Label
Allows a user process to modify the
integrity label of objects, such as fi les,
Registry keys, or processes owned by other
users. This privilege can be used to lower

the priority of other processes. Processes
running under a user account can modify
the label of any object the user owns
without requiring this privilege.
None
Modify Firmware
Environment Values
Allows users and processes to modify
system environment variables (not user
environment variables).
Administrators
Perform Volume
Maintenance Tasks
Allows administration of removable
storage, disk defragmenter, and disk
management.
Administrators
Profi le A Single
Process
Allows users to monitor the performance of
non-system processes.
Administrators on
domain controllers;
on member servers
and workstations,
Administrators and
Users
Profi le System
Performance
Allows users to monitor the performance of

system processes.
Administrators
Remove Computer
From Docking
Station
Allows undocking a laptop and removing
from network.
Administrators and
Users
Replace A Process
Level Token
Allows processes to modify the default
token for subprocesses.
Local Service and
Network Service
Chapter 35
1180 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Privilege Description
Groups Assigned by
Default in Domains
Restore Files And
Directories
Allows restoring backed-up fi les and
directories, regardless of the permissions
set on fi les and directories.
Administrators,
Backup Operators,
and Server Operators
Shut Down The

System
Allows shutting down the local computer. Administrators,
Backup Operators,
Print Operators, and
Server Operators
Synchronize
Directory Service
Data
Allows users to synchronize directory
service data on domain controllers.
None
Take Ownership
Of Files Or Other
Objects
Allows users to take ownership of any
Active Directory objects.
Administrators
Table 35-2 Default Logon Rights Assigned to Groups
Logon Right Description
Groups Assigned by
Default in Domains
Access Credential
Manager As A
Trusted Caller
Grants permission to establish a trusted
connection to Credential Manager.
Credentials, such as a user name
and password or smart card, provide
identifi cation and proof of identifi cation.
None

Access This
Computer From The
Network
Permits remote access to the computer. Administrators,
Authenticated Users,
and Everyone
Allow Logon Locally Grants permission to log on to the
computer interactively at the console.
Administrators,
Account Operators,
Backup Operators,
Print Operators, and
Server Operators
Allow Logon
Through Terminal
Services
Allows access through Terminal Services;
necessary for remote assistance and
remote desktop.
None
Deny Access To This
Computer From The
Network
Denies remote access to the computer
through network services.
None
Deny Logon As Batch
Job
Denies the right to log on through a batch
job or script.

None
Deny Logon As
Service
Denies the right to log on as a service. None
Managing Domain User Accounts 1181
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Logon Right Description
Groups Assigned by
Default in Domains
Deny Logon Locally Denies the right to log on to the
computer’s keyboard.
None
Deny Logon Through
Terminal Services
Denies right to log on through Terminal
Services.
None
Log On As A Batch
Job
Grants permission to log on as a batch job
or script.
Administrators,
Backup Operators,
and Performance Log
Users
Log On As A Service Grants permission to log on as a server.
LocalSystem account has this right.
Services that run under separate accounts
should be assigned this right.

None
Assigning User Rights
The most effi cient way to assign user rights is to make the user a member of a group
that already has the right. In some cases, however, you might want a user to have a
particular right but not have all the other rights of the group. One way to resolve this
problem is to give the user the rights directly. Another way to resolve this is to create a
special group for users that need the right. This is the approach used with the Remote
Desktop Users group, which was created by Microsoft to grant Allow Logon Through
Terminal Services to groups of users.
You assign user rights through the Local Policies node of Group Policy. Local policies
can be set on a per-computer basis using a computer’s local security policy or on a
domain or OU basis through an existing group policy for the related domain or OU.
When you do this, the local policies apply to all accounts in the domain or OU.
Assigning User Rights for a Domain or OU
You can assign user rights for a domain or OU by completing the following steps:
1. In the Group Policy Management Console, select the policy you want to work
with, and then click Edit. Access the User Rights Assignment node by working
your way down the console tree. Expand Computer Confi guration, Windows
Settings, Security Settings, Local Policies, and User Rights Assignment, as shown
in Figure 35-3.
Chapter 35
1182 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Figure 35-3 Configuring user rights in Group Policy.
2. To confi gure a user right, double-click a user right or right-click it and select
Properties. This opens a Properties dialog box, as shown in Figure 35-4. If the
policy isn’t defi ned, select Defi ne These Policy Settings. To apply the right to a
user or group, click Add User Or Group. Then, in the Add User Or Group dialog
box, click Browse. This opens the Select Users, Computers, Or Groups dialog box.
Figure 35-4 Define the user right, and then assign the right to users and groups.

3. Type the name of the user or group you want to use in the fi eld provided, and
then click Check Names. By default, the search is confi gured to fi nd built-in
security principals, groups, and user accounts. After you select the account names
or groups to add, click OK. The Add User Or Group dialog box should now show
the selected accounts. Click OK again.
4. The Properties dialog box is updated to refl ect your selections. If you made a
mistake, select a name and remove it by clicking Remove. When you’re fi nished
granting the right to users and groups, click OK.
Managing Domain User Accounts 1183
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Assigning User Rights on a Specifi c Computer
User rights can also be applied to a specifi c computer. However, remember that domain
and OU policy take precedence over local policy. This means that any settings in these
policies will override settings you make on a local computer.
You can apply user rights locally by completing the following steps:
1. Start Local Security Policy by clicking Start, Programs or All Programs,
Administrative Tools, Local Security Policy. All computers, even domain
controllers, have Local Security Policy. Settings available in the Local Security
Policy console are a subset of the computer’s local policy.
2. Under Security Settings, expand Local Policies and then select User Rights
Assignment.
3. Double-click the user right you want to modify. The Properties dialog box shows
current users and groups that have been given the user right.
4. You can apply the user right to additional users and groups by clicking Add User
Or Group. This opens the Select Users, Computers, Or Groups dialog box, which
you can use to add users and groups.
5. Click OK twice to close the open dialog boxes.
Note
If the options in the Properties dialog box are dimmed, it means the policy has been set

at a higher level and can’t be overridden locally.
Creating and Confi guring Domain User Accounts
As a member of the Account Operators, Enterprise Admins, or Domain Admins group,
you can use Active Directory Users And Computers to create user accounts. Follow
these steps:
1. Click Start, Administrative Tools, and Active Directory Users And Computers.
This starts Active Directory Users And Computers.
2. By default, you are connected to your logon domain. If you want to create OUs in
a different domain, right-click the Active Directory Users And Computers node in
the console tree, and then select Change Domain. In the Change Domain dialog
box, type the name of the domain to which you want to connect, and then click
OK. Alternatively, you can click Browse to fi nd the domain to which you want to
connect in the Browse For Domain dialog box.
3. You can now create the user account. Right-click the container in which you want
to create the user, point to New, and then select User. This will start the New
Object–User Wizard.
Note
If the options in the Properties dialog box are dimmed, it means the policy has been set
at a higher level and can’t be overridden locally.
Chapter 35
1184 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
When you create a new user, you’re prompted for the fi rst name, initials, last
name, full name, and logon name, as shown in Figure 35-5. The pre–Windows
2000 logon name then appears automatically. This logon name is used when a
user logs on to Windows NT, Microsoft Windows 95, or Microsoft Windows 98.
Figure 35-5 Creating a user account.
4. When you click Next, you can set the user’s password and account options. The
password must meet the complexity requirements set in the group policy. As
shown in Figure 35-6, these options are as follows:


User Must Change Password At Next Logon

User Cannot Change Password

Password Never Expires

Account Is Disabled
Figure 35-6 Set the user’s password and account options.
Managing Domain User Accounts 1185
Chapter 35
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

At the command line, you can create a user account using DSADD USER. For users, the
distinguished name (DN) for the account is used to set the account’s full name. For
example, you want to create a user account with the display name William Stanek in the
Technology OU for the cpandl.com domain. When creating the user object using DSADD,
you must specify the path as follows:
dsadd user "CN=William Stanek,OU=Technology,DC=cpandl,DC=com"
When you create an account in this way, the other properties of the account are set auto-
matically and the account is disabled by default. To resolve this, you would need to cre-
ate a password for the account and then enable the account.
Often, rather than have some properties set automatically, you’ll want to defi ne them
with specifi c values. This gives you more control and allows you to create the account so
that it is enabled for use. Use the following parameters:
-FN
to set the fi rst name
-MI
to set the middle initials
-LN

to set the last name
-Display
to set the display name
-samid
to set the logon name
-pwd
to set the password
To see how these parameters are used, consider the following example:
dsadd user "CN=William Stanek,OU=Technology,DC=cpandl,DC=com" -fn
William -mi R -ln stanek -Display "William Stanek" -samid williamstanek
-pwd TradeWinds45!
For the full syntax and usage, type dsadd user /? at a command prompt. The directory
services commands can also be used to manage user accounts. Use DSMOD USER to set
properties, including passwords and group membership. Use DSMOVE USER to move
users to a new container or OU. Use DSRM USER to remove user accounts. Tasks that you
might want to perform from the command line include:

Searching the entire domain for users with disabled accounts by typing dsquery
user -disabled.

Using dsmod user UserDN to set account fl ags -mustchpwd (yes | no),
-canchpwd (yes | no), -pwdneverexpires (yes | no), -disabled (yes | no).

Determining all users who have not changed their passwords in a specifi ed num-
ber of days by typing dsquery user -stalepwd NumDays where NumDays is the
number of days.

Determining all users who have not logged on in a specifi ed number of weeks by
typing dsquery user -inactive NumWeeks where NumWeeks is the number of
weeks.


Determining all the groups of which a user is a member by typing dsget user
UserDN -memberof and using the optional -expand parameter to determine all
the inferred group memberships based on the group of which other groups are
members.
SIDE OUT
Creating group accounts at the command line
At the command line, you can create a user account using DSADD USER. For users, the
distinguished name (DN) for the account is used to set the account’s full name. For
example, you want to create a user account with the display name William Stanek in the
Technology OU for the cpandl.com domain. When creating the user object using DSADD,
you must specify the path as follows:
dsadd user "CN=William Stanek,OU=Technology,DC=cpandl,DC=com"
When you create an account in this way, the other properties of the account are set auto-
matically and the account is disabled by default. To resolve this, you would need to cre-
ate a password for the account and then enable the account.
Often, rather than have some properties set automatically, you’ll want to defi ne them
with specifi c values. This gives you more control and allows you to create the account so
that it is enabled for use. Use the following parameters:
-FN
to set the fi rst name
-MI
to set the middle initials
-LN
to set the last name
-Display
to set the display name
-samid
to set the logon name
-pwd

to set the password
To see how these parameters are used, consider the following example:
dsadd user "CN=William Stanek,OU=Technology,DC=cpandl,DC=com" -fn
William -mi R -ln stanek -Display "William Stanek" -samid williamstanek
-pwd TradeWinds45!
For the full syntax and usage, type dsadd user /? at a command prompt. The directory
services commands can also be used to manage user accounts. Use DSMOD USER to set
properties, including passwords and group membership. Use DSMOVE USER to move
users to a new container or OU. Use DSRM USER to remove user accounts. Tasks that you
might want to perform from the command line include:

Searching the entire domain for users with disabled accounts by typing dsquery
user -disabled.

Using dsmod user UserDN to set account fl ags -mustchpwd (yes | no),
-canchpwd (yes | no), -pwdneverexpires (yes | no), -disabled (yes | no).

Determining all users who have not changed their passwords in a specifi ed num-
ber of days by typing dsquery user -stalepwd NumDays where NumDays is the
number of days.

Determining all users who have not logged on in a specifi ed number of weeks by
typing dsquery user -inactive NumWeeks where NumWeeks is the number of
weeks.

Determining all the groups of which a user is a member by typing dsget user
UserDN -memberof and using the optional -expand parameter to determine all f
the inferred group memberships based on the group of which other groups are
members.
Chapter 35

1186 Chapter 35 Managing Users, Groups, and Computers
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.