The Best Damn Windows Server 2003 Book Period- P47 pdf

a tree that represents the directory tree. By browsing the folders in this tree, you can select the con-
tainer you want the object moved to, and then click OK to being the move.
When using Active Directory Users and Computers, multiple objects can be selected and moved
to other locations.You can select these objects as you would files in Windows Explorer, by dragging
your mouse over the objects to be moved.You can also select a series of objects by holding down
the Shift key as you click on objects, or select a number of individual objects by holding down the
Ctrl key as you click on them. After selecting the objects to be moved, perform the actions we just
discussed to move them to another container or OU.
Moving Objects with the DSMOVE Command
DSMOVE is used to move objects within a domain, and can be used to rename objects. DSMOVE
is a command-line utility that is used from the command prompt. Providing you don’t need to
move an object to another domain, you can use this tool to move an object to other locations in the
directory tree.The syntax for using this tool is as follows:
DSMOVE UserDN [-newparent ParentDN] -pwd {Password|*}
In using this syntax, several different parameters must be entered for moving the object.The
UserDN parameter specifies the DN of the object being moved.The –newparent switch indicates that
you are using DSMOVE to move an object, and is used with the ParentDN variable to specify the
DN of the new location.
To illustrate how this command is used, let’s say you wanted to move an object called BuddyJ
from the Sales OU in knightware.ca to the Finance OU in the same domain.To move this object,
you would use the following command:
Dsmove CN=BuddyJ,OU=Sales,DC=knightware,DC=ca –newparent
OU=Finance,DC=knightware,DC=ca
426 Chapter 10 • Working with User, Group, and Computer Accounts
Figure 10.41 Move Dialog Box
301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 426
DSMOVE also provides additional parameters to perform actions such as renaming an object, or
controlling the type of input and output for this command.To review these parameters, refer to the
section on DSMOVE in Chapter 9.
Moving Objects with the MOVETREE Command
MOVETREE is the Active Directory Object Manager tool. In addition to other capabilities, it is a

command-line tool that allows you to move objects to other domains in a forest. By using this tool,
you have the freedom to move a user account, computer account, group, or OU to any location
within the directory, regardless of the domain.
When an object is moved using this tool, it is first copied to the Lost and Found container
before being moved to the destination domain. Objects that can’t be moved remain in this con-
tainer, so you can manage them as needed. Because orphaned data might reside in this domain after
using MOVETREE, you should check this container after performing a move.
A variety of information isn’t moved with this tool.This includes data such as profiles, logon
scripts, and personal information when moving user accounts. Local groups and global groups also
aren’t moved, but membership in these groups remains unaffected so that security involving the
moved objects remains the same.
In addition to the limitations on data associated with accounts, there are also limitations when
MOVETREE is used to move OUs between domains. When an OU is moved, group policies
aren’t affected, as clients will continue to receive these settings from a link to the policy in the orig-
inal domain. In other words, although the OU is now in another domain, clients will connect to the
Group Policy Object (GPO) that is located in the original domain. Because this can cause perfor-
mance issues, it is wise to recreate these policies in the domain where the OU has been moved, and
then delete the GPO in the original domain (which is no longer needed).
As a command-line tool, MOVETREE requires that certain parameters be used to effectively
complete operations.The syntax for MOVETREE is as follows, and the parameters are explained in
Table 10.6.
MoveTree [/start | /continue | /check] [/s SrcDSA] [/d DstDSA]
[/sdn SrcDN] [/ddn DstDN] [/u Domain\Username] [/p Password]
[/quiet]
Table 10.6 Parameters for MOVETREE
Parameter Description
/start Specifies whether to start a move with a /check option, or
with the /startnocheck option, which starts the operation
without a check.
/continue Specifies to continue the move after a failure.

/check Specifies to check the entire tree before moving an object.
/s SrcDSA The SrcDSA variable is used to specify the FQDN of the source
server.
Working with User, Group, and Computer Accounts • Chapter 10 427
Continued
301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 427
Table 10.6 Parameters for MOVETREE
Parameter Description
/d DstDSA The DstDSA variable is used to specify the FQDN of the desti-
nation server.
/sdn SrcDN The SrcDN variable is used to specify the source subtree’s root
DN.
/ddn DstDN The DstDN variable is used to specify the destination subtree’s
root DN.
/u Domain\Username Specifies the domain and user account to use for the opera-
tion.
/p Password Specifies the password of the account to use for the operation.
/quiet Specifies that quiet mode should be used, suppressing
output.
The Active Directory Object Manager tool isn’t installed with Active Directory, and thereby
isn’t initially available for use. MOVETREE is available as part of the Active Directory Support
Tools on the installation CD, and can be installed through Windows Explorer. By accessing the
Support\Tools folder on the installation CD, right-clicking on SUPTOOLS.MSI, and then
choosing Install from the menu that appears, the Windows Support Tools Setup Wizard will
start. By following the instructions in this wizard, MOVETREE and the other support tools will be
installed.
You can use the following steps to install MOVETREE with AD support tools.
Install MOVETREE with AD Support Tools
1. Insert the Windows Server 2003 Server installation CD into your CD-ROM drive.
2. From the Windows Start menu, select Windows Explorer.

3. When Windows Explorer opens, expand the node representing your CD-ROM drive, and
then expand the Support | Tools folder.
4. When the contents of the Tools folder is displayed in the right pane, right-click on the
SUPTOOLS.MSI file and click Install in the context menu.
5. When the Windows Support Tools Setup Wizard appears, click Next to continue.
6. On the End User License Agreement screen, click I Agree to install these tools, and
then click Next to continue.
7. On the User Information screen, enter your name in the Name field, and the company
you work for in the Organization field. By default, these fields will already be completed
from information acquired from Windows Server 2003 Server. Click Next to continue.
8. On the Destination Directory screen, accept the default settings, and click Install Now
to install the tools.
428 Chapter 10 • Working with User, Group, and Computer Accounts
301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 428
9. A dialog box will appear showing that files are being copied to the folder specified in the
Destination Directory screen, and being installed on Windows Server 2003. Once com-
pleted, the final screen of the wizard will appear, informing you that the tools were suc-
cessfully installed. Click Finish to exit the wizard and complete the installation process.
Troubleshooting Problems with Accounts
Troubleshooting problems with accounts relies on the same methodologies and practices involved in
troubleshooting other problems in Windows Server 2003. It requires an understanding of functions,
configurations, and limitations. It also requires starting at the simplest possible solution for a problem
and working up to the most complex. For example, if a user’s account wasn’t working, you wouldn’t
start by restoring Active Directory from a previous backup from when the user was able to log on.
You might, however, check to see if the account was disabled or locked out.
It is important that you determine whether the problem exists with the user who’s logging on
from a computer, or with the machine itself.You’ll remember that Active Directory uses both com-
puter and user accounts. If a problem is resulting from the computer account, no user will be able to
perform a certain action from the machine, regardless of what user account is used.
At times, the problems that exist in a computer account might require resetting it. If you want

to reset a computer account, in Active Directory Users and Computers, you can right-click on
the account you want to reset, and then click Reset from the menu that appears. After a moment, a
message box will appear stating that the account was reset.
Another important part of troubleshooting is determining the scope of a problem. Is only one
person experiencing a problem, or are a number of people experiencing the same difficulties? In
doing so, you can determine whether the problem is with a user or computer account, or with a
group of which these members are a part.
The problem might not exist in the user’s account settings, but with DCs in the domain. For
example, if you couldn’t create security principals in Active Directory, the problem could stem from
the fact that the RID Master is unavailable.The DC that has the RID operations master role allo-
cates RIDs used for SIDs. Because SIDs can’t be issued to new user accounts, computer accounts,
and groups, these security principals can’t be created.
You could use the command netdom query fsmo to identify which computers are holding single oper-
ation master roles. Once you’ve identified the DC serving in a particular master role, you could
either repair the machine, or assign the operations master role to another machine. Before going
through all this work, however, you should remember that the reason why others can’t perform such
actions might be because they don’t have the proper rights, privileges, or permissions. In all cases,
remember to start by looking at the simplest possible solution first.
Working with User, Group, and Computer Accounts • Chapter 10 429
301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 429
301_BD_W2k3_10.qxd 5/12/04 12:28 PM Page 430
Creating User
and Group Strategies
In this chapter:
 Create a password policy for domain users.
 Plan a security group strategy.
 Plan a user authentication strategy.
Introduction
Knowing how to create users and groups and the procedures for moving and managing
them is only half the battle when it comes to effectively using these security objects on

the network.The network administrator must also be able to develop strategies for
authenticating the identity of anyone who uses network resources, and plan how to use
groups most effectively to provide the security and access needed.
In today’s connected world, proof of your identity is often required to ensure that
someone else is not trying to use your identity. It used to be that a username and pass-
word were sufficient to authenticate someone to a network. However, password authen-
tication is only the first step in true authentication of a user’s identity in today’s
environment.You must have a well-defined password policy, which includes account
lockout, password rotation, and other options to ensure limited access to your network.
In this chapter, we develop a password policy for your Windows Server 2003 network.
However, sometimes passwords and password policies are not enough, and we have to
take authentication to the next plateau.
Tools such as biometric devices, token devices, voice identification, and smart cards
are becoming much more mainstream for user authentication as the price continues to
drop and acceptance continues to rise. Smart cards are discussed in a later chapter
“Planning, Implementing, Maintaining Public Key Infrastructure.”
An effective authentication strategy works hand in hand with a security group
strategy.A well-designed group strategy will ensure that users receive only the appropriate
Chapter 11
431
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 431
level of access to resources on the network. It will also reduce the workload of the administrator and
make it easier to manage large numbers of users.
Creating a Password Policy for Domain Users
Since they are largely created and managed by end users, passwords have the potential to be the
weakest link in any network security implementation. Since passwords are the “keys to the
kingdom” of any computer system, the database that Windows Server 2003 uses to store password
information will be a common attack vector for anyone attempting to hack your network. Windows
Server 2003 offers several means to secure passwords on your network.A combination of technical
measures, along with a healthy dose of user training and awareness, will go a long way toward pro-

tecting the security of your network systems.
Creating an Extensive Defense Model
In modern computer security, a system administrator needs to create a security plan that uses many
different mechanisms to protect a network from unauthorized access. Rather than relying solely on
a hardware firewall and nothing else, defense in depth would also use strong passwords as well as other
mechanisms on local client PCs, in the event that the firewall is compromised.The idea is to create a
series of security mechanisms so that if one is circumvented, other systems and procedures are in
place to help impede an attacker. Microsoft refers to this practice as an extensive defense model.The
key points of this model are the following:
■
A viable security plan needs to begin and end with user awareness, since a technical mech-
anism is only as effective as the extent to which the users on your network adhere to it.As
an administrator, you need to educate your users about how to best protect their accounts
from unauthorized attacks.
■
Use the system key utility (syskey) on all critical machines on your network.This utility,
discussed later in this chapter, provides additional encryption for password information that
is stored in the Security Accounts Manager (SAM) and Active Directory databases.
■
Educate your users about the potential hazards of selecting the Save My Password feature or
any similar feature on mission-critical applications, such as remote access or VPN clients.
■
If you need to create one or more service accounts for applications to use, make sure that
these accounts have different passwords. Otherwise, compromise of one account might
leave multiple network applications open to attack.
■
If you suspect that a user account has been compromised, change the password immediately.
If possible, consider renaming the account entirely, since it is now a known attack vector.
■
Create a password policy and/or account lockout policy that is appropriate to your organi-

zation’s needs. It’s important to strike a balance between security and usability in designing
these types of account policies.
432 Chapter 11 • Creating User and Group Strategies
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 432
Strong Passwords
In discussing security awareness with your user community, one of the most critical issues to con-
sider is that of password strength.A weak password will provide potential attackers with easy access
to your users’ computers, and consequently the rest of your company’s network. Well-formed pass-
words will be significantly more difficult to decipher. Even though password-cracking utilities con-
tinue to evolve and improve, educating your users regarding the importance of strong passwords will
provide additional security for your network’s computing resources.
According to Microsoft, a weak password is one that contains any portion of your name, your
company’s name, or your network logon ID. For example, if a username was assigned as JSmith, and
the user’s password was Smith12!@!, that would be considered a weak password.A password that
contains any complete dictionary word—password, thunder, protocol—is also considered weak. It
should be understood that blank passwords are weak as well.
By comparison, a strong password will not contain any reference to your username, personal
information, company name, or any word found in the dictionary. Strong passwords should also be
at least seven characters long and contain characters from each of the following groups:
■
Uppercase letters A, B, C …
■
Lowercase letters z, y, x …
■
Numeric digits 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9
■
Non-alphanumeric characters !, *, $, }, etc.
Each strong password should be appreciably different from any previous passwords that the user
has created. P!234abc, Q!234abc, and R!234abc, although each meeting the described password cri-
teria, would not be considered strong passwords when viewed as a whole.

System Key Utility
Most password-cracking software used in attacking computer networks attempts to target the SAM
database or the Active Directory database in order to access passwords for user accounts.To secure your
password information, you should use the system key utility (the syskey.exe file itself is located in the
%systemroot%\System32 directory by default) on every critical machine that you administer.This
utility provides additional encryption for password information, which provides an extra line of defense
against would-be attackers.To run the utility, click Start | Run then type syskey and click OK.
Defining a Password Policy
Using Active Directory, you can create a policy to enforce consistent password standards across your
entire organization.The options you can specify include: how often passwords must be changed, the
number of unique passwords a user must use before being able to reuse one, and the complexity
level of passwords that are acceptable on your network. Additionally, you can specify an account
lockout policy that will prevent users from logging on after a specified number of incorrect logon
attempts. In this section, we discuss the steps necessary to enforce password and account lockout
policies on a Windows Server 2003 network.You can use the following steps to create a domain
password policy.
Creating User and Group Strategies • Chapter 11 433
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 433
Create a domain password policy
1. From the Windows Server 2003 desktop, open Start | Administrative Tools | Active
Directory Users and Computers. Right-click the domain that you want to set a pass-
word policy for, and select Properties.
2. Select the Group Policy tab, followed by the Default Domain Policy, as shown in
Figure 11.1. Click the Edit button.
3. Navigate to Computer Configuration | Windows Settings | Security Settings |
Account Policies | Password Policy. You’ll see the screen shown in Figure 11.2.
Using password policies, you can configure the following settings:
■
Enforce password history This option allows you to define the number of
unique passwords that Windows will retain.

434 Chapter 11 • Creating User and Group Strategies
Figure 11.1 The Group Policy Tab
Figure 11.2 Configuring Password Policy Settings
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 434
■
Maximum password age This setting defines how frequently Windows will
prompt your users to change their passwords.
■
Minimum password age This setting ensures that passwords cannot be changed
until they are more than a certain number of days old.
■
Minimum password length This option dictates the shortest allowable length
that a user’s password can be. Enabling this setting also prevents users from setting a
blank password.
■
Password must meet complexity requirements This policy setting, when
activated, forces any new passwords created on your network to meet the com-
plexity requirements.
■
Store passwords using reversible encryption This option stores a copy of the
user’s password within the Active Directory database using reversible (cleartext)
encryption.This is required for certain message digest functions and authentication
protocols to work properly.This policy is disabled by default and should be
enabled only if you are certain that your environment requires it.
4. For each item that you want to configure, right-click the item and select Properties.In
this case, we’re enforcing a password history of three passwords. In the screen shown in
Figure 11.3, place a check mark next to Define this policy setting, and then enter the
appropriate value.
Modifying a Password Policy
You can modify an existing Windows Server 2003 password policy by navigating to the policy sec-

tion of the appropriate computer or domain and make the changes. New and modified password
policies are only enforced when passwords are changed.Therefore, altering password policy does not
place an immediate burden on users.Typically, users won’t notice the policy change until their pass-
words expire and they are forced to set new ones. If you need to ensure that all passwords are forced
Creating User and Group Strategies • Chapter 11 435
Figure 11.3 Defining the Password History Policy
301_BD_W2k3_11.qxd 5/12/04 12:30 PM Page 435