Protecting SAM and Security Hives
Windows NT/2000, Windows XP, and Windows Server 2003 security information is
stored in the SAM (Security Accounts Manager) and Security registry hives.

N
ote Although starting with Windows 2000, Microsoft has introduced the Active
Directory (AD)—arguably the most complex of new technologies, which in some
ways represents a further extension of the system registry, the SAM database has
retained its importance. In contrast to Windows NT 4.0 domain controllers, where
SAM used to be simply a registry hive, on native-mode Windows 2000 and
Windows Server 2003 domain controllers, the directory services database is stored
in the Ntds.dit file. The SAM is now part of the Active Directory, which serves as a
kind of "super-registry", storing all user and machine information, as well as a
whole host of other types of objects, including group policies and applications.
However, the SAM database continues to store local accounts (required to log on
locally). Furthermore, if your computer that is running Windows 2000, Windows
XP or Windows Server 2003 does not participate in a domain, the SAM database
remains the main storage of the user and group accounts information. Among other
things, it is important to notice that the Directory Service Restore Mode
Administrator password, which is separate from the Administrator password that is
stored in the Active Directory, resides in the local SAM
(%SystemRoot%\System32\Config\SAM).
The SAM hive contains user passwords as a table of hash codes; the Security hive stores
security information for the local system, including user rights and permissions, password
policies and group membership.

N
ote The SAM information is encrypted. However, there are many utilities that allow
you to crack the SAM hive. The most common examples are PWDUMP, NT Crack,
and L0phtCrack (at the time of this writing, the latest version was LC4).
How to Protect the SAM Hive

mounts NTFS volumes under DOS. This utility and its clones (for example, NTFS
for Windows 98) cause different, and sometimes negative, reactions (because of the
potential risk to the security subsystem). When the first version of NTFSDOS
appeared, Microsoft had to state officially that "true security is physical security".
N
TFSDOS, though, is one of the most useful tools for registry backup and recovery
and may be very helpful when performing emergency recovery (especially if this
has to be done very quickly). After all, whatever can be used for good, can also be
used for evil.
To summarize, in order to protect the SAM and Security files from unauthorized copying,
you need to provide true physical security for the computers you need to protect. Also,
don't assign every user the right to reboot the system.

N
o
t
e By default, this privilege is assigned to Administrators, Backup Operators, Power
Users, and Users on Windows 2000/XP workstations. On member servers, it is
assigned to Administrators, Power Users, and Backup Operators. On domain
controllers, it is assigned to Administrators, Account Operators, Backup Operators,
Print Operators, and Server Operators.
To edit the user permissions in Windows 2000, Windows XP, or Windows Server 2003,
log onto the system as a member of the Administrators group, open the Control Panel
windows, start Administrative Tools and select the Local Security Policy option.
Expand the MMC tree and select the User Rights Assignment option. The list of user
rights will appear in the right pane of this window (Fig. 9.19
).

Figure 9.19: The list of user groups allowed to reboot the system (Windows Server 2003
domain controller)

and represents a new version of the well-known L0phtCrack
password-auditing tool), your success mainly depends on the quality of the dictionary
you use (Fig. 9.20
).

Figure 9.20: Weak passwords are cracked by LC4 within a matter of minutes

N
ote Imagine that you want to hack your own SAM hive (and then try to do it).
Remember, your tasks are significantly easier than those of a hacker, because you
don't need to plan a remote attack to steal the SAM and Security hives. If you can
crack some passwords automatically, explain to the users who've specified these
passwords that they're compromising system security.
Thus, to protect the system, you need to:
 Ensure a strong account policy (or, at least, prevent users from setting blank
passwords and require that passwords be at least 8 characters long, use arbitrary
combinations of letters and digits, and specify the system policy in relation to
password complexity).
 Pay special attention to protecting the local Administrator account from misuse.
Ensuring Strong Account Policy in Windows Server 2003
An account policy is a collection of settings that influence user accounts and their ability
to authenticate the system. In other words, the account policy sets the standards for initial
access to the system and includes every setting that controls access in any form
(including file permissions, system objects permissions, dial-up permissions, and so on).
If account and password policies are set correctly, this will prevent many attempts of
intrusions into your system.
To create, examine, or set strong account and password policies in Windows Server 2003,
proceed as follows:
1. Click Start, select Run, and type secpol.msc in the Open field, then click OK, or,
alternately, open the Control Panel window, and select Administrative Tools |

passwords).
Table 9.2: Recommended Settings for the Password Policy
Setting Description Recommended setting
Maximum
password age
Setting the Password never expires checkbox
in the user account properties when creating or
editing user accounts is not a good idea. In
order to minimize chances that an intruder will
use a password that has been guessed or
cracked, it is necessary to have users
periodically change their passwords.
The default value is 42
days, but in sensitive
environments it is
recommended that users
reduce this value.
Minimum
password age
As was already mentioned, this setting supports
the Enforce password history policy. If you
don't change the default value (0), then the user
will immediately be able to change the
password in order to return to the original one.
At least 5 days.
Minimum
password
length
As was shown by the example presented in Fig.
9.21, password-cracking tools crack weak

Enabled.
Table 9.2: Recommended Settings for the Password Policy
Setting Description Recommended setting
letters, numbers, and keyboard special
characters.
This is important, since password-cracking
utilities are gradually becoming more and more
advanced. For example, the newest version of
LOphtCrack, LC4, implements an improved
hybrid cracking mode that can both append and
prepend characters to dictionary words, and
look for common substitutions — if the
dictionary word is "password", it will also
crack "password!", "!password", or even
"#$p@$$wOrd^%
".

Store password
using reversible
encryption
If you want to tighten security on your server,
don't turn this setting on. It is available for a
single purpose — to provide compatibility with
non-Microsoft clients that do not support newer
Windows authentication process (therefore,
such clients must be able to decrypt
passwords). Use this setting only if necessary
(i.e., if you have such clients in your network
environment).
Disabled.