| Note |
|---|
This Cookbook version was written to address the InCommon Identity Assurance Profile version 1.1 that has been deprecated. The Cookbook is being updated to reflect the changes in version 1.2. |
Introduction
This document is intended to aid in configuring Active Directory Domain Services (AD DS, commonly referred to as "Active Directory") to meet the requirements of the InCommon Federation's Identity Assurance Profile (IAP) for Silver level of assurance. Only sections of the IAP where there is a challenge unique to AD DS are specifically addressed. For example, sections 4.2.3.2 and 4.2.3.3 of the IAP are not covered in this document because issues of brute-force guessing and password entropy pose no unique challenge to AD DS; like most authentication services AD DS has controls to enable password rotation, and mitigating features like account lockout, and configuring these controls to meet those IAP sections is an exercise that requires no knowledge unique to AD DS.
...
- 4.2.3.4 Stored Authentication Secrets
- 4.2.3.5 Protected Authentication Secrets
- 4.2.5.1 Resist Replay Attack
- 4.2.5.2 Resist Eavesdropper Attack
- 4.2.5.3 Secure communication
Software changes can impact the necessary configurations, so for brevity we have limited the scope of recommendations to AD DS on Windows Server 2008 R2 running in Windows Server 2008 Forest Functional mode. It is likely that similar protections and controls can be used with other versions of the software. This cookbook only addresses the most recent versions of the Windows Server operating system and its AD DS componentWe believe that many of the approaches documented in this cookbook are applicable to all versions of AD DS from Windows Server 2003 forward (with possible exception of the IPSec approach), although the exact steps to implement them may vary. The documentation below references Windows Server 2008 R2 settings.
For more information about the InCommon Assurance program, terms and definitions, and links to the IAP and IAAF documents and the FAQ, see the Assurance Resources section
...
- 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:
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.
Preventing the storage of longterm shared secrets in LMHASH format in conjunction with a strict password policy will mitigate risk.
To disable the storage of LM hashes of a user's passwords in the local computer's SAM database by using Local Group Policy (Windows XP or Windows Server 2003) or in a Windows Server 2003 AD DS environment by using Group Policy in AD DS, follow these steps:
1. In Group Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
2. In the list of available policies, double-click Network security: Do not store LAN Manager hash value on next password change.
3. Click Enabled, and then click OK.
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:
NOTE: This section of the IAPs requires a salt value to be combined with a password and then hashed, with the intent of increasing the entropy of the hashed password for the purposes of preventing an offline (dictionary or “rainbow table”-based) attack on a stolen copy of the password file. We believe that the IAPs are over-prescriptive in this area, and that other strategies for increasing the entropy of stored passwords should be acceptable. The ultimate determination for this acceptability lies with each institution, their auditors, the InCommon assurance review panel, the InCommon technical advisory committee and the InCommon steering committee. Because no institution has received approval to assert the Silver Identity Assurance Qualifier (IAQ) at the time of writing, and further no institution has achieved this with AD DS in the mix, there is no way of saying whether this approach will be sufficient. Any feedback or clarification that can be added to this section over time will help more institutions achieve Silver. Please send any feedback you have on this, including and especially success stories, to assurance-adsilver at incommon dot org.
Since any salt value must be well-known to some extent in order for passwords to be successfully verified across heterogeneous systems, a well-known salt value in the form of a username, a transformed username, a time value, constant, cyclical value or any other predictable permutation, does not provide much extra entropy to the hashes in a password file. We believe that requiring passwords with a level of entropy above that required at a minimum by the IAPs (14 bits of guessing entropy, 10 bits of “min” entropy across the password store) is achievable in a practical way, and should provide total entropy (entropy of the final hash to protect against a dictionary attack) at or above the level of the IAP entropy requirements plus a well-known salt value. Exactly how much extra entropy a well-known hash value adds (for example, the username- very well-known since it’s necessarily associated at some level with the password) and therefore how much extra entropy should be required above the minimum IAP requirements to achieve the spirit, if not the letter, of the requirements, is up to each institution.
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. 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.
Preventing the storage of longterm shared secrets in LMHASH format in conjunction with a strict password policy will mitigate risk.
To disable the storage of LM hashes of a user's passwords in the local computer's SAM database by using Local Group Policy (Windows XP or Windows Server 2003) or in a Windows Server 2003 AD DS environment by using Group Policy in AD DS, follow these steps:
1. In Group Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
2. In the list of available policies, double-click Network security: Do not store LAN Manager hash value on next password change.
3. Click Enabled, and then click OK.
For a discussion of password length, For a discussion of password length, complexity and "entropy" calculations, see Appendix EF
Other Compensating Controls
...
(Fill in the blanks with your campus' parameters for use with your audit staff.)
Wiki Markup
4.2.3.5 Protected Authentication Secrets
...
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).
...
AD DS Policies or Practices to Mitigate Risk
AD DS storage mitigation:
Wiki Markup
AD DS transmission mitigation:
There are several possible alternate solutions:
...
alternate solutions:
- 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 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
...
Sample Management Assertion(s)
Wiki Markup
Wiki Markup
We actively monitor for unsecured authentication events on our network using the following intrusion detection system monitoring profiles *\[ place list of profiles here \ ]* and follow up with any sources of unsecured authentication activity. We further monitor for usernames and passwords traversing the network in the clear from sources such as forms-based web page logins, and follow up with the sources of these events.
Wiki Markup
We have an institutional policy requiring secure communication of authentication events for institutional network IDs: *\[ put link to institutional policy here \ ]*. This policy is enforced by *\[responsible party \ ]* using *\[ audits, education, IDS rules, etc. \ ]*
4.2.5.1 Resist Replay Attack
...
- 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 connectionsrequire 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 so are protected and acceptable. Likewise, requiring LDAP data signing encrypts the password data so are protected and acceptable.
Basic LDAP binds using SSPI for security that require Kerberos are acceptable because they use Kerberos for authentication, covered under the first paragraph of this assertion.
NTLMv2 is acceptable because it uses a fine-grained time value in the hashing process that the client must use to respond to the server challenge, to mitigate risk of a replay attack.
Wiki Markup
4.2.5.2 Resist Eavesdropper Attack
...
Additionally or alternatively, require Silver subject passwords/phrases to be >= 15 characters to prevent storage of weak LMHASH. As of Server 2008R22008 R2, require signed LDAP binds, which will cause AD DS domain controllers to drop non-tunneled connections.
...
There are two strategies that can be employed to preventing prevent eavesdropper attacks with AD DS:
- 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 so are protected and acceptable.Likewise, requiring LDAP data signing encrypts the password data so are protected and acceptable.
...
NTLMv2 is acceptable because it uses a challenge-handshake authentication protocol that hashes the username and password together with a random salt in the response to the server challenge using MD5 to prevent a successful dictionary attack against the password in transit.
unmigrated-wiki-markup
We disable NTLMv1 and basic unsecured LDAP binds by setting Group Policy Object settings *\[ x, y \ ]*
The use of RADIUS with PEAP-MS-CHAPv2 is acceptable because PEAP establishes a TLS tunnel to protect the MS-CHAPv2 messages communicated between the RADIUS client and server.The use of MS-CHAPv2 alone is not acceptable as is it known to be cryptographically weak.
...
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 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. 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 issue.
Appendix C - Operational Considerations, Practices, Processes For Syskey Mode 2/3 Management
...
Q: What is within scope for services based on AD DS? In other words, if I have AD DS on my campus, and the passwords are the same as passwords used by my IdP (even if the IdP doesn't directly authenticate against AD DS,) do I have to be concerned with the security of authentication events for every dependent service?are the same as passwords used by my IdP (even if the IdP doesn't directly authenticate against AD DS,) do I have to be concerned with the security of authentication events for every dependent service?
A: You should use common sense and best security practices in your assessment of the situation at your institution. Silver is Silver, it's not Gold or Platinum. If there are strategies you can use to detect direct simple binds to AD DS and prevent NTLMv1 connections, those are good things to do. You should probably have a strategy for following up with people doing simple binds and asking them not to do that. You may want to consider spot auditing owners of any kind of service ID that does any kind of authentication with your AD DS implementation, to make sure they aren't doing things like exposing passwords via unprotected forms authentication on web sites, etc. You can probably use a combination of institutional authentication policy, monitoring processes (such as intrusion detection system rules that look for simple LDAP binds) and spot checks to mitigate this risk adequately.
Q: What is the security boundary for an AD DS deployment?
A: The security boundary is the forest, unless you have a domain or forest trust and you are the trusting domain/forest. If you have a trust, and your IdP asserts identity for principals in the trusted domain or forest, then both forests are in-scope. For more information, see figures 1 and 2, below.
Figures
1 Basics of AD DS trusts (diagram by Brian Desmond)
2 Decision Flowchart for AD DS Domain/Forest Trust and Silver Compliance (diagram by Brian Desmond)
A: You should use common sense and best security practices in your assessment of the situation at your institution. Silver is Silver, it's not Gold or Platinum. If there are strategies you can use to detect direct simple binds to AD DS and prevent NTLMv1 connections, those are good things to do. You should probably have a strategy for following up with people doing simple binds and asking them not to do that. You may want to consider spot auditing owners of any kind of service ID that does any kind of authentication with your AD DS implementation, to make sure they aren't doing things like exposing passwords via unprotected forms authentication on web sites, etc. You can probably use a combination of institutional authentication policy, monitoring processes (such as intrusion detection system rules that look for simple LDAP binds) and spot checks to mitigate this risk adequately.
Version History
2011 May 5 - Initial work within the CIC CIOs Identity Management working group
...
2012 February 13 - Version 1.0
2012 March 26 - Version 1.1 (Post-IAM Online Feedback)
2012 August 9 - Minor changes to note that many of the approaches in the cookbook work from Windows Server 2003 forward