If you enable nolmhash in a clustered Windows 2003 or Win2K environment, you must make sure that the Cluster service account password is at least 15 characters long. If you don't do this, you'll experience problems when using the Cluster Administrator tool. See the Microsoft article "Cluster service account password must be set to 15 or more characters if the NoLMHash policy is enabled" at http://support.microsoft.com/?kbid=828861 for more information about this issue.
To ensure that your users are using the stronger NTLMv2 authentication protocol, you must make the NTLMv2 software logic available to users that are running older Windows platforms. On Win98 and Win95 systems, install the Directory Services client, which you can download at http://down load.microsoft.com/download/0/0/a/00a71 61e-8da8-4c44-b74e-469d769ce96e/dsclient9x.msi. The NTLMv2 logic is available on Windows 2003, XP, Win2K, or any NT machine running SP4 or later.
To force your clients to use NTLMv2 in a Windows 2003 or Win2K AD environment, you can set the Network Security: LAN Manager Authentication Level GPO setting to the value Send NTLMv2 response only, refuse LM. You can get the same effect by setting the corresponding registry subkey, HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Control\Lsa\lmcompatibilitylevel (REG_DWORD), to value 4. This subkey and its values are also documented in the Microsoft article "LmCompatibilityLevel" at http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/regentry/76052.asp.
Finally, Windows won't generate an LM hash if users honor these password rules:
- Use a password that's longer than 14 characters, or
- Use certain ALT characters in the password. To enter these ALT characters, type a four-digit numeric code while holding down the ALT key. The ALT characters that prevent an LM hash are listed in Web Figure 1.
ATTACK TWO
Cracking Passwords Based on Kerberos Preauthentication Data
For a long time, we assumed that when we used the default Kerberos authentication provider on Windows 2003, XP, or Win2K machines to protect our passwords, brute-force password cracking attacks such as the ones outlined in the previous section couldn't be successful. But in late 2002—2 years after the release of Win2K—a tool named KerbCrack appeared on the Internet. KerbCrack—which is made up of two tools, kerbsniff and kerbcrack—can perform brute-force cracking attacks on Kerberos packets. Kerbsniff captures Kerberos packets from the network, and kerbcrack performs the actual brute-force cracking on the output of the first tool. Both tools can be downloaded from http://www.ntsecurity.nu/ toolbox/kerbcrack. A paper outlining a similar attack but using different tools is available from http://www.hut.fi/~autikkan/kerberos/docs/phase1/pdf/LATEST_password_attack.pdf.
Kerberos preauthentication is a feature that was introduced in Kerberos 5.0. A client uses preauthentication data to prove the knowledge of its password to the Kerberos Key Distribution Center (KDC—the Kerberos service running on every Windows 2003 and Win2K DC) so that the client can be issued a Ticket Granting Ticket (TGT). Kerberos cracking attacks target the encrypted timestamp that's embedded in the Kerberos preauthentication data. The timestamp is encrypted by using the user's master key (i.e., a key that's based on the user's password).
ATTACK TWO
Prevention
There are two ways to protect against Kerberos preauthentication attacks: Use Windows smart card logon, or encrypt the network traffic between the Kerberos client and the DC by using IPsec. Windows smart card logon uses a Kerberos extension called PKINIT, which doesn't encrypt the packet by using the user's master key but rather uses the user's private key. For more information about PKINIT, see "Public Key Cryptography for Initial Authentication in Kerberos" at http://www.ietf.org/proceedings/03mar/ I-D/draft-ietf-cat-kerberos-pk-init-16.txt. At this point in time, it's impossible to perform a brute-force attack on packets that are secured by using public-private key cryptography. For more information about configuring IPsec, have a look at the Windows IT Security article "Using IP Security Policies to Restrict Access to a Server," March 2005, InstantDoc ID 45217, and "Assigning IPsec Policies to Servers and Workstations on Your Network," March 2003, InstantDoc ID 37946.
ATTACK
THREE
Privilege Elevation by Using SIDHistory
Microsoft added the SIDHistory attribute to AD user account objects in Win2K. SIDHistory facilitates resource access in interdomain account migration scenarios and intraforest account move scenarios. For example, when a user account is migrated from an NT 4.0 domain to a Win2K domain, Windows automatically populates the SIDHistory attribute of the newly created user account in the Win2K domain with the SID of the corresponding user account in the NT 4.0 domain. When at logon, the user's authorization data (group memberships and so on) is gathered in the Win2K domain, the DC adds the user's old SID from the SIDHistory attribute to the authorization data. The resources located in the old domain don't have to be re-permissioned (i.e., their ACLs don't need to be updated); users can continue to access them, even with a new account.
A malicious AD administrator could try to modify the SIDHistory attribute of a user account object to elevate its privileges. For example, in a domain trust relationship, the administrator of the trusted domain could try to add the SID of an administrator account in the trusting domain to the SIDHistory attribute of a user account in the trusted domain. If the administrator were successful, the user account of the trusted domain would get administrator access to the trusting domain.
In the first releases of Win2K, the DCs of the trusting domain don't check the authorization data included with resource access requests from the trusted domain. The trusting domain DCs automatically assume that the requests contain only SIDs for which the DCs of the trusted domain are an authoritative source.
Prev. page
1
[2]
3
4
next page 
