ad-assurance - RE: [AD-Assurance] RE: Parking lot item: eduRoam passwords
Subject: Meeting the InCommon Assurance profile criteria using Active Directory
List archive
- From: Eric Goodman <>
- To: "" <>
- Subject: RE: [AD-Assurance] RE: Parking lot item: eduRoam passwords
- Date: Thu, 18 Apr 2013 20:08:39 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport07.merit.edu; dkim=neutral (message not signed) header.i=none
I saw the issue as a more fundamental problem: that storing the NTLMv1 (not v2) hash or transmitting an NTLMv1 challenge are both violations of Silver/800-63
(more definitively than any of the RC4 issues are), regardless of how you protect the transmission channel, as the hash/validation protocol are weak and the contents of the stored hash/validation exchange are too easily used to discover the originating passwords. --- Eric From: [mailto:]
On Behalf Of 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 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 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 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 |
- [AD-Assurance] Parking lot item: eduRoam passwords, Eric Goodman, 04/17/2013
- [AD-Assurance] RE: Parking lot item: eduRoam passwords, Coleman, Erik C, 04/18/2013
- [AD-Assurance] RE: Parking lot item: eduRoam passwords, Brian Arkills, 04/18/2013
- Re: [AD-Assurance] RE: Parking lot item: eduRoam passwords, Jeff Whitworth, 04/18/2013
- RE: [AD-Assurance] RE: Parking lot item: eduRoam passwords, Brian Arkills, 04/18/2013
- Re: [AD-Assurance] RE: Parking lot item: eduRoam passwords, Jeff Whitworth, 04/18/2013
- RE: [AD-Assurance] RE: Parking lot item: eduRoam passwords, Eric Goodman, 04/18/2013
- Re: [AD-Assurance] RE: Parking lot item: eduRoam passwords, Jeff Whitworth, 04/18/2013
- RE: [AD-Assurance] RE: Parking lot item: eduRoam passwords, Brian Arkills, 04/18/2013
- Re: [AD-Assurance] RE: Parking lot item: eduRoam passwords, Jeff Whitworth, 04/18/2013
- [AD-Assurance] RE: Parking lot item: eduRoam passwords, Brian Arkills, 04/18/2013
- [AD-Assurance] RE: Parking lot item: eduRoam passwords, Coleman, Erik C, 04/18/2013
Archive powered by MHonArc 2.6.16.