Re: [squid-users] squid 5.9 Kerberos authentication problem

2023-10-10 Thread Ludovit Koren 



Hi,

I am sorry to bother you once again, but I sent you and described just
the problem you were talking about and did not get any answer.

In the logged output you can see several 407 and afterwards 200 error
code just as you described, that the state you worry about.

Is there any solution to this?

Regards,

lk


>>>>> Amos Jeffries  writes:

> On 5/10/23 19:30, Ludovit Koren wrote:
>> Hello,
>> I am using squid 5.9 with AD Kerberos authentication and could not
>> solve
>> the problem of sending incorrect request according to client
>> configuration followed by the correct one, i.e.:
>> 1695983264.808  0 x.y.z TCP_DENIED/407 4135 CONNECT
>> th.bing.com:443 - HIER_NONE/- text/html
>> 1695983264.834 21 x.y.z TCP_TUNNEL/200 6080 CONNECT th.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
>> 

> This looks fine to me. The first request is sent without credentials,
> then the second contains the correct ones using the correct 
> authentication scheme.

ok, this is little bit longer output:

1695983167.151  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.154  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.155  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.155  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.163  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.837  0 x.y.z TCP_DENIED/407 4135 CONNECT th.bing.com:443 - 
HIER_NONE/- text/html
1695983167.842  1 x.y.z TCP_DENIED/407 4135 CONNECT th.bing.com:443 - 
HIER_NONE/- text/html
1695983167.873 27 x.y.z TCP_TUNNEL/200 6080 CONNECT th.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983168.440  0 x.y.z TCP_DENIED/407 4139 CONNECT www.bing.com:443 - 
HIER_NONE/- text/html
1695983181.337 103937 x.y.z TCP_TUNNEL/200 7562 CONNECT 
browser.events.data.msn.com:443 name@domain FIRSTUP_PARENT/squid-parent -
1695983181.367 15 x.y.z TCP_DENIED/407 4254 CONNECT assets.msn.com:443 - 
HIER_NONE/- text/html
1695983181.367 28 x.y.z TCP_DENIED/407 4254 CONNECT assets.msn.com:443 - 
HIER_NONE/- text/html
1695983181.504 24 x.y.z TCP_DENIED/407 4306 CONNECT 
browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.504 26 x.y.z TCP_DENIED/407 4306 CONNECT 
browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.559  0 x.y.z TCP_DENIED/407 4306 CONNECT 
browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.662  5 x.y.z TCP_DENIED/407 4234 CONNECT c.msn.com:443 - 
HIER_NONE/- text/html
1695983181.847  5 x.y.z TCP_DENIED/407 4238 CONNECT c.bing.com:443 - 
HIER_NONE/- text/html
1695983182.031 12 x.y.z TCP_DENIED/407 4242 CONNECT th.bing.com:443 - 
HIER_NONE/- text/html
1695983194.404  0 x.y.z TCP_DENIED/407 3952 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983200.151  0 x.y.z TCP_DENIED/407 3952 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983201.409  20034 x.y.z TCP_TUNNEL/200 4166 CONNECT assets.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983202.682 131076 x.y.z TCP_TUNNEL/200 6868 CONNECT assets.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983205.701  0 x.y.z TCP_DENIED/407 3952 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983221.409  0 x.y.z TCP_DENIED/407 3952 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983233.498   5002 x.y.z TCP_DENIED/407 4139 CONNECT www.bing.com:443 - 
HIER_NONE/- text/html
1695983241.717  77946 x.y.z TCP_TUNNEL/200 7596 CONNECT edge.microsoft.com:443 
- FIRSTUP_PARENT/squid-parent -
1695983241.717  76955 x.y.z TCP_TUNNEL/200 58182 CONNECT ntp.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.717  76795 x.y.z TCP_TUNNEL/200 8279 CONNECT api.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  76731 x.y.z TCP_TUNNEL/200 110495 CONNECT assets.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  74275 x.y.z TCP_TUNNEL/200 6756 CONNECT edge.microsoft.com:443 
- FIRSTUP_PARENT/squid-parent -
1695983241.718  76590 x.y.z TCP_TUNNEL/200 42623 CONNECT assets.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  73876 x.y.z TCP_TUNNEL/200 95997 CONNECT th.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  74645 x.y.z TCP_TUNNEL/200 18121 CONNECT business.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  18104 x.y.z TCP_TUNNEL/200 59080 CONNECT edge.microsoft.com:443 
- FIRSTUP_PARENT/squid-parent -
1695983241.719  18234 x.y.z TCP_TUNNEL/200 7147 CONNECT go.microsoft.com:443 - 
FIRSTUP_PARENT/squid-parent -
1695983241.

Re: [squid-users] squid 5.9 Kerberos authentication problem

2023-10-05 Thread Ludovit Koren 
>>>>> Amos Jeffries  writes:

> On 5/10/23 19:30, Ludovit Koren wrote:
>> Hello,
>> I am using squid 5.9 with AD Kerberos authentication and could not
>> solve
>> the problem of sending incorrect request according to client
>> configuration followed by the correct one, i.e.:
>> 1695983264.808  0 x.y.z TCP_DENIED/407 4135 CONNECT
>> th.bing.com:443 - HIER_NONE/- text/html
>> 1695983264.834 21 x.y.z TCP_TUNNEL/200 6080 CONNECT th.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
>> 

> This looks fine to me. The first request is sent without credentials,
> then the second contains the correct ones using the correct 
> authentication scheme.

ok, this is little bit longer output:

1695983167.151  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.154  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.155  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.155  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.163  0 x.y.z TCP_DENIED/407 4179 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983167.837  0 x.y.z TCP_DENIED/407 4135 CONNECT th.bing.com:443 - 
HIER_NONE/- text/html
1695983167.842  1 x.y.z TCP_DENIED/407 4135 CONNECT th.bing.com:443 - 
HIER_NONE/- text/html
1695983167.873 27 x.y.z TCP_TUNNEL/200 6080 CONNECT th.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983168.440  0 x.y.z TCP_DENIED/407 4139 CONNECT www.bing.com:443 - 
HIER_NONE/- text/html
1695983181.337 103937 x.y.z TCP_TUNNEL/200 7562 CONNECT 
browser.events.data.msn.com:443 name@domain FIRSTUP_PARENT/squid-parent -
1695983181.367 15 x.y.z TCP_DENIED/407 4254 CONNECT assets.msn.com:443 - 
HIER_NONE/- text/html
1695983181.367 28 x.y.z TCP_DENIED/407 4254 CONNECT assets.msn.com:443 - 
HIER_NONE/- text/html
1695983181.504 24 x.y.z TCP_DENIED/407 4306 CONNECT 
browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.504 26 x.y.z TCP_DENIED/407 4306 CONNECT 
browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.559  0 x.y.z TCP_DENIED/407 4306 CONNECT 
browser.events.data.msn.com:443 - HIER_NONE/- text/html
1695983181.662  5 x.y.z TCP_DENIED/407 4234 CONNECT c.msn.com:443 - 
HIER_NONE/- text/html
1695983181.847  5 x.y.z TCP_DENIED/407 4238 CONNECT c.bing.com:443 - 
HIER_NONE/- text/html
1695983182.031 12 x.y.z TCP_DENIED/407 4242 CONNECT th.bing.com:443 - 
HIER_NONE/- text/html
1695983194.404  0 x.y.z TCP_DENIED/407 3952 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983200.151  0 x.y.z TCP_DENIED/407 3952 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983201.409  20034 x.y.z TCP_TUNNEL/200 4166 CONNECT assets.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983202.682 131076 x.y.z TCP_TUNNEL/200 6868 CONNECT assets.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983205.701  0 x.y.z TCP_DENIED/407 3952 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983221.409  0 x.y.z TCP_DENIED/407 3952 CONNECT 
gw1.ris.datacentrum.sk:443 - HIER_NONE/- text/html
1695983233.498   5002 x.y.z TCP_DENIED/407 4139 CONNECT www.bing.com:443 - 
HIER_NONE/- text/html
1695983241.717  77946 x.y.z TCP_TUNNEL/200 7596 CONNECT edge.microsoft.com:443 
- FIRSTUP_PARENT/squid-parent -
1695983241.717  76955 x.y.z TCP_TUNNEL/200 58182 CONNECT ntp.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.717  76795 x.y.z TCP_TUNNEL/200 8279 CONNECT api.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  76731 x.y.z TCP_TUNNEL/200 110495 CONNECT assets.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  74275 x.y.z TCP_TUNNEL/200 6756 CONNECT edge.microsoft.com:443 
- FIRSTUP_PARENT/squid-parent -
1695983241.718  76590 x.y.z TCP_TUNNEL/200 42623 CONNECT assets.msn.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  73876 x.y.z TCP_TUNNEL/200 95997 CONNECT th.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  74645 x.y.z TCP_TUNNEL/200 18121 CONNECT business.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.718  18104 x.y.z TCP_TUNNEL/200 59080 CONNECT edge.microsoft.com:443 
- FIRSTUP_PARENT/squid-parent -
1695983241.719  18234 x.y.z TCP_TUNNEL/200 7147 CONNECT go.microsoft.com:443 - 
FIRSTUP_PARENT/squid-parent -
1695983241.719  76826 x.y.z TCP_TUNNEL/200 7443 CONNECT deff.nelreports.net:443 
name@domain FIRSTUP_PARENT/squid-parent -
1695983241.719  74620 x.y.z TCP_TUNNEL/200 8392 CONNECT 
gw1.ris.datacentrum.sk:443 name@domain FIRSTUP_PARENT/squid-parent -
1695983241.719  74562 x.y.z TCP_TUNNEL/200 4477 CONNECT 
gw1.ris.datacentrum.sk:443 nam

[squid-users] squid 5.9 Kerberos authentication problem

2023-10-05 Thread Ludovit Koren 


Hello,

I am using squid 5.9 with AD Kerberos authentication and could not solve
the problem of sending incorrect request according to client
configuration followed by the correct one, i.e.:

1695983264.808  0 x.y.z TCP_DENIED/407 4135 CONNECT th.bing.com:443 - 
HIER_NONE/- text/html
1695983264.834 21 x.y.z TCP_TUNNEL/200 6080 CONNECT th.bing.com:443 
name@domain FIRSTUP_PARENT/squid-parent -

There are some web servers which are not working even when the correct
request follows afterwards.

Anyone experienced this behavior? Any specific settings of Windows
clients?


Thank you very much.

Regards,

lk

___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid exiting on signal 6

2022-10-12 Thread Ludovit Koren 
>>>>> Amos Jeffries  writes:

> On 12/10/22 21:12, Ludovit Koren wrote:
>> Hi,
>> I am running squid-5.7 on FreeBSD 12.3-STABLE r371879. Occasionally
>> I
>> get the following error:
>> 

>> #3  0x00080111fcb1 in __assert (func=, 
file=, line=, failedexpr=) at 
/usr/src/lib/libc/gen/assert.c:51
>> #4  0x00698fcd in Ip::Address::getAddrInfo (this=0x861c04588, 
dst=, force=0) at Address.cc:663
>> #5  0x0068b732 in comm_openex (sock_type=sock_type@entry=1, 
proto=proto@entry=6, addr=..., flags=1, note=0x85ce42dc0 
"[fe80::21f:29ff:fe28:7017]") at comm.cc:347
> ...

>> The squid is compiled without IPv6 option, so I do not understand
>> why it
>> tries to reach IPv6 address.
>> 

> A client is requiring connection to an IPv6 server. But Squid cannot
> convert that IPv6 address or use on an IPv4-only network. Lack of IPv6 
> support also forbids IPv6 failover handling being used.

So the solution is to reenable IPv6 in the squid, as well as in the OS
network stack? Am I right?

Thank you.

Regards,

lk
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] squid exiting on signal 6

2022-10-12 Thread Ludovit Koren 


Hi,

I am running squid-5.7 on FreeBSD 12.3-STABLE r371879. Occasionally I
get the following error:

Oct 12 09:40:59 x kernel: pid 88291 (squid), jid 0, uid 100: exited on 
signal 6 (core dumped)
Oct 12 09:40:59 x squid[76820]: Squid Parent: squid-1 process 88291 exited 
due to signal 6 with status 0
Oct 12 09:40:59 x squid[76820]: Squid Parent: (squid-1) process 89357 
started

>From backtrace I get:

gdb /usr/local/sbin/squid squid.core 
GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD]
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.3".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/squid...
[New LWP 102541]
Core was generated by `(squid-1) --kid squid-1 -f 
/usr/local/etc/squid/squid.conf'.
Program terminated with signal SIGABRT, Aborted.
Sent by thr_kill() from pid 88291 and user 100.
#0  thr_kill () at thr_kill.S:3
3   RSYSCALL(thr_kill)
(gdb) bt
#0  thr_kill () at thr_kill.S:3
#1  0x00080112fd44 in __raise (s=s@entry=6) at 
/usr/src/lib/libc/gen/raise.c:52
#2  0x0008010a8409 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3  0x00080111fcb1 in __assert (func=, file=, 
line=, failedexpr=) at 
/usr/src/lib/libc/gen/assert.c:51
#4  0x00698fcd in Ip::Address::getAddrInfo (this=0x861c04588, 
dst=, force=0) at Address.cc:663
#5  0x0068b732 in comm_openex (sock_type=sock_type@entry=1, 
proto=proto@entry=6, addr=..., flags=1, note=0x85ce42dc0 
"[fe80::21f:29ff:fe28:7017]") at comm.cc:347
#6  0x006dcdb9 in Comm::ConnOpener::createFd 
(this=this@entry=0x85e66b8b8) at ConnOpener.cc:288
#7  0x006dcb72 in Comm::ConnOpener::start (this=0x85e66b8b8) at 
ConnOpener.cc:261
#8  0x00682294 in JobDialer::dial (this=0x85390c798, 
call=...) at ../../src/base/AsyncJobCalls.h:175
#9  0x0067e9bb in AsyncCall::make (this=0x85390c760) at AsyncCall.cc:44
#10 0x0067fa91 in AsyncCallQueue::fireNext (this=, 
this@entry=0x801c00740) at AsyncCallQueue.cc:60
#11 0x0067f6e8 in AsyncCallQueue::fire (this=0x801c00740) at 
AsyncCallQueue.cc:43
#12 0x004914f2 in EventLoop::dispatchCalls (this=) at 
EventLoop.cc:144
#13 EventLoop::runOnce (this=this@entry=0x7fffe9d0) at EventLoop.cc:121
#14 0x00491418 in EventLoop::run (this=0x7fffe9d0) at 
EventLoop.cc:83
#15 0x005792a8 in SquidMain (argc=, argc@entry=5, 
argv=, argv@entry=0x7fffeab8) at main.cc:1719
#16 0x005786a0 in SquidMainSafe (argc=102541, argv=0x6) at main.cc:1406
#17 main (argc=102541, argv=0x6) at main.cc:1394
(gdb) 


The squid is compiled without IPv6 option, so I do not understand why it
tries to reach IPv6 address.

Please, can anybody help, why I am getting signal 6 and core dump?

Thank you very much.

Regards,

lk
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Kerberos authentication problem - squid 3.4.11

2015-02-14 Thread Ludovit Koren 
 Markus Moeller hua...@moeller.plus.com writes:

 It could be the new AD server  is setup to be backward  compatible
 meaning it use RC4 despite being able to use AES.  I suggest you crate
 an additional keytab entry for RC4.  How did you create the keytab ?

Now it seems to work:


# /usr/local/libexec/squid/negotiate_kerberos_auth_test proxy.mdpt.local | awk 
'{sub(/Token:/,YR); print $0}END{print QQ}' | 
/usr/local/libexec/squid/negotiate_kerberos_auth -r -s HTTP/proxy.mdpt.local
AF oRQwEqADCgEAoQsGCSqGSIb3EgECAg== HTTP/proxy.mdpt.local
BH quit command

respectively with debug output

# /usr/local/libexec/squid/negotiate_kerberos_auth_test proxy.mdpt.local | awk 
'{sub(/Token:/,YR); print $0}END{print QQ}' | 
/usr/local/libexec/squid/negotiate_kerberos_auth -d -r -s HTTP/proxy.mdpt.local
negotiate_kerberos_auth.cc(212): pid=59316 :2015/02/14 09:40:23| 
negotiate_kerberos_auth: INFO: Starting version 3.0.4sq
negotiate_kerberos_auth.cc(258): pid=59316 :2015/02/14 09:40:23| 
negotiate_kerberos_auth: DEBUG: Got 'YR 
YIIFkgYGKwYBBQUCoIIFhjCCBYKgDTALBgkqhkiG9xIBAgKiggVvBIIFa2CCBWcGCSqGSIb3EgECAgEAboIFVjCCBVKgAwIBBaEDAgEOogcDBQAAo4IEQGGCBDwwggQ4oAMCAQWhDBsKTURQVC5MT0NBTKIjMCGgAwIBA6EaMBgbBEhUVFAbEHByb3h5Lm1kcHQubG9jYWyjggP8MIID+KADAgEXoQMCAQaiggPqBIID5sVhPZfpC5bIQPSFoRRkg/yI1a3e+rJhYMx9v8sahJtT0prtSF715Q1TAqiXKDZJ479BKKPA27BL63p/mwvu7bf4gznZNTZLFIfHYU/ImK//RrvgkDv1uFSqm/skfzEECQBth4rxozQMfqLgmADCvAdEQVBIeG3D/QlhJ6LNdk4V4f0RBPr8zsagJ7529iSJK0otclE8McAg/5ZB4uA4L9PW6db+UOE3wR1LXK1w40dJkh3YRZX7SjZTEEpT003IRCulEq+fqIfLOPbL8+bbTrECYvvShaMuZF+RAlRZTrxS8P4KPk1f7muLEvA5/EvsGKXmtyTeytd9eRdfAhw5LBuUbwjDsuoliD1ARTPXL1syTtUy4CgJUNu6a6GGgh3uBF2zdDu7cY/4wtU1do3DJRq2NFzjQxcc4TzT64/HjYR+pi2MgchXJBbD3J79AQmKAvtO2B0xI9w/qSCH2uLoPwwzGEXGvr4DsXNgBbkaandw0UtpUyyfd6Gk313mc58dc+G10J3xPhsUOz9a1EOmmETquEPLgjkfpUQY6/MTRbWk/aRl9l681664Ywb6gp9mJioNfz6cxcF7C7fIGKrvBDSyZCBEGH+HOBfBr0REYkqKOqw1xVg0LfYYX4/6pE9ZfJMk3XTHmWKDa+EIahs5ibMsfi+MBx5iEOva3SC8s+rEZyWiG3soowE3U2BCgkGihRAI1thGJVUKLMQy3AokSX7xZF/RiYA4C4MdnFbDdCUJ14vNH4gYZs3A15wbbBUe6aUz3hblSHhFM/vjc4+EyMMyhiJLLYJ9wqe+Y2+eAl0H8wErSjb4ivFv8pNUZuGgbtT4buAE4AHYahWn+f/0S0r05T9uV+273KyA56+KZ4tXnbzhMo9ybqSA6B0BYpsEeDvZDYfUfrDyo4fyT/W2Rem+UMvuJ/o5HRrZWiSP45ANGkqLQcOXwjSDPQQUQaytPeClrqUamnZxbD/XsBosKUUbOfvxnQgWOrVbaDwNN8WfQ+Tv1ZQO8tXoDt9RE1fewaKF8cJS9zsbcSuucBsmQGcMHKn035bsEni8JoiWU1g9ieXeqvRTg5nAkf6bzP3rs4awhXTa3if11liCSZojMUi1Q2d/HZ8X9ZJhu2VS6+EVNQ0dlHspnH3nV8GMz5JI0eQuwPfE2rTOcv4vFZldK2+jJVlCOHu/sMW+gojLjoTg4yrMp1RFq9P3JIlo388eoInu94nAjrbcRgX6W/t+tdUMxGs7+xEoVuCwvnl7jbny31QHzSV2B2n5bGH04z0kAzgOfZmUkJyZivOR8fFisBEX69BWAPXuhQaJFhRsA1pHPPASEYcApIH4MIH1oAMCAReige0Eger41GqgKOrnmoPBzgQ+QQQICBbu/8WBFqzn7Cn4vVSrhsU5umcgSpzTIioLSNQWktPeZQRh/ZcPb+gIWZHaP9LvUEeqXbIT0oYTyStS1bgMCl/yfI4WzGpCKhZbd43jShcQB6SOjQlua7V/0dFOpUv+q1LVD//FFl2dIGoKZHXU5NYpf1yl9dX5Cgd4oKlJUyqgXWclIRzPeGl8nJ8oPvi2af9GGPazSF31Cu7jA/fG9mM4Tses4gI3EPBQBgCAThJ7QeNASK0GEXKsoQE2gYcmaQBTOUP0mhMs43vPqCQckoOcK3/l7SsPwg0='
 from squid (length: 1911).
negotiate_kerberos_auth.cc(311): pid=59316 :2015/02/14 09:40:23| 
negotiate_kerberos_auth: DEBUG: Decode 
'YIIFkgYGKwYBBQUCoIIFhjCCBYKgDTALBgkqhkiG9xIBAgKiggVvBIIFa2CCBWcGCSqGSIb3EgECAgEAboIFVjCCBVKgAwIBBaEDAgEOogcDBQAAo4IEQGGCBDwwggQ4oAMCAQWhDBsKTURQVC5MT0NBTKIjMCGgAwIBA6EaMBgbBEhUVFAbEHByb3h5Lm1kcHQubG9jYWyjggP8MIID+KADAgEXoQMCAQaiggPqBIID5sVhPZfpC5bIQPSFoRRkg/yI1a3e+rJhYMx9v8sahJtT0prtSF715Q1TAqiXKDZJ479BKKPA27BL63p/mwvu7bf4gznZNTZLFIfHYU/ImK//RrvgkDv1uFSqm/skfzEECQBth4rxozQMfqLgmADCvAdEQVBIeG3D/QlhJ6LNdk4V4f0RBPr8zsagJ7529iSJK0otclE8McAg/5ZB4uA4L9PW6db+UOE3wR1LXK1w40dJkh3YRZX7SjZTEEpT003IRCulEq+fqIfLOPbL8+bbTrECYvvShaMuZF+RAlRZTrxS8P4KPk1f7muLEvA5/EvsGKXmtyTeytd9eRdfAhw5LBuUbwjDsuoliD1ARTPXL1syTtUy4CgJUNu6a6GGgh3uBF2zdDu7cY/4wtU1do3DJRq2NFzjQxcc4TzT64/HjYR+pi2MgchXJBbD3J79AQmKAvtO2B0xI9w/qSCH2uLoPwwzGEXGvr4DsXNgBbkaandw0UtpUyyfd6Gk313mc58dc+G10J3xPhsUOz9a1EOmmETquEPLgjkfpUQY6/MTRbWk/aRl9l681664Ywb6gp9mJioNfz6cxcF7C7fIGKrvBDSyZCBEGH+HOBfBr0REYkqKOqw1xVg0LfYYX4/6pE9ZfJMk3XTHmWKDa+EIahs5ibMsfi+MBx5iEOva3SC8s+rEZyWiG3soowE3U2BCgkGihRAI1thGJVUKLMQy3AokSX7xZF/RiYA4C4MdnFbDdCUJ14vNH4gYZs3A15wbbBUe6aUz3hblSHhFM/vjc4+EyMMyhiJLLYJ9wqe+Y2+eAl0H8wErSjb4ivFv8pNUZuGgbtT4buAE4AHYahWn+f/0S0r05T9uV+273KyA56+KZ4tXnbzhMo9ybqSA6B0BYpsEeDvZDYfUfrDyo4fyT/W2Rem+UMvuJ/o5HRrZWiSP45ANGkqLQcOXwjSDPQQUQaytPeClrqUamnZxbD/XsBosKUUbOfvxnQgWOrVbaDwNN8WfQ+Tv1ZQO8tXoDt9RE1fewaKF8cJS9zsbcSuucBsmQGcMHKn035bsEni8JoiWU1g9ieXeqvRTg5nAkf6bzP3rs4awhXTa3if11liCSZojMUi1Q2d/HZ8X9ZJhu2VS6+EVNQ0dlHspnH3nV8GMz5JI0eQuwPfE2rTOcv4vFZldK2+jJVlCOHu/sMW+gojLjoTg4yrMp1RFq9P3JIlo388eoInu94nAjrbcRgX6W/t+tdUMxGs7+xEoVuCwvnl7jbny31QHzSV2B2n5bGH04z0kAzgOfZmUkJyZivOR8fFisBEX69BWAPXuhQaJFhRsA1pHPPASEYcApIH4MIH1oAMCAReige0Eger41GqgKOrnmoPBzgQ+QQQICBbu/8WBFqzn7Cn4vVSrhsU5umcgSpzTIioLSNQWktPeZQRh/ZcPb+gIWZHaP9LvUEeqXbIT0oYTyStS1bgMCl/yfI4WzGpCKhZbd43jShcQB6SOjQlua7V/0dFOpUv+q1LVD//FFl2dIGoKZHXU5NYpf1yl9dX5Cgd4oKlJUyqgXWclIRzPeGl8nJ8oPvi2af9GGPazSF31Cu7jA/fG9mM4Tses4gI3EPBQBgCAThJ7QeNASK0GEXKsoQE2gYcmaQBTOUP0mhMs43vPqCQckoOcK3/l7SsPwg0='

Re: [squid-users] Kerberos authentication problem - squid 3.4.11

2015-02-13 Thread Ludovit Koren 
 Markus Moeller hua...@moeller.plus.com writes:

 It could be the new AD server  is setup to be backward  compatible
 meaning it use RC4 despite being able to use AES.  I suggest you crate
 an additional keytab entry for RC4.  How did you create the keytab ?

It was created with ktpass on AD. The exact switches used I do not
know. I will manage to get keytab with the RC4.

lk
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Kerberos authentication problem - squid 3.4.11

2015-02-11 Thread Ludovit Koren 
 Markus Moeller hua...@moeller.plus.com writes:

 Hi Ludovit,
  Which Kerberos library version do you use ?Is it possible that
 the encryption types don't match ?  I saw in your first email the
 following:

It is standard Heimdal library on FreeBSD:
# kinit --version
kinit (Heimdal 1.5.2)
Copyright 1995-2011 Kungliga Tekniska Högskolan
Send bug-reports to heimdal-b...@h5l.org

FreeBSD 10.1-STABLE #1 r275861

 Your klist shows a HTTP ticket for arcfour

 Server: HTTP/squid1.mdpt.local@MDPT.LOCAL
 Client: HTTP/squid1.mdpt.local@MDPT.LOCAL
 Ticket etype: arcfour-hmac-md5, kvno 8
 Ticket length: 1090
 Auth time:  Feb  9 14:55:18 2015
 Start time: Feb  9 14:55:20 2015
 End time:   Feb 10 00:55:18 2015
 Ticket flags: enc-pa-rep, pre-authent
 Addresses: addressless

 but the keytab has aes128.

 # ktutil -k /etc/krb5.keytab list
 /etc/krb5.keytab:

 Vno  Type Principal  Aliases
  8  aes128-cts-hmac-sha1-96  HTTP/squid1.mdpt.local@MDPT.LOCAL


You are right... I tried to find out how to change it. Is it option on
KDC server? I am not able to find anything relevant. 


lk
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Kerberos authentication problem - squid 3.4.11

2015-02-09 Thread Ludovit Koren 


Hi,

I have setup kerberos according to:

http://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory

# klist 
Credentials cache: FILE:/tmp/krb5cc_0
Principal: HTTP/squid1.mdpt.local@MDPT.LOCAL

  IssuedExpires   Principal
Feb  9 14:55:18 2015  Feb 10 00:55:18 2015  krbtgt/MDPT.LOCAL@MDPT.LOCAL
Feb  9 14:55:20 2015  Feb 10 00:55:18 2015  HTTP/squid1.mdpt.local@MDPT.LOCAL

# klist -v
Credentials cache: FILE:/tmp/krb5cc_0
Principal: HTTP/squid1.mdpt.local@MDPT.LOCAL
Cache version: 4

Server: krbtgt/MDPT.LOCAL@MDPT.LOCAL
Client: HTTP/squid1.mdpt.local@MDPT.LOCAL
Ticket etype: aes256-cts-hmac-sha1-96, kvno 3
Session key: aes128-cts-hmac-sha1-96
Ticket length: 1081
Auth time:  Feb  9 14:55:18 2015
End time:   Feb 10 00:55:18 2015
Ticket flags: enc-pa-rep, pre-authent, initial, forwardable
Addresses: addressless

Server: HTTP/squid1.mdpt.local@MDPT.LOCAL
Client: HTTP/squid1.mdpt.local@MDPT.LOCAL
Ticket etype: arcfour-hmac-md5, kvno 8
Ticket length: 1090
Auth time:  Feb  9 14:55:18 2015
Start time: Feb  9 14:55:20 2015
End time:   Feb 10 00:55:18 2015
Ticket flags: enc-pa-rep, pre-authent
Addresses: addressless



# ktutil -k /etc/krb5.keytab list
/etc/krb5.keytab:

Vno  Type Principal  Aliases
  8  aes128-cts-hmac-sha1-96  HTTP/squid1.mdpt.local@MDPT.LOCAL  


When I try to test it with the following command I get the error:

# /usr/local/libexec/squid/negotiate_kerberos_auth_test squid1.mdpt.local | awk 
'{sub(/Token:/,YR); print $0}END{print QQ}' | 
/usr/local/libexec/squid/negotiate_kerberos_auth -r -s HTTP/squid1.mdpt.local
BH gss_accept_sec_context() failed:  Miscellaneous failure (see text). unknown 
mech-code 2529639093 for mech unknown
BH quit command


I cannot find anything suitable for the error code. Could you, please,
point me in the right direction? Any hint appreciated.

regards,

lk
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Memory Leak Squid 3.4.9 on FreeBSD 10.0 x64

2015-01-08 Thread Ludovit Koren 
 Doug Sampson do...@dawnsign.com writes:

 Hi,
 
 I have the similar problem on FreeBSD 10.1-STABLE #1 r275861 with
 squid-3.4.10. I also applied MEMPOOLS=1 when starting squid. I
 experience the process slowing down and unacceptable performance.
 
 Squid is configured to use kerberos and ntlm authentication and lap
 group authentication. other settings:
 
 cache_replacement_policy heap LFUDA
 cache_mem 4096 MB
 maximum_object_size 32 MB
 cache_dir diskd /usr/local/squid/cache 32768 32 256
 
 I have seen the following errors in cache.log:
 
 FATAL: Received Segment Violation...dying.
 FATAL: Received Bus Error...dying.
 
 after this the squid restarts. The system has 10GB of memory and is
 working as internal cache for ~600 users.
 
 Please point me in the right direction. I have no problem running
 squid33-3.3.13 on FreeBSD 9.3-STABLE #0 r270210.
 
 Thank you very much.
 
 Regards,
 
 lk

 Man, I empathize with you. Have you tried running Squid 3.4.x on
 FreeBSD 9.3? Sometimes I wonder if it's FreeBSD 10.x that's causing
 the issue...

I am running FreeBSD 9.3-STABLE #1 r274084 with Squid 3.4.9 as a cache
in DMZ without authentication. There are no problems.

lk

 I tried the shell variable MEMPOOLS=1 and that quickly made the
 situation a lot worse. Swap space would get filled up very quickly and
 the system would slow down quickly before crashing.

 Any other ideas?

 ~Doug

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users