[squid-users] Problems setting up Kerberos authentication
Hello, I am setting up Kerberos auth on squid (3.1.15), but it won't work. Browser (IE 8) keeps on poping up the username/password window, but authentication is never successful. Yet, I don't see any logging of failed authentication attempts in kerberos logs at all! It's as if squid is not communicating with kerberos server. Yet, kinit from the command line works fine (see details below). What am I doing wrong? Am I missing something? I need your help. Thanks, Nick Details of the setup follow (true names/IP addresses have been changed): I have a working Kerberos Server (MIT Kerberos 5 on CentOS 5.6) on kerb.example.com and I am setting up squid on squid.example.com; it's Squid 3.1.15.x86_64 as RPM on CentOS 5.6 (from here: ftp://ftp.pbone.net/mirror/ftp.pramberger.at/systems/linux/contrib/rhel5/x86_64/squid3-3.1.15-1.el5.pp.x86_64.rpm). Host squid.example.com is also setup as a kerberos client. So, I have added to kerberos a host: host/squid.example@example.com and a service: HTTP/squid.example@example.com Then, I created a keytab file (httpsquid.keytab) for the latter: [root@squid]# kadmin.local Authenticating as principal userx/ad...@example.com with password. kadmin.local: addprinc HTTP/squid.example@example.com WARNING: no policy specified for HTTP/squid.example@example.com; defaulting to no policy Enter password for principal "HTTP/squid.example@example.com": Re-enter password for principal "HTTP/squid.example@example.com": Principal "HTTP/squid.example@example.com" created. kadmin.local: ktadd -k /etc/krb5kdc/httpsquid.keytab HTTP/squid.example.com Entry for principal HTTP/squid.example.com with kvno 2, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5kdc/httpsquid.keytab. Entry for principal HTTP/squid.example.comwith kvno 2, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5kdc/httpsquid.keytab. Entry for principal HTTP/squid.example.comwith kvno 2, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5kdc/httpsquid.keytab. Entry for principal HTTP/squid.example.comwith kvno 2, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5kdc/httpsquid.keytab. Entry for principal HTTP/squid.example.comwith kvno 2, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5kdc/httpsquid.keytab. Entry for principal HTTP/squid.example.comwith kvno 2, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5kdc/httpsquid.keytab. ...moved it to /etc/squid and changed ownership to root:squid and permissions: 640. I have checked that the keytab file works: [root@squid]# kinit -V -k -t httpsquid.keytab HTTP/squid.example.com Authenticated to Kerberos v5 I also added to the start of /etc/init.d/squid the lines: KRB5_KTNAME=/etc/squid/httpsquid.keytab export KRB5_KTNAME Then, I checked that kerberos authentication is enabled (as explained e.g. here: http://publib.boulder.ibm.com/infocenter/ltscnnct/v2r0/index.jsp?topic=/com.ibm.connections.25.help/t_install_kerb_edit_browsers.html), then I specified (in IE, Internet Options / Connections / LAN Settings) squid.example.com as a Proxy on port 3128 and I have tried to visit any page. As I explained, browser (IE 8) keeps on poping up the username/password window, but authentication is never successful. I have tried the following as username, without success: userx EXAMPLE.COM\userx us...@example.com us...@example.com On the other hand, Firefox 6 (with similar settings) doesn't show any pop up window; it just fails. I have tried the three following configuration alternatives, but it didn't make any difference: auth_param negotiate program /usr/libexec/squid/squid_kerb_auth -d auth_param negotiate program /usr/libexec/squid/squid_kerb_auth-d -s HTTP/squid.example.com auth_param negotiate program /usr/libexec/squid/squid_kerb_auth Here is /etc/squid/squid.conf: --- acl manager proto cache_object acl localhost src 127.0.0.1/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 acl localnet src 10.10.10.0/24 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access allow localhost auth_param negotiate program /usr/libexec/squid/squid_kerb_auth -d auth_param negotiate children 10 auth_param negotiate keep_alive on acl auth proxy_auth REQUIRED http_access allow auth #http_
Re: [squid-users] Problems setting up Kerberos authentication
Hi all, Fabian Hugelshofer wrote: Markus Moeller wrote: Continuation needed means that the GSSAPI exchange has not finished and the server needs more data from the client. Can you see in wireshark if the token length is the one squid_kerb_auth says it is > squid_kerb_auth: Got 'YRYI...' from squid (length: 3607) Update: I could find the reason for the error message. Even though it was a hierarchical domain structure, the proxy server performed a transit domain path verification. One domain of the path was not in the transited domains list. Not sure whether this is a Microsoft or Heimdal issue. As a workaround I manually spefified the list of transit domains in the [capatsh] section of krb5.conf. This made it work. For details see my posts on the Heimdal mailing list: https://list.sics.se/sympa/arc/heimdal-discuss/2010-03/msg00096.html Regards, Fabian
Re: [squid-users] Problems setting up Kerberos authentication
Markus Moeller wrote:
Can you download kerbtray from microsoft and list the tickets you have
on XP on a working and failing machine. Can you alos capture with
wireshark the traffic on port 88 ?
Using kerbtray did not show a difference. Capturing the traffic on port
88 shows that in both cases the client walks through the domain
hierarchy and at the end gets a ticket for the proxy service.
Comparing the tickets that are sent in the HTTP request with Wireshark
did not show any difference at all. For what I can see there
I used debug_options ALL,1 29,9. Both cases start with:
2010/03/04 13:39:49| authenticateValidateUser: Validating Auth_user
request '(nil)'.
2010/03/04 13:39:49| authenticateValidateUser: Auth_user_request was NULL!
2010/03/04 13:39:49| authenticateAuthenticate: broken auth or no
proxy_auth header. Requesting auth header.
2010/03/04 13:39:49| authenticateFixHeader: headertype:38 authuser:(nil)
2010/03/04 13:39:49| authenticateNegotiateFixErrorHeader: Sending
type:38 header: 'Negotiate'
2010/03/04 13:39:50| authenticateAuthenticate: header Negotiate YII...
2010/03/04 13:39:50| authenticateAuthenticate: This is a new checklist
test on FD:71
2010/03/04 13:39:50| authenticateAuthenticate: no connection
authentication type
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '1'.
2010/03/04 13:39:50| authenticateDecodeAuth: header = 'Negotiate YII...
2010/03/04 13:39:50| authenticateAuthUserLock auth_user '0x8593128'.
2010/03/04 13:39:50| authenticateAuthUserLock auth_user '0x8593128' now
at '1'.
2010/03/04 13:39:50| authenticateDecodeNegotiateAuth: Negotiate
authentication
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| User not fully authenticated.
2010/03/04 13:39:50| authenticateNegotiateAuthenticateUser: auth state
negotiate none. Negotiate YII...
2010/03/04 13:39:50| authenticateNegotiateAuthenticateUser: Locking
auth_user from the connection.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '2'.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| User not fully authenticated.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateStart: auth_user_request '0x8552f98'
2010/03/04 13:39:50| authenticateNegotiateStart: auth state '1'
2010/03/04 13:39:50| authenticateNegotiateStart: state '1'
2010/03/04 13:39:50| authenticateNegotiateStart: 'YII...
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '3'.
2010/03/04 13:39:50| squid_kerb_auth: Got 'YR YII... ' from squid
(length: 3607).
Then for the non-working case:
2010/03/04 13:39:50| squid_kerb_auth: continuation needed
2010/03/04 13:39:50| authenticateNegotiateHandleReply: Helper:
'0x82d5d40' {TT oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo=}
2010/03/04 13:39:50| authenticateNegotiateHandleReply: Need to challenge
the client with a server blob 'oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo='
The only difference that I can see is that in the non-working case the
ticket length is 3607 and in the working case 2643.
## With a user from non-working domain B1.B.EXAMPLE.COM
# kinit us...@b1.b.example.com
us...@b1.b.example.com's Password:
# squid_kerb_auth_test proxy.d1.d.example.com
2010/03/04 15:26:51| squid_kerb_auth_test: gss_init_sec_context()
failed: An unsupported mechanism was requested. unknown mech-code 0
for mech unknown
Token: NULL
# kinit -S HTTP/proxy.d1.d.example@a.example.com
us...@b1.b.example.com's Password:
kinit: krb5_get_init_creds: Server
(HTTP/proxy.d1.d.example@b1.b.example.com) unknown
This is correct it should not work as there is no
HTTP/proxy.d1.d.example@b1.b.example.com principal. You need to use
another call to get a TGT for HTTP/proxy.d1.d.example.com like:
kinit us...@b1.b.example.com
kgetcred HTTP/proxy.d1.d.example@a.example.com
klist
At the moment I don't have kgetcred available. I will try this later.
Thanks for the hint.
Using a user from the domain that is not working on a computer of the
domain that is, did not help. Is definitely somehow domain-related. The
tickets ar
Re: [squid-users] Problems setting up Kerberos authentication
Markus Moeller wrote:
Continuation needed means that the GSSAPI exchange has not finished and
the server needs more data from the client. Can you see in wireshark if
the token length is the one squid_kerb_auth says it is
> squid_kerb_auth: Got 'YRYI...' from squid (length: 3607)
I could confirm that the data that the client sends in the HTTP request
is the same that is received by squid_kerb_auth. "YR " is added by squid
(the space in the log of my last post got lost).
Further, I discovered that authentication is working for users from
certain domains, but not for those at whose location the proxy is
standing at. I describe the AD domain setup in more details:
The computer account that is associated with the service principal in
the keytab file is from domain A.EXAMPLE.COM. Users, for who access is
not working, are from domain B1.B.EXAMPLE.COM. Access is working for
users from C.EXAMPLE.COM and a few others. The users from these "other"
domains have been tested by starting IE as a user from that domain on a
computer in domain C.EXAMPLE.COM. I forgot to mention that all the
clients are Windows XP with IE7.
The FQDN of the proxy is not in the Windows domain hierarchy. It is
proxy.d1.d.example.com.
I compiled squid_kerb_auth_test from Squid 3.1. On the proxy:
## With a user from non-working domain B1.B.EXAMPLE.COM
# kinit us...@b1.b.example.com
us...@b1.b.example.com's Password:
# squid_kerb_auth_test proxy.d1.d.example.com
2010/03/04 15:26:51| squid_kerb_auth_test: gss_init_sec_context()
failed: An unsupported mechanism was requested. unknown mech-code 0 for
mech unknown
Token: NULL
# kinit -S HTTP/proxy.d1.d.example@a.example.com
us...@b1.b.example.com's Password:
kinit: krb5_get_init_creds: Server
(HTTP/proxy.d1.d.example@b1.b.example.com) unknown
## With a user from the domain of the proxy (A.EXAMPLE.COM)
# kinit us...@a.example.com
us...@a.example.com's Password:
# squid_kerb_auth_test proxy.d1.d.example.com
Token: YIIF...
# kinit -S HTTP/proxy.d1.d.example@a.example.com
us...@a.example.com's Password:
Tomorrow I will try with a user from another domain that is working and
that is outside A.EXAMPLE.COM. The content of my krb5.conf is:
[libdefaults]
default_realm = A.EXAMPLE.COM
[realms]
A.EXAMPLE.COM = {
kdc = 10.0.0.1
kdc = 10.0.0.2
}
B1.b.EXAMPLE.COM = {
kdc = 10.1.0.1
kdc = 10.1.0.2
}
[domain_realm]
.example.com = A.EXAMPLE.COM
example.com = A.EXAMPLE.COM
.d1.d.example.com = A.EXAMPLE.COM
d1.d.example.com = A.EXAMPLE.COM
Fabian
[squid-users] Problems setting up Kerberos authentication
Hi all, I am trying to set up Kerberos authentication with Squid 2.7.stable7 on Linux. I use Heimdal 1.3.1. I already had success doing so on two proxies, but in a third environment, authentication fails. In squid.conf I have the following entries: auth_param negotiate program /opt/squid/libexec/squid_kerb_auth -d -s HTTP/proxy.example@example.com acl REQUIRE_AUTH proxy_auth REQUIRED http_access allow src_localhost http_access deny !REQUIRE_AUTH http_access allow all Environmental variables KRB5_CONFIG and KRB5_KTNAME are set. By using kinit on the proxy it is possible to obtain a user ticket (auth with a password) and obtaining the service principal ticket (HTTP/proxy.example@example.com, auth with the keytab file) works fine, too. When a client tries to use the proxy, the conversation is as following: * User requests website * Proxy responds with 407 and sets header "Proxy-Authenticate: Negotiate" * User sends another request for the website and sends the ticket. From Wireshark: OID: 1.3.6.1.5.5.2 (SPNEGO) negTokenInit MechTypes: 1.2.840.48018.1.2.2 (MS KRB5), 1.2.840.113554.1.2.2 (KRB5), 1.3.6.1.4.1.311.2.2.10 (NTLMSSP) krb5_blob: Kerberos AP-REQ Realm: EXAMPLE.COM Server Name (type 2, service and instance): HTTP/proxy.domain.com * squid_kerb_auth reports: squid_kerb_auth: Got 'YRYI...' from squid (length: 3607) squid_kerb_auth: parseNegTokenInit failed with rc=102 squid_kerb_auth: continuation needed. * Proxy replies with 407: GSS-API:SPNEGO:negTokenTarg negResult: accept-incomplete supportedMech: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP) * Client gets an authentication pop-up where he can enter a username and password, but this does not work. This is probably related to the suggested NTLMSSP. * User requests URL again, this time with an NTLM authenticator GSS-API:SNPEGO:negTokenTarg NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_NEGOTIATE * squid_kerb_auth reports: squid_kerb_auth: Got 'KKoS...' from squid (length: 67) squid_kerb_auth: parseNegTokenInit failed with rc=300 squid_kerb_auth: Invalid GSS-SPNEGO query [KKoS...]. NA Invalid GSS-SPNEGO query. * Server replies to client with "Proxy-Authenticate: Negotiate Invalid" Does anyone have an idea what is going wrong, i.e. why the authentication helper replies with "continuation needed" and what I should try to debug? Best regards, Fabian
