Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Fair enough. I’m okay with removing.

 

--- Eric

 

From: [mailto:] On Behalf Of Brian Arkills
Sent: Friday, November 08, 2013 9:46 AM
To:
Subject: [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections: Response from AD DS Alternate Means workgroup

 

Here's a comment on something I just noticed in the scope:

 

"For instance, HTTP traffic is not used to communicate with an AD DS store, so requirements for securing HTTP traffic are not discussed in this document, even though institutions will likely need to address security of HTTP traffic in an overall compliance review."

 

This statement has a factual inaccuracy. since WS2008, AD-DS includes the AD web services, which is a HTTP protocol method of communicating with an AD DS store.

 

I'd recommend either removing that sentence or changing it to reference some other example. I'd prefer removing it.

 

From: [] On Behalf Of Eric Goodman
Sent: Friday, November 08, 2013 9:03 AM
To:
Subject: [AD-Assurance] RE: [aac] AD Assurance Cookbook: Interpretation Sections: Response from AD DS Alternate Means workgroup

 

I’m concerned that the comments indicate that the main points of the recommendation were not understood.

 

None of us has argued that using Kerberos or NTLMv2 from the IdP to the verifier would be an issue for transmission of credentials. It's trying to secure it outside of IDP interactions (other uses of credentials) that we found nearly impossible.

 

On the Kerberos comment: I found one instance where we said "MIT Kerberos" where we meant "Windows Kerberos". In the other instances, it's clear we meant MIT Kerberos. E.g.,

 

For example, if an MIT Kerberos system is used as the IdP Verifier, but the same passwords used by that Kerberos system are also stored in an AD DS

 

The intent here was definitely to use MIT Kerberos to mean “a non windows Kerberos system”. When we use Kerberos, we are inconsistent about whether we mean “Kerberos the technology” or “a Windows Kerberos implementation”.

 

--- Eric

 

-----Original Message-----
From: [] On Behalf Of Ann West
Sent: Friday, November 08, 2013 8:25 AM
To:
Subject: [AD-Assurance] FW: [aac] AD Assurance Cookbook: Interpretation Sections: Response from AD DS Alternate Means workgroup

 

Hello,

 

 

After the AAC meeting with us last Friday, there was a side thread about the applicability of the cookbook to the majority of schools and whether it focused the recommendations too tightly to get around developing AMs.

 

Mary asked one of her staff to review the cookbook in this light and, in particular, how Va Tech could use it. Below is her response.

 

Ann

 

On 11/8/13 9:23 AM, "Dunker, Mary" <> wrote:

 

>Ann, Tom, & Scott,

> 

>I spoke with Marc DeBonis, who manages our Microsoft: Secure

>Infrastructure Services group. Marc thought it would be possible for an

>IdP like Virginia Tech to implement the configuration recommended in

>the AD cookbook. However, he noted that a more typical Windows

>implementation for an IdP would be to use ADFS with Kerberos or NTLMv2

>for Integrated Windows Authentication.

> 

>To meet IAP Section 4.2.3.6.2 requirements, Marc thought the only

>viable option for us would be to use "Encryption on the wire via IPSec"

>to force LDAP to use a secured channel. He thought it would be

>possible, using CAS as the login handler, to build an encrypted IPsec

>tunnel and use certificates for the connection between CAS and the AD on port 389 LDAP.

>If we made that IPsec tunnel required for all clients that connect to

>389 LDAP then certainly anything that can't verify the certificate

>chain (or do IPsec) will fail.

> 

>Marc and I both noticed the use of "MIT Kerberos" and unqualified

>"Kerberos" throughout the document. We assume when Kerberos is

>unqualified, the references are to Windows Kerberos, but it might help

>to make that clear.

> 

>As I said earlier, Virginia Tech has no plans to implement an IdP using

>our Active Directory credentials.

> 

>I hope this helps. I'm copying Marc in case you need clarification.

> 

>Best,

>Mary

> 

> 

>-----------------------------------------------------------------

>Mary Dunker

>Director, Secure Enterprise Technology Initiatives Virginia Tech

>Information Technology

>1700 Pratt Drive

>Blacksburg, VA 24060

>540-231-9327

>