[squid-users] Re: Question about changing authentication in a http session.
Hi Amos, I tried 3.4.3 and it didn't change. I attach a access.log cache.log and a wireshark capture file. You will see the first Negotiate/NTLM authentication attempt is declined and the Negotiate/Kerberos attempt is not processed by the auth helper ( I assume because it is on the same session as I get successful authenticated when I wait a bit ) Is there a way in the dispatcher to check the auth method has changed despite being the same session ? I know it is more difficult for Negotiate/NTLM to Negotiate/Kerberos as you need to check the token. Thank you Markus Amos Jeffries wrote in message news:611078a64927db3a27e7bee192469...@treenet.co.nz... On 2014-02-03 12:06, Markus Moeller wrote: Hi, I am testing authenticating a XP machine with Kerberos, but the client tries Negotiate/NTLM first after which squid does not accept the change to Negotiate/Kerberos anymore. If you look at the wireshark log you authentication attempts at 20:44:20 for Negotiate/NTLM and at 22:44:30 the client changed to Negotiate/Kerberos, but the cache.log file does not get any request after the 20:44:20 NTLM request. I can only see the deny entries in the access.log. I use squid 3.4.1 from the repository from 24 Dec 2013. Is this an expected behavious ? Depends. Is this renegotiation being done on the same connection as NTLM was begun? (sorry cant view the packet trace right now). Do you get the same results with 3.4.3? It could be related to the helper decoding or external ACL loops bugs fixed in 3.4.2 and 3.4.3. Amos squid_2.pcapng.gz Description: GNU Zip compressed data 2014/02/04 20:21:07| negotiate_wrapper: Got 'YR TlRMTVNTUAABB4IIogAFASgKDw==' from squid (length: 59). 2014/02/04 20:21:07| negotiate_wrapper: Decode 'TlRMTVNTUAABB4IIogAFASgKDw==' (decoded length: 40). 2014/02/04 20:21:07| negotiate_wrapper: received type 1 NTLM token 2014/02/04 20:21:07| negotiate_wrapper: Return 'TT TlRMTVNTUAACEgASADgFgomi2qilCL+tNc0AAHQAdABKBgEAAA9X AEkATgAyADAAMAAzAFIAMgACABIAVwBJAE4AMgAwADAAMwBSADIAAQAUAE8AUABFAE4AUwBVAFMA RQAxADIABAASAHMAdQBzAGUALgBoAG8AbQBlAAMAKABvAHAAZQBuAHMAdQBzAGUAMQAyAC4AcwB1 AHMAZQAuAGgAbwBtAGUAAA== ' 2014/02/04 20:21:07| negotiate_wrapper: Got 'KK TlRMTVNTUAADGAAYAHCkAKQAiAwADABIEAAQAFQMAAwAZAAs AQAABYKIogUBKAoPVwBJAE4AWABQADIAbQBhAHIAawB1AHMALQBhAFcASQBOAFgAUAAyAHVS S4C7nuJuNgDAHmZeeARLJqSkShKttNOsqLu+uWlYbBOzF8zexA4BAQAAABjYFaLmIc8BSyak pEoSrbQAAgASAFcASQBOADIAMAAwADMAUgAyAAEAFABPAFAARQBOAFMAVQBTAEUAMQAyAAQA EgBzAHUAcwBlAC4AaABvAG0AZQADACgAbwBwAGUAbgBzAHUAcwBlADEAMgAuAHMAdQBzAGUALgBo AG8AbQBl' from squid (length: 403). 2014/02/04 20:21:07| negotiate_wrapper: Decode 'TlRMTVNTUAADGAAYAHCkAKQAiAwADABIEAAQAFQMAAwAZAA sAQAABYKIogUBKAoPVwBJAE4AWABQADIAbQBhAHIAawB1AHMALQBhAFcASQBOAFgAUAAyAHV SS4C7nuJuNgDAHmZeeARLJqSkShKttNOsqLu+uWlYbBOzF8zexA4BAQAAABjYFaLmIc8BSya kpEoSrbQAAgASAFcASQBOADIAMAAwADMAUgAyAAEAFABPAFAARQBOAFMAVQBTAEUAMQAyAAQ AEgBzAHUAcwBlAC4AaABvAG0AZQADACgAbwBwAGUAbgBzAHUAcwBlADEAMgAuAHMAdQBzAGUALgB oAG8AbQBl' (decoded length: 300). 2014/02/04 20:21:07| negotiate_wrapper: received type 3 NTLM token 2014/02/04 20:21:07| negotiate_wrapper: Return 'NA = NT_STATUS_NO_SUCH_USER 04/Feb/2014:20:21:07 + 0 192.168.1.5 TCP_DENIED/407 4457 GET http://google.com/ - HIER_NONE/- text/html 04/Feb/2014:20:21:07 + 2 192.168.1.5 TCP_DENIED/407 4791 GET http://google.com/ - HIER_NONE/- text/html 04/Feb/2014:20:21:07 + 4 192.168.1.5 TCP_DENIED/407 4900 GET http://google.com/ - HIER_NONE/- text/html 04/Feb/2014:20:21:19 + 0 192.168.1.5 TCP_DENIED/407 5394 GET http://google.com/ - HIER_NONE/- text/html 04/Feb/2014:20:21:21 + 1 192.168.1.5 TCP_DENIED/407 5414 GET http://google.com/ - HIER_NONE/- text/html 04/Feb/2014:20:21:22 + 2 192.168.1.5 TCP_DENIED/407 5404 GET http://google.com/ - HIER_NONE/- text/html 04/Feb/2014:20:21:22 + 0 192.168.1.5 TCP_DENIED/407 4091 GET http://www.squid-cache.org/Artwork/SN.png - HIER_NONE/- text/html
Re: [squid-users] Re: Question about changing authentication in a http session.
On 2014-02-05 10:06, Markus Moeller wrote: Hi Amos, I tried 3.4.3 and it didn't change. I attach a access.log cache.log and a wireshark capture file. You will see the first Negotiate/NTLM authentication attempt is declined and the Negotiate/Kerberos attempt is not processed by the auth helper ( I assume because it is on the same session as I get successful authenticated when I wait a bit ) Is there a way in the dispatcher to check the auth method has changed despite being the same session ? I know it is more difficult for Negotiate/NTLM to Negotiate/Kerberos as you need to check the token. Tricky. Squid is only concerned with the scheme label to identify the difference in the current code. For the Negotiate that does not change naturally. I think even looking deeper than the token type will be necessary. What I see in that cache.log trace is a normal NTLM sequence of type 1, type 2, type 3 ... except the type 1 2 are NTLM and the type 3 format appears to be in Kerberos or maybe NTLMv2 with security extensions. If this is solvable by Squid then it is likely also solvable in the wrapper helper and best experimented in that simpler code. Amos Thank you Markus Amos Jeffries wrote in message news:611078a64927db3a27e7bee192469...@treenet.co.nz... On 2014-02-03 12:06, Markus Moeller wrote: Hi, I am testing authenticating a XP machine with Kerberos, but the client tries Negotiate/NTLM first after which squid does not accept the change to Negotiate/Kerberos anymore. If you look at the wireshark log you authentication attempts at 20:44:20 for Negotiate/NTLM and at 22:44:30 the client changed to Negotiate/Kerberos, but the cache.log file does not get any request after the 20:44:20 NTLM request. I can only see the deny entries in the access.log. I use squid 3.4.1 from the repository from 24 Dec 2013. Is this an expected behavious ? Depends. Is this renegotiation being done on the same connection as NTLM was begun? (sorry cant view the packet trace right now). Do you get the same results with 3.4.3? It could be related to the helper decoding or external ACL loops bugs fixed in 3.4.2 and 3.4.3. Amos
[squid-users] Re: Question about changing authentication in a http session.
Hi Amos, Amos Jeffries wrote in message news:b596a7df3abbf894689873c1a4bda...@treenet.coz... On 2014-02-05 10:06, Markus Moeller wrote: Hi Amos, I tried 3.4.3 and it didn't change. I attach a access.log cache.log and a wireshark capture file. You will see the first Negotiate/NTLM authentication attempt is declined and the Negotiate/Kerberos attempt is not processed by the auth helper ( I assume because it is on the same session as I get successful authenticated when I wait a bit ) Is there a way in the dispatcher to check the auth method has changed despite being the same session ? I know it is more difficult for Negotiate/NTLM to Negotiate/Kerberos as you need to check the token. Tricky. Squid is only concerned with the scheme label to identify the difference in the current code. For the Negotiate that does not change naturally. I think even looking deeper than the token type will be necessary. What I see in that cache.log trace is a normal NTLM sequence of type 1, type 2, type 3 ... except the type 1 2 are NTLM and the type 3 format appears to be in Kerberos or maybe NTLMv2 with security extensions. I am pretty sure it is NTLM not Kerberos. ( The first characters in the decoded string are NTLM ) If this is solvable by Squid then it is likely also solvable in the wrapper helper and best experimented in that simpler code. It would be possible in the wrapper if the wrapper would get the next auth request. As far I could see from the log the wrapper did not get the next auth token. I have the impression that the dispatcher has marked the session as finished for authentication and does not send anything further to the authentication wrapper. Amos
