IAP v1.2 Section |
Requirements (paraphrased) |
AD-DS Baseline Controls |
Baseline Gaps |
AM Proposal |
Remaining Gaps |
||
4.2.3.4 - Stored Authentication Secrets (S) |
Do not store passwords as plaintext. Limit access to admins and apps that require access. |
Passwords are stored in the ntds.dit file. They are not stored as plaintext. The operating system normally prevents access to the file. |
No gaps. |
|
|
||
|
Protect stored passwords with one of the following alternatives: |
1. The "NT hash" is an unsalted MD4 hash. The "LM hash" isn't a cryptographic hash. |
1. MD4 is not an Approved Algorithm and a variable salt is not employed. |
|
|
||
|
2. Encrypt the password with an Approved Algorithm and decrypt only when immediately needed for authentication. |
2. Encrypts the "NT hash" with DES and the users RID, then encrypts again with RC4 and the PEK. The "LM hash" is the output from encrypting a constant with the password and DES. |
2. DES and RC4 are not Approved Algorithms. |
|
|
||
|
3. Any method allowed for NIST 800-63 Level 3 or 4. |
|
|
|
|
||
4.2.3.5 - Basic Protection of Authentication Secrets (B) |
1. Do not store passwords as plaintext. Limit access to admins and apps that require access. |
1. Passwords are stored in the ntds.dit file. They are not stored as plaintext. The operating system normally prevents access to the file. |
1. No gaps |
|
|
||
|
2. Do not transmit plaintext passwords over the network |
2. Authentication using LM, NTLMv1, NTLMv2, LDAP over SSL, or Kerberos does not transmit cleartext passwords. |
2. LDAP without SSL transmits plaintext passwords. |
|
|
||
4.2.3.6 - Strong Protection of Authentication Secrets (S) |
1a. Any credential store with passwords used by the IdP or verifier is subject to 4.2.3.4 and 4.2.8. |
1a. See the relevant sections in this table. |
1a. See the relevant sections in this table. |
|
|
||
|
1b. Use Protected Channels when passwords are sent from one credential store to another. |
1b. AD-DS uses RPC and Kerberos when synchronizing between domain controllers. For Windows Server 2008 and later, AES is used for Kerberos encryption if properly configured.1 Alternatively, an appropriately configured mechanism such as IKE/IPSEC may be used to create the Protected Channel. |
1b. Gaps? |
|
|
||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e45af96a-241b-46f8-85e4-2f2bf415d331"><ac:plain-text-body><![CDATA[ |
|
2. Use Protected Channels when passwords are sent between services for verification purposes. |
2. Verification using NTLMv2, Kerberos, or LDAP with SSL uses a protected channel between services. Use of LM and NTLMv1 protocols for verification is precluded by subjects holding a Silver IAQ due to the definition of a protected channel. Use of LDAP without SSL is also precluded for the same reason. |
2. Use of LM and NTLMv1 protocols may be prevented by disabling the protocols centrally at the AD-DS. Disabling this protocols may cause compatibility issues with older applications. [3] Enforcing LDAP signing prevents LDAP connections with SSL. As mentioned above, this may cause compatibility issues depending on the environment. |
|
|
]]></ac:plain-text-body></ac:structured-macro> |
|
3. Have policies and procedures to minimize the risk of transient password exposure to non-IdP apps. |
|
|
|
|
||
4.2.5.1 - Resist Replay Attack (B, S) |
Ensure it's impractical to achieve authentication by recording and replaying a previous authentication message. |
Windows maintains a cache of used authenticators to allow it to recognize a replay of a specific authentication event. |
LM - Does not resist replay attacks* |
|
|
||
4.2.5.2 - Resist Eavesdropper Attack (B, S) |
Ensure it's impractical to learn the password or otherwise obtain information that would allow impersonation of a subject by network eavesdropping. |
LM, NTLMv1, NTLMv2 and Kerberos all provide some level of security based on their native encryption. Strength of encryption determines how well the protocol resists eavesdropping. |
LM - Vulnerable to eavesdropping* |
1. Use protected channel (e.g., VPN) |
|
||
4.2.8.2.1 - Network Security (S) |
Protected Channels should be used for communication between IdMS systems. |
For native IdMS components (AD Domain Controllers), replication is described above in 4.2.6.3, 1b. |
As 4.2.6.3, 1b. |
|
|
Definitions from the Identity Assurance Assessment Framework:
- Approved Algorithm - Any implementation of an algorithm or technique specified in a FIPS standard or NIST recommendation, or any algorithm or technique that conforms to an alternative means identitified by InCommon as approved for specified IAPs.
- Protected Channel - A Protected Channel uses cryptographic methods that implement an Approved Algorithm to provide integrity and confidentiality protection, resistance to replay and man-in-the-middle attacks, and mtual authentication.
- IdP Operator (IdPO) - The legal entity that signs contracts, is a registered participant in InCommon, and is responsible for the overall processes supporting the IdP.
Footnotes:
1Kerberos Enhancements and Understanding Active Directory Domain Services (AD DS) Functional Levels explain that in Windows Server 2008 and later, Kerberos uses AES (an Approved Algorithm) for encryption. How Replication Works explains that RPC is used for replication over IP and that Kerberos is used for encryption.
2BitLocker Drive Encryption Overview and BitLocker Drive Encryption Technical Overview explain that AES (an Approved Algorithm) is used for encryption of the drive and that sectors are only decrypted as they are read.
[3] Detailed discussions of the issues and mitigations of LM and NTLMv1 technologies/protocols can be found in the AD Silver Cookbook. Please refer to the AD Silver Cookbook for further explanation.