...
- Encryption on the wire via IPSecEncryption on the wire via LDAPS
- Require LDAP data signing
The reader can use either of these strategies to secure authentication traffic and which is chosen is up to the reader. More about these technologies is included in the appendices.
4.2.3.4 Stored Authentication Secrets
AD DS Problem Statement
The language in this section requires either a salted password to be hashed, or a non-salted password to be encrypted and only un-encrypted when immediately used for authentication, or a NIST Level 3 or 4 method.
On disk, AD DS stores all passwords in a hashed form, encrypted by the Password Encryption Key (PEK). The PEK is unique on each domain controller, and the PEK itself is encrypted by the syskey. It does not concatenate passwords with a salt to increase the entropy of the hash for the purposes of mitigating the risk of a dictionary attack on a stolen copy of the password file.
In memory, AD DS stores hashes of passwords. The encryption used with these hashes varies based on the type of password. NTLMv2 passwords use HMAC-MD5, NTLM passwords use RC4, and LM passwords (if enabled) use DES.
If enabled, the algorithm AD DS uses to store LM passwords is not a true one-way function as the password can be determined from the hash because of several weaknesses in its implementation. As such, if LM password hashes are enabled (they are disabled by default after WS2008), the AD DS will not meet this part of the IAP.
Even with LM password hashes turned off, AD DS doesn't meet any of the 3 alternative methods specified in the IAP, however, there are extenuating circumstances which greatly limit the risk. In specific, because a per-domain controller PEK encrypted by a syskey is used to encrypt the hashes at rest, a stolen copy of the password file would be difficult to use, unless operated on in its in-memory form. Getting the in-memory form of the hashes would be challenging provided adequate physical, network security, and where applicable, virtual machine security is in place.
AD DS Policies or Practices to Mitigate Risk
At rest protected stored secret risk mitigation:
Additionally employing BitLocker to encrypt the volumes on the DC which store secrets would provide even greater protections against unauthorized access at rest, but is likely unnecessary to meet Silver.
Entropy risk mitigation:
Requiring complex passwords per the entropy requirements elsewhere in the IAPs adds significant entropy beyond that achievable via use of a well-known (and thus low-entropy) salt value, therefore complex/long passwords, stored as an NTLM hash (NOT an LMHASH, which is very susceptible to dictionary attack) should be fine for the purposes of this section.
Removal of insecure stored secrets:
Alternatively, you can also achieve secure authentication traffic with AD DS by using encryption on the wire via LDAPS (TLS/SSL) but that approach only works for non-Windows clients, because Windows clients require LDAP traffic for some key functionalities. You can't require LDAPS (and turn off or block LDAP) if you have any Windows clients, so we haven't included this strategy as one of the primary options. See http://support.microsoft.com/kb/832017 for details on functionalities that Windows clients have which require LDAP (which LDAPS doesn't fulfill).
4.2.3.4 Stored Authentication Secrets
AD DS Problem Statement
The language in this section requires either a salted password to be hashed, or a non-salted password to be encrypted and only un-encrypted when immediately used for authentication, or a NIST Level 3 or 4 method.
On disk, AD DS stores all passwords in a hashed form, encrypted by the Password Encryption Key (PEK). The PEK is unique on each domain controller, and the PEK itself is encrypted by the syskey. It does not concatenate passwords with a salt to increase the entropy of the hash for the purposes of mitigating the risk of a dictionary attack on a stolen copy of the password file.
In memory, AD DS stores hashes of passwords. The encryption used with these hashes varies based on the type of password. NTLMv2 passwords use HMAC-MD5, NTLM passwords use RC4, and LM passwords (if enabled) use DES.
If enabled, the algorithm AD DS uses to store LM passwords is not a true one-way function as the password can be determined from the hash because of several weaknesses in its implementation. As such, if LM password hashes are enabled (they are disabled by default after WS2008), the AD DS will not meet this part of the IAP.
Even with LM password hashes turned off, AD DS doesn't meet any of the 3 alternative methods specified in the IAP, however, there are extenuating circumstances which greatly limit the risk. In specific, because a per-domain controller PEK encrypted by a syskey is used to encrypt the hashes at rest, a stolen copy of the password file would be difficult to use, unless operated on in its in-memory form. Getting the in-memory form of the hashes would be challenging provided adequate physical, network security, and where applicable, virtual machine security is in place.
AD DS Policies or Practices to Mitigate Risk
At rest protected stored secret risk mitigation:
Additionally employing BitLocker to encrypt the volumes on the DC which store secrets would provide even greater protections against unauthorized access at rest, but is likely unnecessary to meet Silver.
Entropy risk mitigation:
Requiring complex passwords per the entropy requirements elsewhere in the IAPs adds significant entropy beyond that achievable via use of a well-known (and thus low-entropy) salt value, therefore complex/long passwords, stored as an NTLM hash (NOT an LMHASH, which is very susceptible to dictionary attack) should be fine for the purposes of this section.
Removal of insecure stored secrets:
Steps should be taken to disable storage of the LMHASH (by running Windows 7, Server 2008, and/or setting a GPO setting "Network security: Do not store LAN Manager hash value on next password change" to disable storage of the LMHASH, or requiring 15 character or greater passwords, since LMHASHes cannot be applied to passwords greater than 14 characters. Steps should be taken to disable storage of the LMHASH (by running Windows 7, Server 2008, and/or setting a GPO setting "Network security: Do not store LAN Manager hash value on next password change" to disable storage of the LMHASH, or requiring 15 character or greater passwords, since LMHASHes cannot be applied to passwords greater than 14 characters. Note that invalidating any stored LMHASH values after making these changes will require password changes for any subject for whom Silver is to be asserted. Further protection under this section is achieved by operating Syskey management in mode 2 or 3.
...
So in the context of AD DS, the transmission requirements mean that the domain to which Silver subject passwords are provisioned must comply with the requirements of these sections, and password traffic must take place via via protected channels. Protected channels are are defined in the IAAF as: "industry-standard cryptographic methods to provide integrity and confidentiality protection, resistance to replay and man-in-the-middle attacks, and mutual authentication." SSL/TLS is an example LDAP data signing or IPSec are examples of a protected channel, and is an acceptable method of password transmission for AD DS. According to our interpretation of this passage, Kerberos and NTLMv2 are also acceptable (see 4.2.5.1, 4.2.5.2 and 4.2.5.3, below).
...
There are several possible alternate solutions:
- Use Windows Firewall to block access to unsecured LDAP port 389.
- Require signed LDAP traffic by setting the following GPO setting: Domain Controller: LDAP Server signing requirements=Enabled
Note: This may require deploying an additional GPO setting to clients, "Network security: LDAP client signing requirements", and require third party applications to be reconfigured to use SSL/TLS or signed SASL binds. This may have an adverse effect on the ability of Mac OS X and other clients to authenticate using the AD DS, so care must be taken in an enterprise setting when testing and communicating this changecommunicating this change. http://support.microsoft.com/kb/823659 discusses some possible incompatibilities with doing this and Appendix B discusses one solution for Mac OS X clients. - Use IPSec policies to force LDAP (port 389) traffic to be encrypted. Steps for creating an IPSec policy are documented on Microsoft TechNet: http://technet.microsoft.com/en-us/library/cc730656.aspx
...
- Encryption on the wire via IPSecEncryption on the wire via LDAPS
- Require LDAP data signing
If you choose LDAPSLDAP data signing, you must require signed LDAP bindsconfigure "Domain controller: LDAP server signing requirements: Enabled", which will cause AD DS domain controllers to drop non-tunneled connectionsto require all clients to negotiate signed LDAP traffic. http://support.microsoft.com/kb/823659 discusses some possible incompatibilities with doing this--also see Appendix B.
If you choose IPSec, you must require that all authentication traffic be encrypted using IPSec. This depends on forest functional level (must be Windows Server 2008 forest functional level); if lower OS DCs exist in a domain, then the least common denominator is used.
...
Secure LDAP binds using TLS are encrypted are encrypted so are protected and acceptable. Likewise, requiring LDAP data signing encrypts the password data so are protected and acceptable.
...
- Encryption on the wire via IPSecEncryption on the wire via LDAPS
- Require LDAP data signing
If you choose LDAPSLDAP data signing, you must require signed LDAP bindsconfigure "Domain controller: LDAP server signing requirements: Enabled", which will cause AD DS domain controllers to drop non-encrypted connectionsto require all clients to negotiate signed LDAP traffic. http://support.microsoft.com/kb/823659 discusses some possible incompatibilities with doing this--also see Appendix B.
If you choose IPSec, you must require that all authentication traffic be encrypted using IPSec (with Authentication Header (AH) and Layer 2 Tunneling Protocol (L2TP)). This depends on forest functional level (must be Windows Server 2008 forest functional level); if previous versions of Windows Server OS domain controllers exist in a domain, then the least common denominator is used for forest functional level.
...
Secure LDAP binds using TLS are encrypted encrypted so are protected and acceptable.Likewise, requiring LDAP data signing encrypts the password data so are protected and acceptable.
...
AD DS Problem Statement
While this section is focused at communication between the Subject and IdP, not the IdP and Verifier, it naturally extends to AD DS if AD DS is your source of credential verification, or (peripherally, via section 4.2.3.5) to AD DS if your Silver subject credentials are provisioned in AD DS or transit it in any way. As such, the requirements for in AD DS or transit it in any way. As such, the requirements for section 4.2.3.5 cover this section of the IAP with regard to AD DS.
AD DS Policies or Practices to Mitigate Risk
See other sections of this document for acceptable strategies to mitigate risk in this context.
Other Compensating Controls
See other sections of this document for acceptable compensating controls.
Sample Management Assertion(s)
AD DS is not explicitly within the scope of this section of the IAP, but it follows that communication between AD DS and other systems should be appropriately protected. Management assertions in section 4.2.3.5 cover this section of the IAP with regard to AD DS.
AD DS Policies or Practices to Mitigate Risk
See other sections of this document for acceptable strategies to mitigate risk in this context.
Other Compensating Controls
See other sections of this document for acceptable compensating controls.
Sample Management Assertion(s)
AD DS is not explicitly within the scope of this section of the IAP, but it follows that communication between AD DS and other systems should be appropriately protected. Management assertions in section 4.2.3.5 provide documentation of these protections.
provide documentation of these protections.
Appendix A - Known Issues With NTLMv1 Disabled/LMHASH Storage Turned Off
Put any known issues/affected systems here, along with how you solved the problem, if possible.
See http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx for an exhaustive discussion of the LanManCompatibilityLevel setting.
By default, Windows XP and earlier clients aren't compatible with DCs that have LanManCompabilityLevel=5. This means you must get all older Windows clients reconfigured. Domain joined computers can be easily addressed with group policy. Non-domain joined computers will require manual configuration or a script you provide.
Appendix B - Known Issues With Requiring Signed LDAP BindsAppendix A - Known Issues With NTLMv1 Disabled/LMHASH Storage Turned Off
Put any known issues/affected systems here, along with how you solved the problem, if possible.
See http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx for an exhaustive discussion of the LanManCompatibilityLevel setting.
By default, Windows XP and earlier clients aren't compatible with DCs that have LanManCompabilityLevel=5. This means you must get all older Windows clients reconfigured. Domain joined computers can be easily addressed with group policy. Non-domain joined computers will require manual configuration or a script you provide.
Appendix B - Known Issues With Requiring Signed LDAP Binds
Put any known issues/affected systems here, along with how you solved the problem, if possible.
Cisco TMS doesn't support LDAPS. This is an application that integrates with AD DS to provide identity and access management. No resolution. Maybe newer versions will provide LDAPS support. Unclear if Cisco TMS supports LDAP signing.
While the Mac OS GUI claims it will enable LDAP signing by default, in practice, it doesn't. However, if you use Apple's dsconfigad command line tool with the switch "-packetencrypt ssl", you can tell the Mac OS to use LDAPS (i.e. employ LDAP over TLS/SSL). This protects Mac OS clients authentication traffic. This dsconfigad option can be used at the time of Mac computer domain join or it can be used after domain join to mitigate this issueCisco TMS doesn't support LDAPS. This is an application that integrates with AD DS to provide identity and access management. No resolution. Maybe newer versions will provide LDAPS support.
Appendix C - Operational Considerations, Practices, Processes For Syskey Mode 2/3 Management
...