NTLMv2 with FreeRADIUS

[Matthew Newton]

On Wed, Apr 09, 2014 at 03:27:57PM -0400, John McCarthy wrote:
> On 9 Apr 2014, at 15:14, arr2036 wrote:
> 
> > It's not in a local configuration file if it's being sent to an AD server.
> 
> Gotcha, and that is basically what makes NTLMv1 insecure- is if it is
> stored in a file that can be cracked (from what I understand of it).
> 
>  Is there a way to encrypt the NTLM traffic, just to be on the safe side
> (if it isn't already)

With PEAP/EAP-MSCHAPv2:

  There is an EAP tunnel from the client to the RADIUS server
  (generally EAPoL (over LAN or wifi) then, from the NAS onwards,
  EAP inside RADIUS).  In this case that is PEAP, which is TLS
  encrypted, so you don't need to worry about what's inside it.
  (What _is_ inside it is MSCHAPv2.)

  From the RADIUS server, the EAP is decrypted, then the MSCHAPv2
  bit is transformed to NTLMv1 and pushed via ntlm_auth to AD. So
  NTLMv1 goes over the network between the RADIUS server and the
  DC. I don't know if Samba encrypts that any more 'on the wire',
  I assume not, as it's standard NTLMv1.

So if you're worried about the cable in your datacentre that links
the RADIUS server and AD DC that much, you could potentially
secure it with IPsec or some other similar method.

If you're worried about your RADIUS server being compromised, then
you also need to be worried about your DC being compromised, as
that's the machine that stores the NTLMv1 hashes in it's SAM
database anyway.


With TTLS/PAP:

  EAP is similar: TTLS is an encrypted tunnel ("Tunneled TLS")
  from client to RADIUS server.

  On the RADIUS server the inner part is decrypted, and the RADIUS
  server then has the clear text username and password. It can
  then use all manner of methods to authenticate them, which could
  be NTLMv2, Kerberos, testing aginst LDAP(s) or IMAP, or
  whatever.

So both parts over the network can be secure - EAP is anyway, and
RADIUS to the DC can also be using whatever chosen method. However
if the RADIUS server is compromised then the clear passwords can
be sniffed, which is essentially the same as if your DC is
compromised and they access the SAM database anyway.


With EAP-TLS:

  An encrypted TLS tunnel is brought up inside EAP, and
  certificate exchanges *both* ways. The RADIUS server checks the
  client certificate presented is correct, and immediately lets
  the client on if so. (Similarly the client will check the RADIUS
  server cert, as it should also in the above methods.)

  That's it. Nothing else over the network.

It depends on whether you want to protect the servers or the data
in transit over the network. It sounds like EAP-TLS is the only
option they will let you use, but then you need to protect your
CA to make sure only valid certs are issued and signed. There's
always one place somewhere that is the weak point in the chain.

With EAP-TLS comes certificate management, expiry, key rotation
and the like. It can be a right pain. It is made easier by AD,
which will manage domain joined client certs for you, but you're
on your own with non-domain clients. With EAP-TLS you might also
have problems getting iPads and similar mobile devices on entirely
and many just won't do EAP-TLS, so you're probably laptops only in
the majority of cases.

Seriously, PEAP/EAP-MSCHAPv2 isn't as bad as it sounds for using
NTLMv1, and if you're worried about the security of your network
in your datacentre (which I would really want to protect in other
ways) then run that part over IPsec.

But they are basically your options.

Whenever I've looked at PCI in the past I've decided the best way
to achieve the impossible demands would be to essentially turn
everything off and go home. Or change PCI assessor to one that has
some sense.

Cheers,

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>