Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Thanks for the summary, Jeff.

 

Quick notes on the easier bullets at the top of your note.

 

·         DCß term is used in 3.2 but not defined until section 4.1.1

 

I added the “DC” definition to the Domain Controller reference in section 3.1.

 

·         [see] http://support.microsoft.com/kb/832017 for details of the impacts requiring LDAPS has on Windows clients   ß KB article doesn’t talk about LDAPS??

 

Yikes, good catch, as I didn’t check the content of any links. Looking at the appendices, the information is not called out there either. This may just mean we have stale or incorrect links, but it may also mean I made up technical information. This bears more investigation. (I also note that the Appendices conflate LDAP Signing and LDAPS (TLS/SSL), but that’s a separate issue).

 

·         “impractical”  ß Should we have a single definition in the footnotes and refer to it?

 

I added a section header “Glossary” after the appendices. It’s currently blank, but perhaps that’s a good place to collect these things (“DS”, “AD DS”, etc).

 

Finally, as my next documentation task relates to the MFA Cohortium, I added language in the “Purpose” and “Scope” sections to indicate that our recommendations and assertions are relevant to an AD deployment that relies on user-selected passwords as the primary authentication credential, and that if MFA is in use for authenticating Silver IAQ holders that many of our recommendations and assertions would be superseded by ones relevant to the MFA technology and functionality.

 

--- Eric

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Thursday, September 05, 2013 7:20 AM
To:
Subject: [AD-Assurance] Updates to AD Cookbook 2013

 

Eric,

Thank you for reworking the cookbook.  Nice job!

 

I have copied into this email some of my observations as well as many of your “questions/concerns in Boldface Italics so that maybe we can identify them for future discussion.”

 

If this seems long, it reflects all the work you did.  Hopefully everyone can scan through these and see if anything jumps out.

 

·         DCß term is used in 3.2 but not defined until section 4.1.1

 

·         [see] http://support.microsoft.com/kb/832017 for details of the impacts requiring LDAPS has on Windows clients   ß KB article doesn’t talk about LDAPS??

 

·         “impractical”  ß Should we have a single definition in the footnotes and refer to it?

 

·         Should we standardize on “Relevant IAP Section:” to disambiguate the Cookbook numbering from the IAP sections and help minimize the algebra homework look?

 

--Jeff C.

[INCLUDED COMMENTS/NOTES FROM COOKBOOK REVISIONS]

 

LDAP data signing encrypt the data portion of each LDAP packet, including authentication traffic, but if the domain is configured to limit authentication traffic to require signing, it can impact the operation of older or non-Windows clients in an AD DS environment. (?ALSO HOW IS THE DATA ENCRYPTED?IF RC4 OR MD5 it's still not a protected channel?)

 

[3] If the IDP login page supports SPNEGO authentication, then authentication secrets used to authenticate a user to a domain WOULD be in scope of this requirement.

 

AES is used for Kerberos encryption if properly configured. We need to add how to do this configuration

 

We may need an alternate means statement here to allow SSL/TLS using RC4.

• need LDAPS instructions
• we separately pointed out that standard SSL/TLS uses the RC4 cipher. This may STILL need an alternate means section here to justify its use until there's widespread adoption of newer SSL/TLS protocols, though following the assertion we made for 4.2.6.2.1, we can probably just declare interception as "impractical"

 

We recommend you disable all domain support of the LM and NTLMv1 protocols instructions?

 

[4.4. Secure Authentication Traffic Considerations Specific to 4.2.5.1 Resist Replay Attack and Kerberos] Is this still relevant? The replay attack will get you into the DC, but not into the IdP (unless SPNEGO is supported).

 

[4.2.3.5 Basic Protection of Authentication Secrets (no specific configuration required)]

This is a BRONZE requirement... should it be listed here? If so then we can add it to the list of sections reviewed, above. Otherwise we should remove it.

Kerberos V uses a replay cache to protect against replay attack. When combined with an appropriate account lockout policy, (The start of this sentence is a config statement, not a management assertion. It should be moved up to the config section and "appropriate account lockout policy" should be defined)

 

I also note that the management assertion language actually has no dependency on the "Time Skew" setting we recommend in the "Config" section; either we need an assertion statement that explains why we are using it, or we state that we are relying on the replay cache and account lockout policy and call it a day)

 

LDAP data signing, which encrypts the password data need to validate algorithm to see if this is good enough.

 

 

From: [] On Behalf Of Eric Goodman
Sent: Thursday, September 05, 2013 4:13 AM
To:
Subject: RE: [AD-Assurance] Notes from Today's call

 

So I took a stab at reorganizing the AD Cookbook according to the discussion (at least as I remember it) from last week’s call.

 

WARNING: Because of the incorporation of the AAC interpretation language, the decision to add separate interpretation language for several sections and the reorganization we discussed (putting Interpretations and Management Assertions in their own sections), the edits ended up being rather more substantial than I expected:

 

·         In many places I changed the interpretation, configuration or management assertion language where it appeared appropriate based on the AAC clarification. This meant I had to make some judgment calls on which items were covered by 4.2.3.6.2 (which we reduced the scope of, per the clarification) and 4.2.5 (which now only requires “impractical to attack” rather than “Protected Channels”).

·         Most of the language I used for the Interpretation section came from the AAC clarification email or from the previous analysis we did (the matrix at https://spaces.internet2.edu/x/BA8wAg).

·         In making the different sections in the reorg more distinct, I found places where the language was somewhat messy, specifically Sample Management Assertions that actually contained “Interpretation” or “Configuration” text and the like. I tried to “normalize” the sections, but that meant adding or rearranging the text a bit more than I had intended. I don’t believe I added language we haven’t previously discussed, but you might want to double check me.

·         In some cases I felt that spelling out the interpretations or management assertions uncovered some new questions or clarifications. In those cases I noted the questions/concerns in Boldface Italics so that maybe we can identify them for future discussion.

·         I edited until I ran out of steam (and appeared to have made a complete pass). I have NOT proofread the update, so there’s a good chance that typos and sentence fragments abound. Feel free to point them out and/;or fix them.

·         I recognize that the combination of the auto-section numbering and the liberal use of IAP section numbers in headers ended up making the headers and TOC reminiscent of a second year algebra homework set. I may try to clean up later.

·         I’d love a better WYSIWYG editor for confluence…

·         Thankfully confluence versioning means we won’t have lost the original/previous version of edits.

 

--- Eric

 

From: [] On Behalf Of Ann West
Sent: Friday, August 30, 2013 1:52 PM
To:
Subject: [AD-Assurance] Notes from Today's call

 

Hi All,

 

I wrote up a few notes from today's call. They can be found in the wiki at :

https://spaces.internet2.edu/display/InCAssurance/Aug+30%2C+2013

 

Best,

Ann