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-

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
[email protected]. 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

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-

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-

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

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

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

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

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.

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

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,

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.

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
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

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.

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


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


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

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