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 SSL5, or Kerberos6 does not transmit cleartext passwords. | 2. LDAP without SSL5 transmits plaintext passwords. Enforcing LDAP signing4 prevents LDAP connections without SSL, but this may cause compatibility issues with some clients (e.g. Mac and Linux clients using Samba). |
|
|
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? |
|
|
| 2. Use Protected Channels when passwords are sent between services for verification purposes. | 2. Verification using NTLMv2, Kerberos6, or LDAP with SSL5 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 these protocols may cause compatibility issues with older applications3. Enforcing LDAP signing4 prevents unsigned LDAP connections by using SSL. As mentioned above, this may cause compatibility issues depending on the environment. |
|
|
| 3. Have policies and procedures to minimize the risk of transient password exposure to non-IdP apps. | 3. AD-DS is considered part of the IdMS when included in an assurance assessment, Since AD-DS can act as a verifier for non-IdP applications that exist outside of IdMS, the organization as IdPO must have policy in place to enforce the IAP requirements for any application that password transits through between subject and AD-DS. | 3. A general principle of following the password and applying risk management at any point where the protected channel between the subject and the verifier is compromised should be applied. Common examples that require additional attention are non-privacy perserving authentication interfaces, externally hosted applications and applications that require proprietary authentication API's. Involving Information Security, Audit and Procurement staff would be recommended. |
|
|
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* | Require LDAP signing |
|
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.3.6, 1b. | As 4.2.3.6., 1b. |
|
|
...
For the purposes of analyzing replay and eavesdropper attacks, we decided that a vulnerability to a combination of multiple attack styles {eavesdropper(passive), replay, man-in-the-middle} did not constitute an IAP gap of this the individual section. However, for both Kerberos and NTLMv2 there are known vulnerabilities that include replay which can be leveraged to establish a session to a network resource. There are mitigations involving good security practice for these combination attacks, with the most relevant to the IAP revolving around security practices involving the domain controllers and domain admins. Practitioners should review the following material to make sure they are familiar with these combination attacks and have taken reasonable steps to mitigate:
...