Open peternewman opened 7 years ago
My workaround was to switch from using the connection IDs, which appear to be changing during the connection (note how they are getting reused KA=KeepAlive count, but they aren't being kept alive for long enough).
Instead I switched to the remote IP and remote port and used these as the cache key instead, which should only exist for a similar length of time to the connection ID I'd believe and should still be unique to that machine/connection.
I don't really understand why the connection ID isn't working, although I half wonder if it's something up with my Apache config or Ubuntu's version of Apache 2.4.
What exactly you've to fix the problem for you? Could you post the config you've changed made this setup running? Thx!
Hi @prodigy7 ,
So did you hit the same issue? What OS, Apache version etc were you using?
Sorry, I thought I'd committed my changes. I've just done so here: https://github.com/Legrandin/PyAuthenNTLM2/compare/master...peternewman:apache2.4-fix
When I get a chance I'll try and gather together all the other Apache 2.4 fixes I'm using and open a PR.
In our setup (Apache 2.4.25 on Debian Stretch) I was able to fix this error by switching Apache from mpm_event to mpm_worker. So without @peternewman 's fix.
That sounds like a plausible explanation for the issues I was seeing and why it was only affecting some of us etc.
apache2 2.4.18-2ubuntu3.1 libapache2-mod-python 3.3.1-11ubuntu2 python-pyauthenntlm2 2.2-300117
Similar to https://github.com/Legrandin/PyAuthenNTLM2/issues/12 I was seeing "Unexpected NTLM message Type 3 in new connection", the connection ID seemed to increment before the full NTLM handshake had completed. I've just realised I was using an internal redirect from / to /index.cgi, but this seems unlikely to have broken it.
Where PDC is 192.168.0.1 aka TESTDC.TESTDOMAIN.COM BDC is 192.168.0.2 aka TESTDC2.TESTDOMAIN.COM
Client machine is 192.168.0.10
Apache config:
Before (with PDC deliberately misconfigured to see some logging):
With more logging:
With even more logging:
With workaround: