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@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@le.ac.uk>