Meeting the InCommon Assurance profile criteria using Active Directory

[Jeff Whitworth <>]

I'll dig through what we found.  I know we ended up finding a member of the samba dev team (Andrew Bartlett) that pointed out there is actually a way to tell a DC to "pretend this NTLMv2" for the purpose of the rule - apparently a trick not publicly available for use.  I'll go look for the evidence to back this up, but the result of our work was that Microsoft NPS used this trick to bypass the NTLMv2 requirement.  The samba dev team was basically complaining that if Microsoft could do it, why can't they.  So as far as more secure - no.

I believe the other option would be to install the NPS role on a DC, effectively eliminating the network traffic between the radius and domain controllers.  I guess you would still have the issue of client to radius/DC server.

Jeff

Jeff Whitworth

Manager, Enterprise Systems Architecture

University of North Carolina at Greensboro

336.334.9854

 

MCITP: Enterprise Administrator

GIAC Certified Windows Security Administrator

On Thu, Apr 18, 2013 at 11:37 AM, Brian Arkills <> wrote:

By "secret sauce" do you mean that there might be a more secure option? If so, we'd definitely be interested in more details.

 

 

From: [mailto:] On Behalf Of Jeff Whitworth
Sent: Thursday, April 18, 2013 8:26 AM
To:
Subject: Re: [AD-Assurance] RE: Parking lot item: eduRoam passwords

 

Agreed. We've run into this issue with our eduRoam implementation as well. At some point we came across evidence explaining some secret sauce used if you are using Microsoft NPS for your radius server. We currently use an ipsec tunnel between freeRADIUS and two dedicated domain controllers instead. I'll be more than happy to dig up more info if needed.

Jeff

On Apr 18, 2013 11:05 AM, "Brian Arkills" <> wrote:

It strikes me that while not solely an AD issue, Radius/MS-CHAPv2 should go on the list for Dean to take to Microsoft as badly in need of attention.

 

From: [mailto:] On Behalf Of Coleman, Erik C
Sent: Thursday, April 18, 2013 7:09 AM
To:
Subject: [AD-Assurance] RE: Parking lot item: eduRoam passwords

 

For us this expands more-generally into “all things RADIUS-authenticated”, which besides our eduroam access, includes all of our 802.1X wireless and VPN services.  It so happens they tie in to AD for authentication directly via RADIUS/MS-CHAPv2, and in fact are the only things holding us up from disabling NTLMv1 completely.  Should this perhaps be generalized as an issue for any services that use AD via RADIUS/MS-CHAPv2?

 

--

Erik Coleman

University of Illinois at Urbana-Champaign

 

 

 

 

From: [] On Behalf Of Eric Goodman
Sent: Wednesday, April 17, 2013 8:05 PM
To:
Subject: [AD-Assurance] Parking lot item: eduRoam passwords

 

When this subgroup was initially being discussed, I asked a question about eduRoam services vis-à-vis Silver certified AD services.

 

It’s my understanding that the MS-CHAP password is one of the lower-strength password hashes (NTLMv1/Unsalted MD4 IIRC). If so, then any eduRoam-authenticated account would inherently be non-Silver certifiable.

 

This isn’t entirely an AD issue (hence “Parking Lot Item”), as it would hold true for any account whose password is hashed for use in eduRoam. But it’s another one of those examples of “things that you may break by configuring to meet Silver”. I guess if we (or the parent AD Cookbook project) make a recommendation that could break the eduRoam model, I think it would be nice to at least notify and perhaps meet with the eduRoam folks to discuss first.

 

And as usual, please feel free to correct me if my assumptions about the underlying encryption are incorrect.

 

--- Eric