Clear cached authentication for network share

Context: I map a cifs share in windows using NTLMv2 authentication, as the legacy server doesn't support kerberos. I am not prompted for login:

net use S: \\server.domain.com\share /persistent:yes
The command completed successfully.

This is fine until I change my password. Windows seems to continue to attempt to connect with the old credentials, even after logging off and back on or restarting multiple times. The only thing I've discovered works is using a different host name for the connection:

:: After changing password, restarting, and logging in with updated password
net use S: \\server.domain.com\share /persistent:yes
Enter the user name for 'server.domain.com'
:: running credentials failed, 'access denied' message logged on server

:: Manually entering credentials works:
net use S: \\server.domain.com\share /persistent:yes
Enter the user name for 'server.domain.com': DomainUser
Enter the password for 'DomainUser' to connect to 'server.domain.com':
The command completed successfully.

:: Using a different host name works
net use S: \\192.168.100.100\share /persistent:yes
The command completed successfully.

The issue eventually "goes away," but I assume the NTLM token/session/key for that device just expires at some point, and windows is forced to create a new one. Or maybe there's another explanation for this? I looked at the following already:

• Everything I found about NTLMv2 says nothing should stick around after a reboot
• SMB allows for caching files, but I haven't found a way to clear it without disabling it in the registry
• I double-checked for kerberos tokens with klist and for anything in Credential Manager
• net only saves credentials if you specify /SaveCred, and would be removed with /delete anyways.

I want to understand what function could be causing this behavior, or narrow it down to some sort of bug. Any ideas?

Edit: After some fiddling with wireshark, I've identified that it's held together by strings:

• the server is advertising that it supports kerberos (though under normal circumstances kerberos tickets are not created).
• The client actually attempts to get a kerberos ticket, but fails due to not supporting the encryption type. It falls back to ntlm and that works...
• For some reason I haven't figured out yet, attempting to connect with expired credentials causes the client to start succeeding at getting kerberos tokens, which is not correct.
• The server cannot authenticate the user with the token, so it denies access.