Problems setting up Kerberos authentication

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems setting up Kerberos authentication

Fabian Hugelshofer
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/[hidden email]
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/[hidden email], 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
Reply | Threaded
Open this post in threaded view
|

Re: Problems setting up Kerberos authentication

Markus Moeller
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)


Markus


"Fabian Hugelshofer" <[hidden email]> wrote in message
news:[hidden email]...

> 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/[hidden email]
> 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/[hidden email], 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems setting up Kerberos authentication

Fabian Hugelshofer
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 [hidden email]
[hidden email]'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/[hidden email]
[hidden email]'s Password:
kinit: krb5_get_init_creds: Server
(HTTP/[hidden email]) unknown

## With a user from the domain of the proxy (A.EXAMPLE.COM)
# kinit [hidden email]
[hidden email]'s Password:
# squid_kerb_auth_test proxy.d1.d.example.com
Token: YIIF...
# kinit -S HTTP/[hidden email]
[hidden email]'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
Reply | Threaded
Open this post in threaded view
|

Re: Problems setting up Kerberos authentication

Markus Moeller
It looks like a configuration error. Also I recall Heimdal had some issues
with Cross realms. But you say all clients are on Windows only the server
uses squid with Heindal, so the problem might be on the Windows side. Do the
three AD domains trust each other ?

Markus


"Fabian Hugelshofer" <[hidden email]> wrote in message
news:[hidden email]...

> 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 [hidden email]
> [hidden email]'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/[hidden email]
> [hidden email]'s Password:
> kinit: krb5_get_init_creds: Server
> (HTTP/[hidden email]) unknown
>
> ## With a user from the domain of the proxy (A.EXAMPLE.COM)
> # kinit [hidden email]
> [hidden email]'s Password:
> # squid_kerb_auth_test proxy.d1.d.example.com
> Token: YIIF...
> # kinit -S HTTP/[hidden email]
> [hidden email]'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
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems setting up Kerberos authentication

Markus Moeller
In reply to this post by Fabian Hugelshofer
Some more comments below:

"Fabian Hugelshofer" <[hidden email]> wrote in message
news:[hidden email]...

> 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.
>

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 ?

> 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 [hidden email]
> [hidden email]'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/[hidden email]
> [hidden email]'s Password:
> kinit: krb5_get_init_creds: Server
> (HTTP/[hidden email]) unknown
>

This is correct  it should not work as there is no
HTTP/[hidden email] principal.  You need to use
another call to get a TGT for HTTP/proxy.d1.d.example.com like:

kinit [hidden email]
kgetcred HTTP/[hidden email]
klist

> ## With a user from the domain of the proxy (A.EXAMPLE.COM)
> # kinit [hidden email]
> [hidden email]'s Password:
> # squid_kerb_auth_test proxy.d1.d.example.com
> Token: YIIF...
> # kinit -S HTTP/[hidden email]
> [hidden email]'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
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems setting up Kerberos authentication

Fabian Hugelshofer
In reply to this post by Markus Moeller
Markus Moeller wrote:
> It looks like a configuration error. Also I recall Heimdal had some
> issues with Cross realms. But you say all clients are on Windows only
> the server uses squid with Heindal, so the problem might be on the
> Windows side. Do the three AD domains trust each other ?

Yes, all clients use Windows. Domain trust between all the involved
domains is ok.
Reply | Threaded
Open this post in threaded view
|

Re: Problems setting up Kerberos authentication

Fabian Hugelshofer
In reply to this post by Markus Moeller
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 [hidden email]
>> [hidden email]'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/[hidden email]
>> [hidden email]'s Password:
>> kinit: krb5_get_init_creds: Server
>> (HTTP/[hidden email]) unknown
>>
>
> This is correct  it should not work as there is no
> HTTP/[hidden email] principal.  You need to use
> another call to get a TGT for HTTP/proxy.d1.d.example.com like:
>
> kinit [hidden email]
> kgetcred HTTP/[hidden email]
> 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 are being sent and look the same in both cases.

Fabian
Reply | Threaded
Open this post in threaded view
|

Re: Problems setting up Kerberos authentication

Fabian Hugelshofer
In reply to this post by Fabian Hugelshofer
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