InCommon Silver with Active Directory Domain Services Cookbook - 201404

Appendix A - Known Issues With NTLMv1 Disabled/LMHASH Storage Turned Off

See http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx for an exhaustive discussion of the LanManCompatibilityLevel setting.

By default, Windows XP and earlier clients aren't compatible with DCs that have LanManCompabilityLevel=5. This means you must get all older Windows clients reconfigured. Domain joined computers can be easily addressed with group policy. Non-domain joined computers will require manual configuration or a script you provide.

Radius implementations that leverage Samba and authenticate to a Domain Controller rely on NTLMv1.  Specifically MSCHAPv2 is "cryptographically equivalent" to NTLMv1. There are possible ways to mitigate this, but the right choice is entirely dependent on considerations at each individual institution.

• You could move to a Windows based Radius implementation using Network Policy and Access Services in Windows 2008 Server or later.
• You could leave the LMCompatabilityLevel set to 4 and continue to accept NTLMv1.  You would then have to mitigate the risks using some other means such as the Monitor and Mitigate tactic described previously and establishing a Protected Channel between the Radius server(s) and Domain Controller(s).
• There have been discussions about the feasibility of separating Radius authentication into its own domain.  Whether this is suitable is entirely too dependent on local considerations, but if there are successful implementations using this tactic please share them with the community.

Appendix B - Known Issues With Requiring Signed LDAP Binds

Cisco TMS doesn't support LDAPS. This is an application that integrates with AD DS to provide identity and access management. No resolution. Maybe newer versions will provide LDAPS support. Unclear if Cisco TMS supports LDAP signing.

While the Mac OS GUI claims it will enable LDAP signing by default, in practice, it doesn't. However, if you use Apple's dsconfigad command line tool with the switch "-packetencrypt ssl", you can tell the Mac OS to use LDAPS (i.e. employ LDAP over TLS/SSL). This protects Mac OS clients authentication traffic. This dsconfigad option can be used at the time of Mac computer domain join or it can be used after domain join to mitigate this issue.

Appendix C - Operational Considerations, Practices, Processes For Use of Disk Encryption Software

A potential issue with the use of BitLocker on Domain Controllers arises if you deploy DCs via virtual machines (VMs), as Microsoft does not support BitLocker directly within VMs. However, Microsoft notes that if you BitLocker a HyperV host (i.e. the volumes the guest disks are on), the BitLocker protections are enjoyed by all guest VMs. Microsoft may or may not support other full disk encryption solutions when virtualizing a Domain Controller, so check on support from Microsoft if you run in an alternate configuration.

Appendix D - InCommon Assurance Framework Terminology 

Credential Issuance
Credential Issuance is the process that binds the credential to the subject and enables the credential to be used by the subject. This process may or may not actually add the records associated with the credential to systems. With Windows AD DS, this may be accomplished by creating and enabling the user account, and conveying the password to the subject via a registration process that complies with the subject registration and credential issuance requirements of the IAP

Credential Revocation
Credential Revocation is the process that removes the binding of the credential from the subject and renders the credential non-usable by the subject. This process may or may not actually remove the records associated with the credential from systems. With Windows AD DS, this may be accomplished multiple ways:

• disabling the user account
• giving the user account an account expiration value in the past
• changing the password on the user account to a value unknown to the user (note that this is only acceptable as a temporary method of revocation--one of the other methods must be used before your password entropy/brute force period is exceeded)
• deleting the user account
• moving the user account to a directory which is configured to prevent Silver authentication, such as a correctly configured Active Directory Lightweight Directory Services (AD-LDS).

Appendix E - Password Entropy - Calculating it, what's needed, what's "good enough," etc.

While this topic is not specifically within the scope of this cookbook, it plays a big role in brute force and dictionary attacks against your credential store.  NIST SP 800-63 Appendix A contains a lengthy discussion of Claude Shannon's notion of information entropy and complexity as it applies to passwords.  We'll leave that discussion to that document.  Here, we'll say that there are any number of ways to reach the required 1:16384 chance of guessing a password during its active life, and the 14 bits of entropy, against a targeted guessing attack, that are required by the Silver IAP.  You can have longer, complex passwords that are active for a longer time, shorter, less complex passwords that are active for a shorter time, with more or less aggressive account lockout policies, etc.  SP 800-63, the IAP document and an entropy calculation spreadsheet, such as http://www.infoworld.com/sites/all/themes/ifw/downloads/passwordcalc096.zip are good reference documents.

Appendix F - FAQ

(Please add any FAQ/Q&A type things you can think of with regard to AD DS here- if you have a question, please add it, and if you have an answer, please add it. They don't necessarily have to come in pairs, but we'll try to collaboratively fill in the blanks for each other.)

Caveat: We are not auditors, and we aren't the InCommon arbitration board, the TAC, or the steering committee (and we aren't even close to being FICAM.) So, take these Q&As as they are intended, as a best effort interpretation. These statements largely remain to be vetted by auditing/achievement of Silver.

Q: What is within scope for services based on AD DS? In other words, if I have AD DS on my campus, and the passwords are the same as passwords used by my IdP (even if the IdP doesn't directly authenticate against AD DS,) do I have to be concerned with the security of authentication events for every dependent service?

A: In general, the scope will be defined by the "Identity Management System Operations" in the Identity Management Functional Model described in section 2 of the IAAF. In general, AD DS will function in the role of both a "Verifier" and an "Attribute Service". You should use common sense and best security practices in your assessment of the situation at your institution. If there are strategies you can use to detect direct simple binds to AD DS and prevent NTLMv1 connections, those are good things to do. You should probably have a strategy for following up with people doing simple binds and asking them not to do that. You may want to consider spot auditing owners of any kind of service ID that does any kind of authentication with your AD DS implementation, to make sure they aren't doing things like exposing passwords via unprotected forms authentication on web sites, etc. You can probably use a combination of institutional authentication policy, monitoring processes (such as intrusion detection system rules that look for simple LDAP binds) and spot checks to mitigate this risk adequately.

Q: What is the security boundary for an AD DS deployment?

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

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

Glossary

Authentication Credential

The information entered or held by an individual used to verify their identity during authentication. Most commonly, username/password.

Authentication Secret 

Information used to validate an individual in an authentication negotiation; e.g., in addition to actual authentication credentials, the information negotiating the initial exchange of a session key or authentication challenges is an “Authentication Secret”.

IPSec

Internet Protocol Security (IPSec) is a framework of open standards for ensuring private, secure communications over IP networks through the use of cryptographic security services. The Microsoft Windows implementation of IPsec is based on standards developed by the Internet Engineering Task Force (IETF) IPSec working group.

IPSec establishes trust and security from a source IP address to a destination IP address. The only computers that must know about the traffic being secured are the sending and receiving computers. Each computer handles security at its respective end with the assumption that the medium over which the communication takes place is not secure. Computers that only route data from source to destination are not required to support IPsec unless firewall-type packet filtering or network address translation (NAT) is performed between the two computers.

You can use the IP Security Policy snap-in to create, edit, and assign IPsec policies on a local computer and remote computers.

Identity Provider (IdP)

The IdMS system component that issues Assertions.

Kerberos
Kerberos is an authentication protocol which works on the basis of "tickets" to allow nodes on a non-secure network to prove their identity to one another in a secure manner. It provides mutual authentication - both the subject and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may employ public key cryptography by utilizing asymmetric keys during certain phases of authentication. (from Wikipedia). When used in this document "Kerberos" generally refers to the Windows-specific Kerberos implementation.

LDAPS
LDAPS refers to encrypted LDAP communication achieved either by using an SSL tunnel (via LDAPv2) or by using the LDAPv3 Transport Layer Security (TLS) extension. Which method is used depends on what the client supports. The default port associated with LDAPS traffic is 636, and for AD DS global catalog traffic is port 3269. Strictly speaking, the term LDAPS was deprecated with LDAPv2, but in common usage it is also used to refer to TLS based encrypted LDAP traffic.

LMHASH
LM hash, LanMan, or LAN Manager hash was the primary hash that Microsoft Windows versions prior to Windows NT used to store subject passwords. Support for the legacy LAN Manager protocol continued in later versions of Windows for backwards compatibility, but was recommended by Microsoft to be turned off by administrators; as of Windows Vista, the protocol is disabled by default, but continues to be used by some non-Microsoft CIFS implementations. (from Wikipedia)

NTLM/NTLMv2
NTLM (NT LAN Manager) is a suite of Microsoft security protocols that provides authentication services.  NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product, and attempts to provide backwards compatibility with LANMAN.  NTLM version two (NTLMv2), which was introduced in Windows NT 4.0 SP4 (and natively supported in Windows 2000), enhances NTLM security by hardening the protocol against many spoofing attacks, and adding the ability for a server to authenticate to the client. (from Wikipedia)

SPNEGO

A protocol (arguably a GSSAPI mechanism) that allows use of Microsoft AD DS authentication tokens on the desktop to be extended to authenticate web-based applications.

SYSKEY
A tool used to configure the startup key, a random, 128-bit, symmetric cryptographic key created at system startup and used to encrypt all of the user`s symmetric cryptographic keys. Use SysKey with a password shared between two individuals (person A knows the first 8 characters, person B knows the second 8 characters). The steps for configuring SysKey are here:http://technet.microsoft.com/en-us/library/cc773183(WS.10).aspx

Comments

Please send any comments regarding this document to: ad-assurance@incommon.org

Contributors

• Lee Amenya, University of California, San Diego
• Brian Arkills, University of Washington
• Michael Brogan, University of Washington
• Jeff Capehart, University of Florida
• Erik Coleman, University of Illinois at Urbana-Champaign
• Warren Curry, University of Florida
• Eric Goodman, University of California Office of the President (editor)
• Mark Rank, University of California, San Francisco
• Nick Roy, Penn State
• Ron Thielen, University of Chicago
• David Walker, Internet2
• Ann West, Internet2
• Jeff Whitworth, University of North Carolina at Greensboro

The contributors of this version of the Cookbook would like to thank the authors of the original version of the AD Cookbook (based on IAP version 1.1) for their foundational work.

Version History

2011 May 5 - Initial work within the CIC CIOs Identity Management working group

2011 July 20 - CIC IdM Draft

2011 August 15 - InCommon Wiki Draft

2012 January 11 - InCommon Public Review Draft 1

2012 February 13 - Version 1.0

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

2013 June - Revisions to support IAP version 1.2 including alternative means statements, refactoring to de-duplicate controls and pair them with risk mitigations

2013 August - Revisions to add explicit IAP language interpretations, broader management assertion language and some additional reorganization.

2013 October 2 - Version 20131002-DRAFT released for community comment.

2014 April 28 - Community and AAC comments incorporated. Final "InCommon Silver AD Cookbook 201404" version released

2015 October 1 - Added Post-Release Notes section and Note #1 (also added a reference to this note in Appendix C)

Post-Release Notes

This section contains information the editors found relevant to the document after the final 2014 publication of the Cookbook.

Note #1: Using Bitlocker with Azure based VMs - 10/1/2015

Microsoft recently announced the ability to use Bitlocker with Azure based VMs, including managing the Bitlocker encryption keys with a FIPS validated Hardware Security Module (HSM). This allows an exception to the limitation identified in Appendix C in the original report, which called out that Microsoft does not support Bitlocker encryption of DCs deployed on VMs. For more details on this support, see https://channel9.msdn.com/Events/Microsoft-Azure/AzureCon-2015/ACON214.