Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

• Eric to take a first cut at reviewing the Cookbook and develop recommendations for what to keep, cut, and edit.

 

So this one turned out to be quite a bit more challenging than I expected. (It didn’t help that I didn’t really get started on it until today).

 

My edits were – probably unwisely – made on a second copy of the original cookbook (Called “Working copy of …” rather than just the AD cookbook title).

 

https://spaces.internet2.edu/display/InCAssurance/Working+copy+of+InCommon+Silver+with+Active+Directory+Domain+Services+Cookbook+-+May+2013

 

This resulted in page to be harder to find, without adding any value since Confluence would have saved the original pre-edit version anyway. If I can figure out how to move my copy back into the original one, I’ll do that and delete this alternate copy.

 

 

In any case, some major disagreement between the AD cookbook analysis and the Alternative Means strategies we identified around stored passwords. Specifically, the AD cookbook states that the specification of the use of salt is over-prescriptive and basically states that the entire requirement (of using a salt, or on access encryption) is unnecessary. Therefore there is no clear “stub” for us to note the need of Bitlocker (though the use of Bitlocker is encouraged). This conclusion is largely due to the Cookbook misapplying (in my estimation) the entropy requirements against brute force password guessing to the protection of passwords at rest (see my comments in the doc).

 

Because the risk assessments are so out of phase with one another in the area of stored passwords, I didn’t see how to put in our commentary without completely rewriting (and revising) the original AD cookbook suggestions, which I think bears more discussion – or at least we should alert the original group that we disagree – before actually making any edits of that magnitude.

 

On the other areas, we mostly agreed; I added a couple of comments, but there’s still lots of room for editing what I added. E.g., I say “add some of Jeff’s references here” rather than actually having selected his best references. I’m willing to do that addition as well, I just didn’t get to it at this point.

 

I’d like to see the document better formatted to clarify what sections are background info, what are specific operating configuration recommendations, and what is language to use to assert (non-AM) compliance, but I haven’t quite sussed out how to do that yet. For now, I squeezed in our two main additional differences (Require Bitlocker, require invalidating subjects using insecure authentication protocols), and tagged the base disagreements between the two groups. In the doc, my comments are identified with text inside of <<double angle brackets>>.

 

--- Eric