Versions Compared

Old Version 51

changes.mady.by.user barkills@washington.edu

Saved on

compared with

New Version 58

changes.mady.by.user David Walker

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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. Concatenate a variable salt to the password and hash with an Approved Algorithm.

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.

Full-disk encryption (FDE) solutions (hardware or software) that utilize Approved Algorithms and only decrypt passwords when immediately needed (i.e. decrypt disk sectors as needed to support read operations while keeping the data on disk encrypted) provide a compensating control. Bitlocker2 is an example FDE solution that ships with Windows 2008 and newer.

 

 

 

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 IdP 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.

This requirement also applies to provisioning of passwords into or out of AD-DS.

1b. Gaps?



There may be implementation specific issues based on local technology choices for password provisioning. These issues are not specific to AD-DS.

 

 

 

2. Use Protected Channels when IdP 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.

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. 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 preserving 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 IdP authentication by recording and replaying a previous IdP 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*
NTLMv1 - Does not resist replay attacks*
NTLMv2 - Resists replay attacks7  
LDAP - Does not resist replay attacks if LDAP signing4 is not enforced
Kerberos - Resists replay attacks7 
* Not allowed per AD Silver Cookbook

Require LDAP signing

OR

Enable LDAP signing and monitor & mitigate non-LDAP signed use by those with an assurance level.

 

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 during an IdP authentication event.

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.


LDAP
Fails to resist eavesdropping if using Simple Binds without TLS/SSL.

Simple Binds with TLS/SSL5 or signing should resist eavesdropping.

Binds using SASL (and not TLS/SSL) will use the native encryption of the underlying SASL mechanism (LM, NTLM, etc), so may or may not effectively resist eavesdropping.

LM - Vulnerable to eavesdropping*
NTLMv1 - Vulnerable to eavesdropping*
NTLMv2 - Resists eavesdropping (strength of encryption)7
LDAP - Vulnerable to eavesdropping if LDAP signing4 is not enforced 
Kerberos - Resists eavesdropping7
* Not allowed per AD Silver Cookbook

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.

Not clear that other IdMS are relevant, in that they will not be native AD components. *

* Assumes that AD-LDS replication is the same as AD-DS replication.

As 4.2.3.6., 1b.

 

 

...