Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft

Chronological Thread 
  • From: "Capehart,Jeffrey D" <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft
  • Date: Mon, 7 Oct 2013 17:42:26 +0000
  • Accept-language: en-US

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.

Archive powered by MHonArc 2.6.16.

Top of Page