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.