Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

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