Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
[NTLM] does not work when there is a valid credential in the Credential Manager #1622
I did this
On a Windows machine with logon user credentials that are accepted on the server NTLM authentication works ok:
curl -v -u : --ntlm localhost/test-auth
On a Windows machine where logon user credentials are not accepted on the server the user may add a credential record for that server to the Windows Credential Manager. In this case curl fails to authenticate on the server:
curl -v -u : --ntlm remote-server/test-auth
While on both machines Negotiate method works just fine.
curl -v -u : --negotiate localhost/test-auth
curl -v -u : --negotiate remote-server/test-auth
I expected the following
Both Negotiate and NTLM methods should work similarly, i.e. NTLM method should work when either logon user creds are accepted on the server, or there is a record for the server in Windows Credential Manager.
The solution is to provide host as an SPN to
Microsoft Windows [Version 6.1.7601]
So if I understand correctly, if we pass the SPN to InitializeSecurityContext() and there are saved credentials to this target host in Windows-Credential-Manager, then these credentials would be prefered over logon credentials, right? did you test indeed passing the SPN?
Assuming this is the prefered way, and given we already get this behavior in spnego (where we must pass the target), I think it would be ok to change as you have suggested.
Hi, @frenche .
However I did not figure out the exact requirements for the form of SPN, i.e. is the
So I found out how it works even further.
so if a record exists in the Credential Manager for the FQDN (e.g.
It sound a bit strange from security perspectives that SSPI trusts the server to tell it what credentials to use from cred-manager.
I'd say that would be more of a reason to specify the target host to SSPI as suggested.
It may be unclear from my previous message, but you assumed absolutely correct that domain name from type 2 NTLM message is used to find credentials only if the SPN provided in the
Anyway I would be super happy if this is fixed in the upcoming release with my changes or by any other means.