Page History

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

...

(Fill in the blanks with your campus' parameters for use with your audit staff.)

Wiki MarkupCampus AD DS stores passwords encrypted with an industry-standard encryption method at rest (NTHASH - MD4) (in the form of syskey encryption) and the passwords are hashed using an industry standard hashing algorithm. Passwords for Silver subjects must be *\must be [x\]* length with *\] length with [y\]* special characters and ] special characters and numbers, must be changed every *\changed every [z\]* days and cannot be the same as the last *\[n\]* passwords, or contain any subset of the user's name or login name. We believe that this provides *\[b\]* bits of min entropy, which is more than the 10\+*\[e\]* bits of min entropy required by the IAPs in the form of a sufficiently entropic password plus a well-known salt value (the username, for example) which provides only *\[e\]* bits of extra entropy.  This provides more than the minimum entropy required by the IAPs, and is better than using the minimum entropy required plus a well-known salt value. We operate Syskey in mode *\[ 2, 3 \]* to further protect the stored password secrets by requiring a secret to be *\[ typed, supplied on a floppy disk \]* during Domain Controller ] days and cannot be the same as the last [n] passwords, or contain any subset of the user's name or login name. We believe that this provides [b] bits of min entropy, which is more than the 10+[e] bits of min entropy required by the IAPs in the form of a sufficiently entropic password plus a well-known salt value (the username, for example) which provides only [e] bits of extra entropy.  This provides more than the minimum entropy required by the IAPs, and is better than using the minimum entropy required plus a well-known salt value. We operate Syskey in mode [ 2, 3 ] to further protect the stored password secrets by requiring a secret to be [ typed, supplied on a floppy disk ] during Domain Controller bootstrapping.

4.2.3.5 Protected Authentication Secrets

...

AD DS Policies or Practices to Mitigate Risk
AD DS storage mitigation:unmigrated-wiki-markup:

Ensure that any AD DS forest(s) and domain(s) that contain "silver" usernames and passwords meet the operational requirements of section 4.2.8, protect their secrets appropriately via complex hashed passwords and appropriate use of syskey, and specifically only allow connections via SSL/TLS, Kerberos, and possibly NTLMv2. Use the following GPO and/or firewall settings and syskey mode(s) *\[ 2, 3 \ ]* to ensure this behavior.

AD DS transmission mitigation:

...

Sample Management Assertion(s)

Wiki MarkupThe 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.

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_And:_
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-markupattack.

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.

...

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 *1 Basics of AD DS trust trusts (diagram by Brian Desmond)

  Image Modified

*2 *2 Decision Flowchart for AD DS Domain/Forest Trust and Silver Compliance (diagram by Brian Desmond)

Image Modified

Version History

...

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