| 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
...
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.
For a discussion of password length, complexity and "entropy" calculations, see Appendix E
Other Compensating Controls
Network Intrusion Systems (NIS), client and hardware firewalls protecting Domain Controllers, e.g. Forefront Endpoint Protection, MS Security Essentials, or your institutional NIS.
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, complexity and "entropy" calculations, see Appendix F
Other Compensating Controls
Network Intrusion Systems (NIS), client and hardware firewalls protecting Domain Controllers, e.g. Forefront Endpoint Protection, MS Security Essentials, or your institutional NIS.
Sample Management Assertion(s)Sample Management Assertion(s)
(Fill in the blanks with your campus' parameters for use with your audit staff.)
Wiki Markup
4.2.3.5 Protected Authentication Secrets
...
AD DS Policies or Practices to Mitigate Risk
AD DS storage mitigation:
Wiki Markup
AD DS transmission mitigation:
...
Sample Management Assertion(s)unmigrated-wiki-markup
The institution's AD DS domain controllers are operated within the constraints placed on them by sections 4.2.5.1, 4.2.5.2., 4.2.5.3 and 4.2.8 (see assertions for the respective sections.) We have set forest-wide group policies *\[ place list of GPOs here \ ]* that prevent unsecured binds and authentication via NTLMv1.unmigrated-wiki-markup
_And/Or:_
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
...
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.
unmigrated-wiki-markup
We disable NTLMv1 and basic unsecured LDAP binds by setting Group Policy Object settings *\[ x, y \ ]*
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:
...
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.
...
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?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