Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

In a Windows environment any entity that can be uniquely identified is called a security principal. Unique identification allows security principals to be distinguished from one another. Users and machines are examples of security principals. Security principals are used in the context of both a local and a domain security authority (as illustrated in Figure 2.4). A security principal’s entry in a local or domain security authority’s security database (the SAM or AD) is usually referred to as an account. A user security principal has a user account in the SAM or AD, a machine—a machine account, and a service—a service account.

Figure 2.4: Security authority and security principals.

From Windows 2000 onward, machine security principals are true security principals: They can identify themselves to any other principal. This was not the case in NT4 and earlier Windows versions. A machine’s account name always ends in a dollar sign ($).

The unique identifiers that Windows uses to refer to security principals are logon names and security identities (SIDs). These will be explained next.

To verify a security principal’s claimed identity, Windows can use different authentication credentials. These credentials can be based on different authentication methods: passwords, smart cards, biometric data, and so forth. The main difference between these methods is the use of different credentials or things that uniquely identify an entity. Out-of-the-box Windows Server 2003 supports password-based and smart card–based authentication. Other authentication methods can be supported by using third- party software. Next we will provide more details on the Windows security principal identifiers and the default Windows credentials—passwords. Authentication methods are discussed extensively in Chapter 4.

So what’s the use, besides identification and authentication, of being a security principal? Every “security principal” can be used in other Windows security-related processes such as authorization, delegation, and auditing. A security principal can be granted access to resources (this process is known as authorization). It can also be granted administrative permissions (this process is known as delegation) and can be uniquely referred to in security logs (creating and maintaining security logs is the task of the auditing process). Authorization, delegation, and auditing will again be covered in later chapters.

Windows Server 2003 supports a new type of security principal: the iNetOrgPerson security principal. The enabler of this new principal type is the iNetOrgPerson AD object class. Contrary to the AD user object class (which is used to define plain user accounts) the iNetOrgPerson object class complies with an Internet standard: RFC 2798. The support for an RFC- compliant security principal type is important for companies planning to set up some kind of directory synchronization between AD and other non- Microsoft directories. iNetOrgPerson AD objects are true Windows security principals. Like any other user object, they can be used to define authorization settings or administrative delegation.

2.2.1 Security principal identifiers

Next we will discuss Windows Server 2003 security principal identifiers. We will look at logon names and security identifiers. Logon names are used by security principals when they authenticate themselves to a local or domain security authority. Security identifiers are of no use to normal users: They are used to refer to security principals by the Windows security processes.

Logon names

In a Windows Server 2003 environment, security principals can use different logon names. They can use their downlevel name or their user or service principal name (UPN or SPN).

A downlevel name has the format “domainname\username.” It was a security principal’s unique identifier in Windows versions before Windows 2000. Downlevel names can be used to refer to security principals in the kingdoms of both local and domain security authorities.

As mentioned earlier, Windows 2000 introduced the concept of a forest as an administrative and security boundary. The forest concept required the creation of a new type of unique security principal identifier. The latter is exactly the reason why Windows 2000 introduced the concepts of UPNs and SPNs.

User principal names

A UPN is of the format “username@company.com.” It consists of a security principal’s name, an @ symbol, and a DNS domain name. Their format is defined in RFC 822. The UPN is stored in the userprincipalname attribute of a Windows Server 2003 AD account object. UPNs can only be used to refer to security principals in the context of a domain security authority.

The uniqueness of a security principal’s UPN is validated every time a new AD account object and UPN are created: first by searching the local Active Directory Domain naming context, then by searching the global catalog.

In Windows Server 2003 (like in Windows 2000), there is no need for the DNS domain name portion of a UPN to correspond to the DNS domain name of the domain that contains the security principal definition. It needs to correspond to a domain that has a trust relationship with the principal’s domain or to an alternate domain name listed in the UPN suffixes attribute of the AD Partitions container (which is a part of the Configuration container). How to define UPN suffixes from the Windows graphical user interface (GUI) is explained in the following side note. UPN suffixes can enable security principals to log on with their e-mail address. The latter may be risky from a security point of view: A hacker sniffing SMTP traffic can immediately catch half of the user’s credentials.

Defining UPN Suffixes UPN suffixes can be set from the Windows Server 2003 GUI by using the properties of the Active Directory domains and trusts container in the Active Directory domains and trusts MMC snap-in—as illustrated in Figure 2.5. To add a UPN suffix, type the name of the suffix in the Alternative UPN suffix entry box, then click the Add button.

Figure 2.5: Defining UPN suffixes.

A nice thing about using a UPN for authenticating to a Windows Server 2003 domain security authority is that it takes away the requirement for a security principal to enter a domain name in the logon dialog box. When he or she types his or her UPN, the domain entry box will be automatically disabled. A UPN also stays the same independently of what happens with a security principal’s account object after its creation. The following administrative actions do not affect the UPN:

• Moving a security principal to another domain in the forest

• Renaming a security principal’s downlevel name

Service principal names

A service principal name (SPN) is a unique identifier for the security identity that is used by a Windows 2000 (or later) service. Like any other piece of code executing on a Windows machine, a Windows service must always run in the security context of a particular security identity.

SPNs were introduced in Windows 2000 to uniquely identify a service during the Kerberos authentication sequence. When a user sends a Kerberos ticket request for a particular service to the Windows Server 2003 Kerberos Key Distribution Center (KDC), it specifies the service he or she wants to connect to using its SPN. The SPN will also be specified in the ticket that is generated by the KDC. The user can use the ticket only to authenticate to the service that is identified by that particular SPN.

An SPN is very similar to the concept of a user principal name (UPN)— the unique identifier for a user in a Windows forest. Just like a UPN, an SPN must be unique in the Windows forest.

An SPN is stored in a security principal’s AD object: in the Service- PrincipalName attribute. Because many Windows services run in the security context of a machine account, you often find them in the ServicePrincipalName attribute of a machine’s AD object.

To look at the SPNs that are associated with a particular machine account, you can use the adsiedit or the setspn tools. Both are coming with the Windows Server 2003 Support tools. Adsiedit is a generic MMC-based tool that allows you to retrieve all kinds of AD information. Setspn is a command-line tool that specifically deals with SPN information.

Typing “setspn –L test1” at the command prompt will list all the SPNs that are linked to the machine called test1 (as illustrated in Figure 2.6). To add an SPN, use setspn with the -A switch. To delete one, use the -D switch.

To enable the user of a Windows service to construct the service’s SPN without completely knowing it, SPNs have a fixed format. In most cases the Kerberos software just gets an LDAP or HTPP URL from the user. To deal with the conversion from, for example, a URL to an SPN Windows includes a special OS function called “DsCrackNames.” The SPN format is specified here:

<ServiceClass>/<Host>:<Port>/<ServiceName>

The different SPN parts have the following meaning:

• <ServiceClass> is a string identifying the service. Examples are “www” for a Web service and “ldap” for a directory service.

  Figure 2.6: Using setspn to display the SPNs linked to a machine.

• <Host> is the name of the computer on which the service is running. This can be a NetBIOS or a DNS name.

• <Port> is an optional parameter for the service port number. It enables differentiating between multiple instances of the same service that are running on the same machine and that are using a different TCP/IP port number.

• <ServiceName> is an optional parameter used to identify the data or services provided by a service or to identify the domain served by a service.

Next is a sample SPN identifying the AD LDAP service of domain controller called DC1 in the sales.hewlettpackard.net domain:

Ldap/DC1.sales.hewlettpackard.net/SALES

Security identifiers

Every Windows security principal has a security identifier (SID). SIDs are used by Windows security-related processes such as authorization, delegation, and auditing to uniquely identify security principals.

The SID for a domain account is created by a domain’s security authority; the SID for a local account is created by a local security authority. The SID of a domain account is stored in the objectSid attribute of the account’s AD object. The SID of a local account is stored in a secured registry portion.

An important property of a SID is its uniqueness in time and space: A SID is unique within the scope of the environment where it was created (domain or local computer). It is also unique in time: If you create an object “Paul,” delete it, and recreate it with the same name, the new object will never have the same SID as the original object. The format of SIDs for local and domain authorities will be outlined next.

A set of interesting utilities to translate user account names to SIDs and the other way around are available on the Internet: look at the Web site of sysinternals for the getsid utility (http://www.sysinternals.com). On the Web site of ntbugtraq, you can find a copy of user2sid and sid2user (http:// www.ntbugtraq.com). You can also use the Support Tools getsid tool. Even though this is a SID comparison tool, you can use it to translate user names to SIDs. To see the SID linked to the account you used to log on to a Windows machine or domain, together with the SIDs of the groups you’re a member of, use the whoami tool with the /all switch.

Sysinternals provides a utility called newsid to generate new machine SIDs. This utility can be very useful when dealing with a machine cloning technology that doesn’t automatically generate a new SID for every cloned machine. A good example is the copying of VMWare images to create new virtual machines. When you bring these identical VMWare images together in the same domain you will experience machine SID problems. You can run newsid from the command line or from the Windows GUI. To run newSID from the command line and to automatically reset a computer’s SID, type

"newsid /a"

at the command prompt. In addition to generating new computer SIDs, newSID replaces all occurrences of the old SIDs with the new SIDs in the registry, in the registry objects’ ACLs, and in the file-system objects’ ACLs. newsid is available for free from http://www.sysinternals.com/ntw2k/source/newsid.shtml.

An SID is not the same as a global unique identifier (GUID). The SID is an object’s unique identifier within a Windows domain. It can be used for security-related processes. The GUID is an object’s unique identifier within the Active Directory database. It cannot be used in security-related processes. The GUID of an object never changes, whereas the SID can change. For example, when a user object is moved between two domains, it will receive a new SID—but the GUID will remain identical. To translate an object’s GUID to its AD Distinguished Name, have a look at the guid2obj utility. This utility can be downloaded from the following URL: http:// www.microsoft.com/windows2000/techinfo/reskit/tools/existing/guid2objo.asp.

SID layout

Let’s have a look at what an SID looks like. The string representation of an SID and its different components together with an example are shown in Table 2.5.

Table 2.6 shows the predefined Windows SID layouts. In this table the following conventions are used:

• “TA” represents the identifier for the top-level authority (as shown in Table 2.7).

  Table 2.7: SID Top-Level Authorities

  Top-Level Authority Value	Meaning
  0	SID_IDENTIFIER_AUTHORITY
  1	SECURITY_WORLD_SID_AUTHORITY
  2	SECURITY_LOCAL_SID_AUTHORITY
  3	SECURITY_CREATOR_SID_AUTHORITY
  4	SECURITY_NON_UNIQUE_AUTHORITY
  5	SECURITY_NT_AUTHORITY
  9	SECURITY_RESOURCE_MANAGER_AUTHORITY

• “X” and “Y” represent two 32-bit fields that are used to uniquely identify a logon session.

• “WM1,” “WM2,” and “WM3” represent three 32-bit fields used to uniquely identify a workstation or member server.

• “D1,” “D2,” and “D3” represent three 32-bit fields used to uniquely identify a Windows domain.

• “RID” represents a relative identifier. This is a value above 1,000 that is maintained in an incremental way by the OS.

• “WID” represents a well-known identifier or an RID with a predefined meaning.

Well-known SIDs and RIDs

Because an SID is unique in space and time, this does not mean that different Windows kingdoms cannot contain identical SIDs. Examples are the well-known SIDs such as the SIDs for the everyone or administrator groups. The administrator groups occur in the context of every Windows domain authority. A list of well-known SIDs and RIDs and their function is shown in Tables 2.8 and 2.9. In Table 2.9, the XXX represents domain SIDs.

* Contrary to Windows 2000, in Windows Server 2003 the Administrator account can be disabled. System or domain administrators may want to do this to better protect against misuse of this powerful account.

† Like the administrator account, the guest account can be disabled in Windows Server 2003 (which is the default). You can also delete it from a Windows system using the del- guest utility that’s available from http://ntsecurity.nu/toolbox/.

2.2.2 Password credentials

Credentials are used by security authorities to verify a security principal’s claimed identity. In this chapter we will explore the Windows default credentials: passwords. Chapter 4 contains more information on other credential types that can be used in the context of a Windows Server 2003 setup.

Although password credentials are not the best way to identify security principals, they are certainly the most widely used credentials. They are the default Windows credentials, and any security principal can use them. Without them you have to install extra hardware or software. In the following sections we will look at how password quality can be enhanced and how you can audit password quality. We will also pay special attention to machine passwords.

The Local Service and Network Service Accounts In Windows 2000 and earlier versions, Windows services and third-party applications typically ran in the security context of the local system account (also referred to as the LSA account: S-1-5-18). Running a service in the context of the local system account gives it almost unlimited privileges on the Windows system. The local system account’s powers are comparable to those of the root account on UNIX systems.

To deal with this problem, Microsoft provides new accounts: the local service (S-1-5-19) and the network service (S-1-5-20). Both accounts have significantly fewer privileges than the local system account. The local service account can be used for services or applications that only access local system resources. The network service account can be used for services or applications that access network resources.

Examples of Windows Server 2003 services that are using the local service account by default are the smart card, remote registry, and telnet service. Examples of services using the network service account by default are the DNS client, the DHCP client, and the license logging service.

When you want to configure a service to use one of these new accounts, you must enter the service accounts manually—you cannot simply select them from a list. To configure the local service account, type NT Authority\LocalService; and to configure the network service account, type NT Authority\NetworkService (as illustrated in Figure 2.7).

Figure 2.7: Configuring a service to use the local service account.

Enhancing password quality

Three important recommendations to enhance password quality in a Windows environment are to use the built-in Windows password policies, to provide your users with guidelines for choosing high-quality passwords, and to regularly audit the password quality. I strongly advise you to implement these guidelines—they are your first line of defense against hackers and malicious users trying to exploit the inherent weaknesses of passwords. These three guidelines will be explored in more detail in the following sections.

Microsoft is also aware of the importance of good password quality: law five of their 10 immutable laws of security^[2] states: “Weak passwords trump strong security.”

Password policy settings

Table 2.10 gives an overview of all password-related Group Policy Object (GPO) settings—of which the password policy settings are certainly the most important ones. GPOs are an important Windows administration tool that can be used by administrators to centrally control the system configuration settings of Windows workstations and servers in a domain environment. The table does not include the machine account password-related settings; these are discussed later.

* More details on the differences between the LAN Manager hash of a password and the more secure NT hash of a password will be provided in Chapter 4.

Password policy settings can be just like any other account policy setting, only defined on the domain level. You cannot enforce a specific password policy for the users in a particular AD organizational unit (OU), for example.

User password guidelines

The most important guideline you can give your users is to choose truly random passwords. There are some tools available that you point your users to in order to help them choosing random passwords. The easiest solution is to let users use the net user command with the /random switch (as Figure2.8 shows for user joe). The command automatically generates a strong random password and assigns it to the user account.

Figure 2.8: Using net user with the /random switch.

Another solution is to use an online password generation service (like the one at http://www.winguides.com/security/password.php) or a stand- alone password generation program (like the one available from http:// www.mark.vcn.com/password/). A Google search for “password generator” will reveal more similar tools. These password generation tools typically generate a random password of a length and complexity specified by the user—they also let you generate multiple random passwords in a single run. The online password generation services are accessible for free. Some of the stand-alone programs have to be purchased.

You may also recommend your users to choose passwords that include special characters that cannot be detected by password cracking tools (these tools are covered next). The 187 special characters that cannot be detected are listed on the Web site http://sysopt.earthweb.com/articles/win2kpass.

Checking password quality

To perform basic password quality tests, you can use the Microsoft Baseline Security Analyzer (MBSA). The MBSA tool (illustrated in Figure 2.9) (version 1.1.1 at the time of this writing) can check for the following password conditions:

• Password is blank.

• Password is the same as the user account name.

• Password is the same as the machine name.

• Password uses the word “password.”

• Password uses the word “admin” or “administrator.”

  Figure 2.9: Using the MBSA tool to audit password quality.

MBSA version 1.1.1 also includes a command-line version (mbsacli.exe) that can perform the same checks.

For advanced password quality tests, I recommend that you look at a set of third-party tools that can crack the password hashes Windows stores in the security database (the SAM or Active Directory) and sends across the network during authentication exchanges. These tools are not just hacking tools; they are also excellent tools to run regular password quality audits on your Windows domains. To run the tools, you need administrator privileges on the local system. Next we will discuss two such tools: L0phtcrack and John the Ripper. Another tool with similar capabilities is the Elcomsoft Advanced NT Security Explorer (More information is available at http://www.elcomsoft.com/antexp.html.)

L0phtcrack L0phtcrack was originally developed by the hacker group, the Cult of the Dead Cow. You can get a trial copy of the latest version of the tool (currently version 4.0) from the @Stake Web site at http://www.atstake.com/research/lc/download.html. The tool is also referred to as LC4. Figure 2.10 shows the LC4 GUI.

Figure 2.10: L0phtcrack GUI.

In a Windows Server 2003 environment, LC4 can retrieve the password hashes from different sources:

• From the local SAM or AD database. This method requires administrator privileges.

• From a remote SAM or AD database. This method requires administrator privileges.

• By sniffing the network for an NTLM version 1 authenticationrelated challenge-response exchanges. If NTLM version 2 is used, LC4 cannot retrieve password hashes using this method. There is more information on the difference between NTLM versions 1 and 2 and how to configure Windows to use either or both of these versions in Chapter 4.

• By importing the output file of a pwdump3.exe-run. Pwdump3 is a command-line tool that can be used to retrieve password hashes from a Windows security database (AD or SAM). You can download the tool from the Polivec Web site at http://www.polivec.com/pwdump3.html. Pwdump3 uses a technique that is known as DLL injection to run code in the security context of the LSASS process. It must be run in the security context of an administrator account. To use pwdump3.exe, extract the pwdump3 zip file, then run the Pwdump3 command from the directory that contains pwdump3.exe.

Another method that was available on pre-Windows 2000 systems was to retrieve the hashes directly from a SAM file. This method did not necessarily require that the user accessing the SAM was logged on with administrator privileges (he or she could easily retrieve the SAM from an Emergency Repair Disk (ERD) or by booting a Windows box in DOS). The reason why this does not work on Windows 2000 and later OS versions is because they have the syskey protection feature enabled by default. Syskey provides an additional layer of encryption for SAM password hashes. It can only be circumvented if the SAM is accessed in the security context of an administrator account. Syskey is explained in more detail in the following side note.

LC4 supports different methods for cracking Windows 2000 password hashes: dictionary, hybrid, and brute force cracks. When starting a cracking session, L0phtcrack runs the three methods in the following order: first dictionary, then hybrid, and finally brute force. You can disable or enable the crack methods using the LC4 Auditing options, which are available from the Session\Session Options menu option.

During a dictionary crack, LC4 encrypts (hashes) all of the passwords listed in a predefined password file and compares every result to the password hash. If they match, LC4 knows the actual password is the dictionary word. LC4 comes with a default password file, named the words-english file. Many other dictionary files can be downloaded from the Internet. You can also create your own custom password file and load it into L0phtcrack.

During a hybrid crack, LC4 extends the dictionary crack by adding simple number and symbol patterns to the word list in the password file. For example, as well as trying out the word “Galileo,” L0phtcrack will also try “Galileo24,” “13Galileo,” “?Galileo,” and so on. The number of characters in the pattern can be specified in the characters field of the Auditing Options dialog box. The default number of characters is 2.

When performing a brute-force crack, LC4 tries every possible combination of characters. The characters LC4 uses can be defined in a character set. This set can be specified in a password file or using the Character Set drop-down box in the Auditing Options dialog box. The default character set is the alphanumeric set, A–Z, 0–9. An important detail is that in LC4 the brute-force crack option is only available if you pay a license fee for the tool. The prices are about $350 for a normal license and $1,750 for a consultant license.

Syskey Protection of SAM and AD Security Data The Syskey adds an extra level of encryption for the password hashes stored in the SAM database and AD. By default, syskey is enabled on any Windows Server 2003 system.

Out of the box, the syskey encryption key is stored on the local system—definitely a bad idea for systems that require a very high level of security. That is why you might want to consider prompting for the syskey password at system startup. To set this up, type “syskey” at the command prompt, choose update, and select the “password startup” option. Syskey also offers the possibility to store the startup key on a floppy disk.

The easiest way to find out whether an NT machine has Syskey enabled is to type “syskey” at the command prompt. This command brings up the Securing the Windows Account Database dialog box (shown in Figure 2.11), which indicates whether Syskey encryption is enabled.

Figure 2.11: Configuring Syskey.

Alternately, you can check for the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Secureboot. If the Secureboot value (of type REG_DWORD) exists and is set to a value of 0x1, 0x2, or 0x3, Syskey is enabled on the system.

More information on syskey can be found in the MS Knowledge Base article Q143475.

John the Ripper Unlike LC4, John the Ripper (JtR) is a command-line password cracking tool that is free (including its brute-force cracking function). You can download the tool from http://www.openwall.com/john. Be sure that you download the Win32 binaries. A distributed version of JtR (called Distributed John) is available from http://ktulu.com.ar/en/djohn.php . It can distribute the cracking load across different machines.

Also unlike LC4, JtR does not include tools to retrieve the password hashes from the NT SAM or Active Directory or to sniff the network for password hashes. To retrieve the hashes, you need a tool like pwdump3.exe (explained earlier). The following command dumps all password hashes to a file called passwd.lanman and stores the file in the D:\john\run directory:

Pwdump3 >D:\john\run\passwd.lanman

If you use Notepad to open the passwd.lanman file, you will see output similar to that in Figure 2.12. Note that the file contains one line for every user account in the SAM. A set of colon-separated alphanumeric values that represent the password hash follows each user account name.

Figure 2.12: Pwdump3 output.

Next, switch from the directory that contains pwdump3.exe to the directory that contains the JtR executable called john.exe, which by default is in the \john-16\run directory. Before starting the password cracking process, test whether JtR is operating properly on your system. To do so, type the following at the command line:

john -test

This command starts a JtR benchmarking test that checks the JtR cracking speed for different password hashing formats. You will notice that in addition to cracking NT password hashes, JtR can crack the password hashes on FreeBSD, OpenBSD, and other UNIX systems.

When the benchmark terminates without an error, you can start the password cracking process. JtR can do both dictionary-based and bruteforce–based password cracking. By default, JtR performs a dictionary-based password crack. To start that cracking process on the password hashes in the passwd.lanman file, you would type the following at the command prompt (illustrated in Figure 2.13):

Figure 2.13: Running John the Ripper.

john passwd.lanman

To start a brute-force–based password cracking process, use the -incre- mental switch:

john -incremental:all passwd.lanman

When you use the -incremental switch, you must include an incremental option (e.g., all in this example), which specifies the brute-force cracking scheme used. For details about all the incremental options and how to configure them, see the documentation that accompanies the JtR tool.

JtR saves its results in the john.pot file. To see an overview of the cracked passwords for the passwd.lanman file, type the following at the command prompt, as Figure 2.13 shows:

john -show passwd.lanman

To speed up the password cracking process, JtR lets you use different dictionary files, test only specific password combinations, or spread the password cracking load across different computers. By default, JtR uses the password.lst dictionary file, which contains commonly used passwords and comes with the JtR software. To discover other dictionary files, simply do a Google or Yahoo! search for the term “dictionary file.” You can use the -wordfile switch to specify other dictionary files. For example, the following command uses the mydict.lst dictionary file.

john -wordfile:mydict.lst passwd.lanman

To test only specific password combinations, you can specify a set of password rules in a file called conf.ini, add conf.ini to the JtR configuration file, then run the tool with the -rules switch:

john -rules passwd.lanman

Spreading the cracking process across multiple machines significantly speeds up the process but is rather complex to set up. Spreading the load uses a different JtR restore file for every computer that participates in the cracking process.

Machine passwords

Many people forget that in a Windows domain environment, machine security principals have—just like user security principals—a password. The reason why many people forget this is mainly because a machine’s password cannot be dealt with directly from the Windows GUI—most of the machine password-related maintenance tasks occur automatically without any administrator intervention.

The OS changes machine passwords automatically every 30 days. Unlike user passwords, a machine’s password cannot be reset from the Windows Server 2003 GUI. An administrator can reset a user password from the Users and Computers MMC snap-in: by right-clicking the account object and selecting “reset password…” You can, however, use the command prompt tool “netdom” with the “/resetpwd” switch (this tool comes with the Windows Server 2003 support tools) to force a machine password change. Doing so will write a copy of the new password to the local LSA database and to the Active Directory (the domain credential database).

Windows Server 2003 includes a set of GPO settings to change the machine password update behavior. The GPO settings together with their corresponding registry hacks are listed in Table 2.11. All registry keys are located in the HKEY_LOCAL_MACHINE\system\currentcontrolset\services\netlogon\parameters registry container.

One of the hacks allows you to disable password changes. From a security point of view, it is obviously a bad idea to disable password changes because it makes machines more vulnerable to hacker attacks.

2.2.3 Account lockouts

From its early versions Windows has come with a security feature known as account lockout. Account lockout assures that user accounts automatically become unusable when a user has entered a certain amount of bad passwords. The bad password threshold is defined by an administrator in the account lockout security policy. Administrator accounts are not subjected to the account lockout policy. Account lockout protects your Windows systems against acount spoofing and hijacking. On the other hand, it can also be looked at as a great denial-of-service (DOS) attack tool: hackers could lock out all your Windows accounts, making it impossible for anyone except your administrators to log on the Windows infrastructure.

When an account is locked out, only an administrator can unlock it. To do so, the administrator must uncheck the “account is locked out” check- box in the account tab of the account properties (using the AD Users and Computers MMC snap-in).

Account lockout should not be confused with disabling an account, which is the consequence of an explicit action performed by the administrator—it does not occur automatically following, for example, a set of security policy settings.

Account lockout process

Figure 2.14 illustrates the Windows 2000 and Windows Server 2003 account lockout process. In this process a domain’s PDC emulator plays the key role.

• Step 1: A user attempts to log on to a Windows domain using a wrong password.

• Step 2: The authenticating DC detects the password is wrong. To make sure that the user really entered a wrong password—and that the problem is not caused by AD replication latency—the authenticating DC double-checks with the domain’s PDC emulator.

• Step 3: The PDC emulator checks the password and detects it is really wrong. The PDC emulator increments the BadPwdCount attribute in the user account object’s properties with 1.

• Step 4: The PDC emulator informs the authenticating DC about the fact that the user’s password was really wrong.

• Step 5: The authenticating DC updates the BadPwdCount attribute in his local AD copy of the user account object.

• Step 6: The user is informed about the fact that he provided a wrong password.

  Figure 2.14: Account lockout process.

If the user’s BadPwdCount property exceeds the value defined in the Account Lockout Threshold of the domain’s lockout policy (explained later), the user’s account will be marked as locked out. The BadPwdCount property is automatically reset to 0 when the user enters a correct password following a set of bad password entries.

In Windows Server 2003 the DCs perform a password history check before a user’s BadPwdCount attribute is incremented. The password provided by the user is checked against the two last passwords in the user object’s password history (stored in the NtPwdHistory user object attribute).

Besides the BadPwdCount property, every Windows Server 2003 account object also has the following account lockout–related property: the BadPasswordTime property. The BadPasswordTime property contains the last time the user, machine, or service submitted a bad password to the authenticating DC. Both the BadPwdCount and the BadPasswordTime property are not replicated between DCs. The authenticating DC only replicates it to the PDC emulator of the domain.

Account lockout policy

A Windows 2000 and later domain’s account lockout policy settings are set from the account lockout portion of a domain group policy object. They are located in the Computer Configuration\Windows Settings\Security Settings\Account Policies GPO container. Like all other account policies (pass- word and Kerberos policies), they can only be applied on the Windows domain level.

Table 2.12 shows a set of recommended values for the account lockout policy settings. To make sure that account policies (including account lock-out policies) are always evaluated (in other words, to make sure that logging on using cached credentials will not work), it is also advisable to use the “Interactive logon: require domain controller authentication to unlock workstation” GPO setting (also known as the forceunlocklogon registry hack). The latter is explained in the side note.

If you are setting the account lockout policies for the very first time (e.g., if you have defined an account lockout threshold), Windows Server 2003 will automatically suggest a set recommended settings for the “account lockout duration” and “reset account lockout counter after” account lockout policy settings. This is illustrated in Figure 2.15.

Figure 2.15: Suggested account lockout policy settings.

Account lockout–related management tools

Early Windows 2003 Microsoft added some interesting new account lockout–related tools to their management tool portfolio. Microsoft provides some of these tools as part of the Windows Server 2003 Resource Kit. All of them are also available in a software package that is downloadable for free from the Microsoft Web site (look for the altools.exe file). Table 2.13 gives an overview of these tools.

Making Sure That Account Security Policies Are Enforced When a User Unlocks the Windows Console When a user unlocks the Windows console, he or she will be logged on using cached credentials (explained in Chapter 3). This means that the account security policies (including the account policies) are not enforced—which is a potential security hole.

To make sure that the account security policies are enforced when a user unlocks the Windows console, change the following GPO setting: “Interactive logon: require domain controller authentication to unlock workstation.” It is located in the Machine Configuration\Windows Settings\Security Settings\Local Policies\Security Options GPO container.

Under the hood this GPO setting changes the ForceUnlockLogon registry key located in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\. Setting it to value 1 means the account policies will be checked on a DC when the console is unlocked. This also means you won’t be able to unlock the console when no DC is available.

The acctinfo.dll adds a new property tab to an AD user account’s properties (as illustrated in Figure 2.16). The new tab holds different types of account logon feature–related information. A very interesting feature of the tool is its capability to reset a user’s password on a specific DC in the domain. This can be done by clicking the “Set PW on Site DC” push button at the bottom of the “Additional Account Info” tab. To add the tab to your AD account properties, register the acctinfo.dll on every machine from which you’re using the AD Users and Computers MMC snap-in. To register a dll, use the regsvr32.exe command-line tool.

Figure 2.16: Additional account info tab.

The alockout.dll helps with identifying the program or service that is causing an account lockout or—in other words—the entity that is sending the wrong credentials. In the altools.exe file it comes in two versions: one for Windows 2000 and Windows Server 2003 and another one for Windows XP. To install the tool, use the appinit.reg registry file that comes together with the tool. When the dll is installed and an account lockout occurs, alockout.dll generates an entry in the alockout.txt file—which is stored in the %windir%\debug folder. Microsoft does not recommend using this tool on servers running important network services or applications (such as Microsoft Exchange).

Aloinfo.exe is a command-line tool that can be used to display a list of the user accounts stored in AD and the amount of days that are left before their passwords expire. To retrieve this information, type the following aloinfo command at the command line:

Aloinfo /expires /server:<servername>

Another interesting tool is lockoutstatus.exe. It is a GUI tool (illustrated in Figure 2.17) that can be used to query for the account lockout–related information of a particular user account on the different domain controllers of a domain. It displays the following information:

• Status of the BadPwdCount attribute on different domain controllers

• Last time a bad password was entered

• Time the password was set for the last time

• Time when the account was locked out

• Name of the domain controller that locked the account (in the “originating lock” field): This is the domain controller that wrote to the Lockouttime attribute of the user account.

  Figure 2.17: LockoutStatus.exe tool.

Under the hood, LockoutStatus.exe uses the NLParse.exe tool to parse the Netlogon logs for specific Netlogon return status codes. The tool’s output can be saved to a comma-separated value text file.

2.2.4 Security-specific AD replication mechanisms

Active Directory provides some specific replication mechanisms to efficiently distribute critical security information such as account lockouts, password updates, global LSA secret changes, and security policy changes in a Windows domain. By default, AD replication takes place at predefined intervals. AD has three security-specific replication mechanisms: immediate, urgent, and single-user-object “on-demand” replication. The differences between the three mechanisms are outlined in Table 2.14.

From an account lockout point of view, there is an important link between urgent and immediate replication: When an account is locked out or unlocked, urgent replication starts, which then triggers immediate replication.

Immediate replication works by default within an AD site. Between AD sites it only works if intersite change notifications are enabled. To enable intersite change notifications, you must enable it in the options attribute of the AD site link object. Site link objects are located at the following AD path: CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=<ForestRootDomainName>. To enable change notifications, set the rightmost bit in the site link object’s options attribute to 1. To change the delay for intersite change notification messages, modify the value of the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\Current- ControlSet\Services\NTDS\Parameters\ Replicator notify pause after modify. The default value is 300 seconds.

Immediate replication can also be disabled within a site for specific DCs (e.g., if there is a slow WAN link between the DC and the PDC emulator). To do so, use the following GPO setting: “Contact PDC on logon failure” located in Computer Configuration\Administrative Templates\System\Net Logon.

Under the hood, this GPO setting changes the following registry key: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\Avoid- PdcOnWan (Value 1 means immediate replication is disabled).

Single-user-object on-demand replication can be enabled or disabled by changing the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa SamDisableSingleObjectRepl. If this key holds value 1, single-user-object on-demand replication is disabled. More information on single-user-object on-demand replication can be found in the following Microsoft KB article: http://support.microsoft.com/?id=812499.

^[2]http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/essays/10imlaws.asp.