Meeting the InCommon Assurance profile criteria using Active Directory

[Ron Thielen <>]

Thanks for the comments David.

 

We mention Radius in section 4.2.1, but the section where my comment becomes relevant is 5.2.3.  We recommend setting the LMCompatabilityLevel to 5 in 5.2.3.  One consequence of the point I’m raising is that if you do that and that domain is also used by Radius, then your Radius installation may well break.  Maybe it should be mentioned in Appendix A as a known issue.  (I was also looking for additional insight into the issue, or magic bullets.  It was raised as a point for discussion in the first AD Cookbook group, but we never actually got anywhere with it.  The discussion went something like “Q: Hey what about Radius?  A: Yep, there’s that.”)

 

Regarding BitLocker:  At this point, I’m looking for opinions on the approach, so I appreciate your sharing yours.  I understand that there may be a lot of debate on this as an approach. If my physical access controls have been audited for FISMA moderate compliance, which they have, then I’d argue that should be good enough.  The alternative for me is to move a half dozen DCs to physical controllers and lose the benefits of virtualization, stand up a Hyper-V installation which we’re not planning, or gamble on some third party encryption product for VMWare like Porticor.  I think my approach represents the least risk for the institution, but we’re positioning ourselves for one of the alternatives if it’s rejected.  I don’t think we should mention media management controls until they are accepted as an alternative means.  Then we can update the doc if it seems appropriate.

 

Ron  

 

From: [mailto:] On Behalf Of David Walker
Sent: Thursday, January 30, 2014 2:03 PM
To:
Subject: Re: [AD-Assurance] Radius NTLMv1

 

Ron,

Some thoughts about the notes you've sent recently...

• Radius and Section 4.1.2.  I think these both relate to the fact that the IAP has different standards for verifiers, depending on whether a verifier is being used to generate an assertion containing the Silver IAQ.  If it is, there are fairly specific requirements about use of approved encryption algorithms, etc.  If it is not, then the requirement is that the IdPO have appropriate controls in place, but is otherwise not specific as to what those controls need to be.  I think the issues of Radius and verifiers not used by the IdP fall in this latter category.
• Bitlocker.  Personally, I agree that it should be possible to substitute strong physical access controls for storage encryption, but I suspect there would be debate on that point.  It's not really an AD-specific issue, though.  Do you think we should include it in the document?  (Also, I agree that storage encryption is a protection for physical access, not software/network mediated access.)

David

On Wed, 2014-01-29 at 18:43 +0000, Ron Thielen wrote:

I don’t think we ever sufficiently addressed the issue of Radius using NTLMv1 to talk with the DC. We address the fact that using PEAP-MS-CHAPv2 deals with the communication between the supplicant and the Radius server, but Radius servers which rely on Samba use NTLMv1 between the Radius server and a DC. 

 

When you research this you may find references to an unsupported patch for Samba that “fixes” the issue. Apparently all the fix does is flip a bit which tells the DC “I know this is NTLMv1, but I want you treat it as NTLMv2.” That doesn’t really address the issue.  From what I have found there is no easy fix for freeradius, steel belted radius, or others that use Samba code.

 

I think what we are left with here at my shop are three options.

 

1)     Leave NTLMv1 turned on for everyone, but tunnel all Radius AuthN traffic to the DC over a protected channel. Since I started my monitor and mitigate program about a year ago, I have only seen a handful of non-Radius NTLMv1 authentications. I may leave NTLMv1 turned on and continue monitor and mitigate.

2)     Move Radius to a Windows implementation. Apparently the Windows version uses the LSAS and can then support NTLMv2.

3)     Change Radius to use a separate DC still supports NTLMv1 but uses a protected channel between the DC and Radius. That way I can turn off NTLMv1 support on the main domain. This has several big downsides and probably is a non-starter. For example, all the supplicants would have to authenticate to a different domain causing havoc on the day of the change. It would also require one more credential sync between LDAP and this new DC.

 

Am I missing something?

 

Ron