Discussion:
[squid-users] negotiate_kerberos_auth: ERROR
neok
2018-09-28 19:51:11 UTC
Permalink
Hello people, in general terms my proxy works quite well. However I tell you
that very eventually, (maybe about 10 times per day based on 15 users using
my test proxy) I get this error in cache.log:


negotiate_kerberos_auth.cc(180): pid=21573 :2018/09/28 14:42:25|
negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified
GSS failure. Minor code may provide more information. Request is a replay
2018/09/28 14:42:25 kid1| ERROR: Negotiate Authentication validating user.
Result: {result=BH, notes={message: gss_accept_sec_context() failed:
Unspecified GSS failure. Minor code may provide more information. Request
is a replay; }}
negotiate_kerberos_auth.cc(180): pid=21573 :2018/09/28 14:42:26|
negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified
GSS failure. Minor code may provide more information. Request is a replay
2018/09/28 14:42:26 kid1| ERROR: Negotiate Authentication validating user.
Result: {result=BH, notes={message: gss_accept_sec_context() failed:
Unspecified GSS failure. Minor code may provide more information. Request
is a replay; }}

I've browse several hours without finding out what causes this error, or if
it's serious, or if I should ignore it.
Could someone with more experience tell me if it's possible what could be
the reason for this error?
My testing environment:

- A VM CentOS 7 Core over VirtualBox 5.2, 1 NIC.
- My VM is attached to my domain W2012R2 (following this post
https://www.rootusers.com/how-to-join-centos-linux-to-an-active-directory-domain/)
to achieve kerberos authentication transparent to the user. SElinux
disabled. Owner permissions to user squid in all folders/files involved.
- squid 3.5.20 installed and working great with Negotiate/NTLM and
Negotiate/Kerberos authentication


squid.conf
### Negotiate/NTLM and Negotiate/Kerberos authentication
auth_param negotiate program /usr/sbin/negotiate_wrapper --ntlm
/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --kerberos
/usr/lib64/squid/negotiate_kerberos_auth -r -d -s GSS_C_NO_NAME
auth_param negotiate children 200
auth_param negotiate keep_alive on

Thank you very much indeed.
Cordial greetings
Gabriel




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
Amos Jeffries
2018-09-28 23:28:56 UTC
Permalink
Post by neok
Hello people, in general terms my proxy works quite well. However I tell you
that very eventually, (maybe about 10 times per day based on 15 users using
negotiate_kerberos_auth.cc(180): pid=21573 :2018/09/28 14:42:25|
negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified
GSS failure. Minor code may provide more information. Request is a replay
2018/09/28 14:42:25 kid1| ERROR: Negotiate Authentication validating user.
Unspecified GSS failure. Minor code may provide more information. Request
is a replay; }}
negotiate_kerberos_auth.cc(180): pid=21573 :2018/09/28 14:42:26|
negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified
GSS failure. Minor code may provide more information. Request is a replay
2018/09/28 14:42:26 kid1| ERROR: Negotiate Authentication validating user.
Unspecified GSS failure. Minor code may provide more information. Request
is a replay; }}
I've browse several hours without finding out what causes this error, or if
it's serious, or if I should ignore it.
It is serious.
Post by neok
Could someone with more experience tell me if it's possible what could be
the reason for this error?
"Request is a replay", aka "token replay attack".

The client is sending a credentials token which has already been used on
another connection. Such clients are either fatally broken, or malicious.

Negotiate and NTLM credentials authenticate the specific TCP connection
they are used on. They are not permitted to be re-used on other
connections nor changed once authenticated.


PS. please upgrade if you can, there are security issues with 3.5.23 and
older releases. Eliezer provides updated CentOS packages for more recent
Squid versions (see <https://wiki.squid-cache.org/KnowledgeBase/CentOS>).

Amos
neok
2018-10-01 19:12:45 UTC
Permalink
Thank you for the answer Amos!
I will see the possibility of updating the version.
I also have to evaluate the possibility that this error is due to some of my
users using mail services on their smartphones and are authenticated against
my AD Servers .
I'm not sure if it can be or not... I have to analyze it.

Thanks again.
Greetings !



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
Amos Jeffries
2018-10-01 21:08:47 UTC
Permalink
Post by neok
Thank you for the answer Amos!
I will see the possibility of updating the version.
I also have to evaluate the possibility that this error is due to some of my
users using mail services on their smartphones and are authenticated against
my AD Servers .
I'm not sure if it can be or not... I have to analyze it.
That is highly unlikely.

It may be the reason NTLM credentials are being sent, but will not
itself cause the "*" behaviour.

That "*" is coming directly from the negotiate_wrapper helper and how it
is configured. Problems are known to occur with the wrapper helper when
the sub-helper is misconfigured, or when usernames contain whitespace
the old squid-2 helper protocol cannot cope with that. The former
usually results in these weird "*", and the latter shows up as truncated
usernames in your access.log.


Amos

Continue reading on narkive:
Search results for '[squid-users] negotiate_kerberos_auth: ERROR' (Questions and Answers)
4
replies
____ 3. In FTP, ASCII and binary are the two file transfer ____.?
started 2007-11-30 12:46:38 UTC
programming & design
Loading...