Note that cracking the NT hash rarely results in escalation of privileges due to the pass-the-hash vulnerability. There is almost never any need to crack NT hashes.
The attacks you need to defend against are:
1) online password guessing, 2) Kerberoast, 3) cracking NTLMv2 authentication handshakes, 4) cracking DCCs (Domain Cached Credentials).
1) is solved by applying a moderate list of banned passwords, a sensible lockout threshold and MFA for things on the internet.
2) and 4) are only against high privileged accounts, as they imply access to a low priv account already. (You need an account to request kerberos tickets and if you can read DCCs, you usually can compromise at least a computer account). High privilege accounts should never be accounts that you log on with before you can access a password manager, so they should simply use a 16 character randomly generated password. Make this a requirement in your org, perhaps crack passwords yourself regularly to confirm.
So you're left with 3) which is effectively salted and orders of magnitudes harder to crack compared to NT hashes.
And guess what, in windows networks authentication is done with domain credentials, but those are bound to your physical console, so a password manager can't be used for remote authentication in this case.
Windows (in a domain environment) sends a Kerberos token for network auth which is generated on sign on and signed by a domain controller (authentication server). When the user authenticates to a network service, the token is sent to the service to validate without the need for an additional network hop to the domain controller.
Each "console" is a "seat" sort of like a PTY emulating a serial connector. Whether you're hands on keyboard or using a remote desktop connection, your login session has one kerberos ticket which is used for authentication automatically.
Yes, I know how Kerberos works. The TGT is not bound to anything though, it can be stolen and reused elsewhere. And in the default setting, an attacker doesn't need to rely on Kerberos as an authentication mechanism, since NTLMv2 support is widely available. It's available by default.
Nevertheless, did GP mean Kerberos tickets by "domain credentials"? How does Kerberos prevent the use of password managers? I'm confused.
When you log into the system, a keyboard is usually the only device you have to enter the password, unless you store in on paper or on a second device. And even if you store it on paper and the password is long, some operations like lock screen (that can be also misconfigured by domain admin) become expensive and thus impractical.
Sure. That's why I recommended password managers only for high privilege accounts. Passwords of those accounts should almost never be typed on a keyboard. They can be looked up by authorized personnel who logged on first with their low privilege account.
The attacks you need to defend against are: 1) online password guessing, 2) Kerberoast, 3) cracking NTLMv2 authentication handshakes, 4) cracking DCCs (Domain Cached Credentials).
1) is solved by applying a moderate list of banned passwords, a sensible lockout threshold and MFA for things on the internet.
2) and 4) are only against high privileged accounts, as they imply access to a low priv account already. (You need an account to request kerberos tickets and if you can read DCCs, you usually can compromise at least a computer account). High privilege accounts should never be accounts that you log on with before you can access a password manager, so they should simply use a 16 character randomly generated password. Make this a requirement in your org, perhaps crack passwords yourself regularly to confirm.
So you're left with 3) which is effectively salted and orders of magnitudes harder to crack compared to NT hashes.
I talked about this at Troopers; unfortunately the video is not yet available. http://troopers.de/downloads/troopers22/TR22_BetterPasswords...