Meeting the InCommon Assurance profile criteria using Active Directory

[Ron Thielen <>]

Thanks David.  If I don’t hear any objections before then, I will put the changes into the wiki by the close of business tomorrow.

 

From: [mailto:] On Behalf Of David Walker
Sent: Tuesday, October 29, 2013 12:12 PM
To:
Subject: Re: [AD-Assurance] proposed scope addition

 

Ron, this looks good to me.  I noted one typo below.

David

On Mon, 2013-10-28 at 22:31 +0000, Ron Thielen wrote:

I propose the following change to section 2,3. I broke the first paragraph into two and added 4 sentences explaining the need to understand how AD fits into the IDMS infrastructure in the context of InCommon identity assurance. Also deleted a redundant “IAQ” in the MFA paragraph.

2.3. Scope

This document focuses specifically on those aspects of Silver IAP compliance specific to an AD environment when using user-selected passwords as the authentication credential. Other authentication components in your environments must also be assessed for compliance with InCommon Silver, but are outside of the scope of this document. For instance, HTTP traffic is not used to communicate with an AD DS store, so requirements for securing HTTP traffic are not discussed in this document, even though institutions will likely need to address security of HTTP traffic in an overall compliance review.

Any institution undertaking a Silver implementation project should carefully read the InCommon Identity Assurance Assessment Framework (IAAF) and Identity Assurance Profiles (IAP), both available from the Assurance section of the InCommon web site. You should thoroughly understand these documents, and determine the remediation needed in your specific environment. Specifically, your will need to understand the role that AD does and does not

"Specifically, you will need..."

play within the context of the defined terms of the IAAF. For example, while AD may provide identities it is likely not the IdP (Identity Provider) for the purposes InCommon Silver or Bronze identity assertions, since AD is unlikely to be issuing the assertions. Similarly, AD may be a Verifier but it may or may not be the Verifier used by the IdP in your environment. Since many of the IAP’s requirements are scoped to some component or process within the identity management infrastructure, a careful understanding of where AD fits within that infrastructure is necessary to understanding which IAP requirements apply to AD in your environment and how they may apply.

Note that this document does not specifically address Bronze IAP compliance.

We believe that many of the approaches documented in this cookbook are applicable to all versions of AD DS from Windows Server 2003 forward (with possible exception of the IPSec approach), although the exact steps to implement them may vary. The documentation below references Windows Server 2008 R2 settings.The recommendations of this document are challenging to implement in a production environment, but the authors believe it is possible to implement them in a reasonable amount of time given some dedicated project resources and a good plan. The size of your AD DS deployment, the types of clients connected to it, the number of customers served (and in what capacity they are served) represent some of the variables you will need to consider when allocating staff and other resources to your AD DS risk mitigation project.

We also note that using Multi-Factor Authentication (MFA) to authenticate Silver IAQ holding users may be a more effective strategy to achieve certification than the recommendations provided in this document, with its focus on securing of password storage and communication of replayable passwords. An MFA-based InCommon Silver compliance review would focus much more on the technology and function of the MFA solution implemented.

A note on SSL/TLS and SHA1: At the time of this writing, there is ongoing discussion of whether or not SSL/TLS based on SHA1 encryption will be considered a FIPS-approved Protected Channel after Jan 1, 2014. All recommendations in this document that refer to SSL/TLS channels assume that such channels are based on FIPS-approved algorithms. Whether SHA1 specifically will suffice for this purpose is beyond the scope of this document. More information regarding this specific issue is available in Draft Special Publication (SP) 800-52 (Revision 1).

 

 

Ron