I have a non-domain joined Win 10 computer which accesses shares on a domain joined Win 2016 server. At first connection with one of these shares, the Win 10 client is challenged and I supply domain credentials. Everything works as expected.

If I understand this correctly, a connection in this scenario will use NTLM rather than a more secure protocol such as Kerberos. Is this assumption correct? I have a valid use-case for this computer not to be joined to the domain, but would like to avoid using NTLM due to hacking tools such as Mimikatz. Are there any best practices to ensure non-domain joined computers can securely access shares on a domain?

  • Using Kerberos instead of NTLM2 makes almost no difference in the risk presented by Mimikatz.
    – Greg Askew
    Mar 14 '20 at 15:41

Yes, that is the case, though there are reasonable steps you can take to make NTLM authentication ...less risky. (But not risk free.)

Use long passwords

NTLM passwords are still digested using a relatively weak hashing scheme, with 8 character passwords being reasonably crackable in approximately 2-3 hours.(Source 1 Source 2) The traditional advice was using passwords at least 14 characters long, though that no longer stands because since Windows 2000 passwords are no longer digested by each 7 characters sequence, so essentially password length comes with linear benefits now. (Source) 14 isn't an unreasonable length to start with though.

Enforce use of NTLM version 2

You can use Group Policy Objects in your domain to enforce this in domain members if you haven't already, though on your non-domain computer you can use the Local Security Policy to set the same setting. You'll want the "Send NTLMv2 response only, refuse LM & NTLM" option. That being said when the two computers talk if only one of them (e.g. your non-domain computer) outright refuses LM and NTLMv1 the other computer will be forced to use NTLMv2 anyway, so you can safely apply this change to just your non-domain computer. This will only fail if the domain computers are configured to not support NTLMv2, but that's just outright daft.

On your non-domain computer you can do this as follows:

  • Open Administrative Tools via the start menu or control panel
  • Open Local Security Policy
  • Navigate to Local Policies then Security Options
  • Scroll down to Network security: LAN Manager authentication level
  • Change the value of this setting to "Send NTLMv2 response only, refuse LM & NTLM"

There are of course plenty of other security options you can configure around this one to enforce use of only the toughest connections, though from what I've seen Windows 10 already had good values defined for most of them.

  • Thanks for your answer, really helpful and your suggestions make a lot of sense. Mar 14 '20 at 12:37
  • Good question too. We have to think about these things at our office when staff bring in their own laptop to work on.
    – Adambean
    Mar 14 '20 at 13:35
  • NO, that is NOT correct. Kerberos will most definitely be used if the client has enough information to resolve a domain controller, which is decided by what credentials you type in. user@domain.com will absolutely first hit a DC it finds in domain.com before falling back to NTLM. The DC only needs the username and password to do Kerberos.
    – Steve
    Mar 16 '20 at 23:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.