Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

Eric,

 

Mary had referred to the “Identity Management Functional Model” diagram in the IAAF on page 4.  I am almost thinking a modified version of that diagram would help explain the in-scope/out-of-scope consideration for AD DS.  Would it be possible to have a simple diagram and explanation?

 

For example, it seems like we have a split-personality “Verifier” for AD DS such that if the protocol in use is LDAPS with UserID/Password over SSL/TLS, then the arrow for Verifier to IdP would be a protected channel.  For the Verifier to the “non-IdP Apps” for AD DS, if the channel were NTLMv2 or Kerberos,  then the traffic would be out of scope and not applicable to requiring approved algorithms or protected channels.

 

We would want to make an Active Directory Domain Services IDM Functional Model specific diagram based on the one from page 4.

To modify the diagram, color code and label each path separately and specifically:

 

(AD DS) Verifier à IdP.  Color this path green; Label path1 (Approved Algorithms)

(AD DS) Verifier à Non-IdP Apps.  Color red; Label path2 (Non-approved Algorithms = outside scope, if at least NTLMv2, Kerberos)

 

Simple statement:  As long as protocol(s) for path1 <> protocol(s) for path2, and path1 protocol(s) = using protected channel, and path2 protocols do not include LAN MAN and NTLMv1, then AD DS is configured per Cookbook and acceptable configuration for the Silver Profile.

 

I suppose the caution here is that the explanation should ensure that someone doesn’t think they can take the NT HASH or Kerberos ticket and send it over a protected channel to the IDP and be compliant. The intent is to isolate the protocols to match their intended destination, IdP or non-IdP, and don’t mix the two.

 

The original diagram would seem to indicate that everything in the dotted line would be in-scope for IdMS operations, so it would almost be like AD DS would straddle the line half in and half out, depending on what, where, and how network [authentication] traffic is sent.

 

Jeff

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, November 04, 2013 5:39 PM
To:
Subject: [AD-Assurance] Next steps

 

Hi all,

 

So we came away from Friday’s call with some good feedback, but I’m not clear whether we have specific next steps. The general request was to clarify the unclear things and to shore up the mapping from the interpretation/discussion sections to the configuration recommendations, but that’s a pretty broad scope. Any specific items we should be undertaking?

 

--- Eric