Meeting the InCommon Assurance profile criteria using Active Directory

[Ron Thielen <>]

++1

 

From: [mailto:] On Behalf Of Rank, Mark
Sent: Monday, October 07, 2013 1:01 PM
To:
Subject: RE: [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft

 

 

+1

 

 

--------------------------------------------------

Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)
email:

phn:414-331-1476

--------------------------------------------------

 

CONFIDENTIALITY NOTICE: This e-mail message including attachments, if any, is intended only for the person(s) or entity(ies) to which it is addressed and may contain confidential and/or privileged material. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: [] on behalf of David Walker []
Sent: Monday, October 07, 2013 10:59 AM
To:
Subject: Re: [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft

I agree with everyone's comments.  It's a good response.  The only thing I would say is to emphasize Jeff's point of the Cookbook being focused on compliance.  I think we agree with much of what Joe says; it's just not needed for compliance with Silver.

David

On Mon, 2013-10-07 at 17:42 +0000, Capehart,Jeffrey D wrote:

Thank you for putting the response together, Brian.  Nice work!

In general, I am thinking maybe we could say there are certain configurations and choices that an IDPO could make to provide a higher level of security than the basic/minimum recommendations in the cookbook.  (For example, turn off NTLM and use Kerberos only, go to DFL 2012, eliminate Windows XP workstations, or automate monitor & mitigate for 24 hour processing instead of 72.  However, the recommendations are made for basic compliance not best security config.)

A couple comments on BitLocker & NTLMv2:

>BitLocker decrypts data on a sector by sector basis *when* that data is needed. It does *NOT* decrypt the entire disk at boot time. This is well-documented >and we took the extra step of verifying this with Microsoft.

The "decrypt the entire disk at boot time" is where I think some people get hung-up.  Yes, a key is read in at boot time to be able to decrypt the data on-the-fly as it is read from disk, but it is not used to decrypt and then store the data unencrypted back out on the disk (i.e. remove encryption from the disk).  Therefore, BitLocker is in compliance, regardless of the fact that once booted up, the disk appears to be "decrypted" from the perspective of the logged-on user or server operating system.  If the system had its plug pulled, the data on the disk would still be encrypted.  Maybe if we explain this 5 different ways, one of them will eventually work for everyone.

>Therefore, NTLMv2 use is not in violation of the Silver IAP (assuming NTLM cannot be used to authenticate to the IdP).

>If AD-DS is the verifier for your IdP, then your concerns are warranted.

As Eric also mentioned, the AD/verifier/IdP/IDPO relations can be confusing if not explicitly pointed out.  While an IDPO can operate an AD DS, which can be used as a verifier for the IdP, the verification needs to be performed over LDAPS to AD DS with username/password collected from the IdP over a protected channel.  In other words, the IDPO can use AD DS (Kerberos Tickets, NTLMv1, v2) as long as the IDP (Shibboleth) does not use those same authentication methods when authenticating the Subject.  (This may need some work to make it more clear and distinguish between IdP/IDPO and what is OK.)

-Jeff C.