jborean93 / pyspnego

Python SPNEGO authentication library
MIT License
52 stars 11 forks source link

NTLM challenge response not accepted #89

Open aa403 opened 2 weeks ago

aa403 commented 2 weeks ago

Hi - I'm running a fastapi server which needs to validate ntlm auth from a client.

using spnego.server (set up like the unittests show), the initial negotiation works fine, but when the client (in this case google chrome) returns the challenge response (the second hash), the server.step call throws the following error:

"Input message was not a NTLM Negotiate message"

any ideas?

jborean93 commented 2 weeks ago

Can you dump the authentication token's bytes? It sounds like potentially it's a SPNEGO/Negotiate wrapped NTLM token rather than a pure NTLM one (starts with NTLMSSP\x00).

aa403 commented 2 weeks ago

Thanks for the prompt response; yeh, it does start w NTLMSSP\x00

how should i be initializing the spenego.server ?

jborean93 commented 2 weeks ago

If it's pure NTLM then you mostly just set server = spnego.server(protocol="ntlm"), you probably also want to set the hostname to the hostname you are using as a target SPN but NTLM use of SPNs is pretty minimal compared to Kerberos.

You can use this library to try and format the token with python -m spnego --token $TOKEN where $TOKEN is the base64 or hex encoded value of the token bytes. The message seems to indicate that the negotiate message was never given to the server as it's trying to unpack the negotiate message. Are you creating a new server object or re-using the one that generated the challenge message?

aa403 commented 2 weeks ago

so i was creating a new server each time; which probably meant it was losing state.

i then did some stuff in session to allow the server to "catch up" when the challenge response came in, meaning that the accept step could start

but then it was complaining about an NTLM creds file not being there; which after adding, looks like is being traded as the overall creds store ... rather than passing thru to AD...

what am I missing :)

jborean93 commented 2 weeks ago

This library on non-Windows has no integration with AD, it has limited acceptor support and for NTLM means you need to provide the cred store. For Windows it can use SSPI altogether which is the Windows equivalent to GSSAPI and has the ability to authenticate local and AD accounts like any other Windows service.

aa403 commented 2 weeks ago

ok got it ... so for a linux system best bet would be to use gssapi ?

jborean93 commented 2 weeks ago

If you want to use proper authentication yes, the trouble is it's a lot harder to work with NTLM authentication. It's an older protocol and there's limited support for NTLM on GSSAPI.

aa403 commented 2 weeks ago

ok, thanks for your help and the prompt responses!