| 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.
...
(Fill in the blanks with your campus' parameters for use with your audit staff.)unmigrated-wiki-markup
Campus 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 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.
Wiki Markup
4.2.5.2 Resist Eavesdropper Attack
...
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.
Wiki Markup
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.
...