Retry with NTLM if Negotiate fails

[mavxg]

Some servers with mis-configured SPN cause Negotiate handshake to fail. Web browsers all make a successful connection anyway because they retry with NTLM after the Negotiate handshake fails.

Could the code be updated to follow the same fallback path? Something like the following:

def _response_hook(self, r, **kwargs):
    if r.status_code == 401:
        scheme = 'Negotiate'
        if scheme.lower() in r.headers.get('WWW-Authenticate', '').lower():
            response = self._retry_using_http_Negotiate_auth(r, scheme, kwargs)
            if response.status_code != 401:
                return response
        scheme = 'NTLM'
        if scheme.lower() in r.headers.get('WWW-Authenticate', '').lower():
            return self._retry_using_http_Negotiate_auth(r, scheme, kwargs)

Might need extra thought as with a supplied username and incorrect password this might cause an account lock out twice as fast.

[michael-o]

In my opinion, a library should not try to fix problem setups on the wrong end since the actual issue is never fixed.

[mavxg]

@michael-o Agreed, if you are in full control of the setup, and it has a problem, you should fix the problem.

But what about robustness?

If you build a system to assume every server, every piece of infrastructure, and every other component, will work perfectly 100% of the time, you should expect your system to be fragile. People make mistakes.

The reason the internet works so well is that it assumes, by design, some of it will be broken, most of the time (see Postel's law).

In this case, an infrastructure team made a minor change to a load balancer and changed name resolution as a side effect. Web browsers, PowerShell scripts, dotnet applications, JavaScript clients, and even python using legacy win32com api calls, all carried on connecting to the services without any problems. Scripts built with this library, well they stopped working for the 2 days it took to convince infrastructure they had a problem, and then fix that problem.

btw. I put this issue in after the configuration was already fixed. I just remember seeing a similar issue before, and I expect to see it again. I would prefer next time to not find the issue by having all my scripts stop working.

Choose robustness.

[michael-o]

I partially agree with you, but I think there are few conceptions:

• You aren't on the internet, you are in a fully controlled environment, although you cannot control it, but you can reach out
• Robustness applies to temporary conditions: network, etc.

Moreover, if there would be this hack, you'd never notice the faulty setup in your network.

[mavxg]

Robustness is the ability of a system to continue working, as expected, despite ANY adverse conditions - including faulty network config.

I assume very few people using this library are building software with the purpose of helping their infrastructure team find bugs. While it is a nice side effect, it is a few orders of magnitude less valuable than productivity lost from none of the systems working for 2 days.

The suggested "hack" is the same mechanism used by every other comparable system I could test (Edge, Chrome, .NET (C# and PowerShell), and Python using win32com.client.Dispatch('WinHTTP.WinHTTPRequest.5.1')). They all try each supported authentication mechanism in turn, and only return a final 401 when all failed. None of them just give up when the first method fails.