Meeting the InCommon Assurance profile criteria using Active Directory

["Coleman, Erik C" <>]

Ron,

 

I think I had actually chimed in several weeks ago in regard to this question, as this has been a thorn in our security team’s side. 

 

We are currently bringing up a POC using a variant of #3—our idea (so far just on paper) is to bring up extra DCs that the Radius servers will bind to, specified directly in the FreeRadius config.  These will be very light-weight versions of our DC, removed from public DNS (except for _msdcs for replication) and rather than in a different domain, isolated in their own AD site, configured so that basically the only incoming traffic it will handle will be from the pool of Radius servers.  Thus non-Radius NTLMv1 authN attempts will default to the main AD site and (hopefully) fail. In our case, we haven’t addressed the mitigation of the actual Radius NTLMv1 transmission, only narrowed it to a specific set of DCs so that we can turn off NTLMv1 on the “general use” domain controllers in the main AD site. We are still considering options on how to secure the Radius-AD channel.  

 

If this doesn’t work out, plan B may be to take over Radius using a Windows implementation.

 

-Erik

 

 

From: [mailto:] On Behalf Of Ron Thielen
Sent: Wednesday, January 29, 2014 12:44 PM
To:
Subject: [AD-Assurance] Radius NTLMv1

 

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