[squid-users] Re: Re: Re: Re: squid_kerb_ldap -> "Error while initialising credentials from keytab"

From: Markus Moeller <huaraz_at_moeller.plus.com>
Date: Fri, 2 Jul 2010 19:44:28 +0100

> "Tom Tux" <tomtux80_at_gmail.com> wrote in message
> news:AANLkTikVPJwrOa_sGBYvZpN2VyiSYBC3961JURlf9gVi_at_mail.gmail.com...
> Hi Markus
>
> Thank you. But what's the meaning of the kerberos-ticket cached on the
> squid (which I can not renew because of "kinit(v5): Ticket expired
> while renewing credentials")?

That is your user cache like on an XP PC. It has nothing to do with the
server.

> Do I have to renew it with a kinit [username]? As much I understand, I
> have not to renew it....correct?

Yes correct. You would have to do this if you would like to use for example
Firefox on Linux.

> I had destroy the ticket on the squid with "kdestroy" and the client
> is still able to connect.....why?
>

As I already said the client cache is the important cache. With kdestroy
you just clear the cache of the user who is logged in. (like kerbtray clear
the cache in XP of the logged in user)

Have a look how Kerberos works. In short the client ( in your case the user
on XP ) is requesting some encrypted information from the kdc ( Active
Directory in your case) and then the client application (IE in your case)
sends the encrypted information to the server (squid in your case). The
server uses the keytab to verify the encrypted information for each request
the client send to the server. The server does not need to cache anything
only the client caches to avoid to many requests to AD.

> Regards,
> Tom

Regards
Markus

2010/7/2 Markus Moeller <huaraz_at_moeller.plus.com>:
> Hi Tom,
>
> The important ticket is the one on the client (I assume a XP PC). Windows
> will usually renew the ticket automatically every 10 hours for 7 days. The
> proxy will request new tickets for the ldap authentication, but uses a
> memory cache which you can not access.
>
> Regards
> Markus
>
>
> "Tom Tux" <tomtux80_at_gmail.com> wrote in message
> news:AANLkTikQgFLhT3qy1hPgPlVk7Z5JUeUTwdk-BoD0f2cR_at_mail.gmail.com...
>>
>> Hi Markus
>>
>> Is it necessary to renew periodically the kerberos-ticket? I've
>> defined a a ticket_lifetime for 24h.
>>
>> I've now the following output:
>> proxy-test-01:~ # klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: user_at_XX.YY
>>
>> Valid starting Expires Service principal
>> 07/01/10 08:47:31 07/01/10 18:47:33 krbtgt/XX.YY_at_XX.YY
>> renew until 07/02/10 07:34:41
>>
>>
>> Kerberos 4 ticket cache: /tmp/tkt0
>> klist: You have no tickets cached
>>
>>
>> Now, the ticket seems to be expired. But I'm still able to
>> authenticate. Why? What is the behavior, if the kerberos-ticket is
>> expired? If I try to renew with "kinit -R", I got the following error:
>>
>> proxy-test-01:~ # kinit -R
>> kinit(v5): Ticket expired while renewing credentials
>>
>>
>> Is this normal? How can I solve this behavior?
>> Thanks you.
>> Regards,
>> Tom
>>
>>
>> 2010/7/1 Markus Moeller <huaraz_at_moeller.plus.com>:
>>>
>>> You could have used a tool like kerbtray or just lock and unlock the PC
>>> which would have refreshed the cache.
>>>
>>> Regards
>>> Markus
>>>
>>> "Tom Tux" <tomtux80_at_gmail.com> wrote in message
>>> news:AANLkTiljGRnzRu9WXIvAp0Tj22OnXaknjanBCZLvshiB_at_mail.gmail.com...
>>> Hi Markus
>>>
>>> This problem is solved now. I rebootet the client, which results in
>>> clearing the client-kerberos cache. Now I'm able to authenticate and I
>>> can use the squid_kerb_ldap-helper.
>>>
>>> Thanks a lot for your hints.
>>> Regards
>>> Tom
>>>
>>>
>>>
>>>
>>> 2010/7/1 Tom Tux <tomtux80_at_gmail.com>:
>>>>
>>>> Hi Markus
>>>>
>>>> Thank you.
>>>> So, I made my kerberos-configuration from scratch. This will mean:
>>>> - Delete computer-account in AD
>>>> - Remove /etc/krb5.keytab
>>>> - Check with "setspn -L proxy-test-01" if there were no SPN's -> OK.
>>>>
>>>> Then I created the account again with the following command:
>>>>
>>>> ./msktutil -c -s HTTP/proxy-test-01.xx.yy -h proxy-test-01.xx.yy -k
>>>> /etc/krb5.keytab --computer-name proxy-test-01 --upn
>>>> HTTP/proxy-test-01.xx.yy --server dc 1.xx.yy --verbose
>>>>
>>>> The computer-account was created successfully. In the msktutil-output,
>>>> I can see, that the KVNO is set to "2".
>>>>
>>>> On the Domain-Controller, I can also see, that the
>>>> "msDS-KeyVersionNumber" is also set to "2".
>>>>
>>>> But I'm not able to authenticate. I got the following
>>>> squid-cache-error:
>>>> 2010/07/01 07:37:04| authenticateNegotiateHandleReply: Error
>>>> validating user via Negotiate. Error returned 'BH
>>>> gss_accept_sec_context() failed: Unspecified GSS failure. Minor code
>>>> may provide more information. Key version number for principal in key
>>>> table is incorrect'
>>>>
>>>> What's wrong here? I tried with "kinit" and "kinit -R" again -> no
>>>> success. How can I fix this problem?
>>>> Regards
>>>> Tom
>>>>
>>>>
>>>> 2010/6/30 Markus Moeller <huaraz_at_moeller.plus.com>:
>>>>>
>>>>> Hi Tom
>>>>>
>>>>> squid_kerb_ldap tries to use the keytab to authenticate squid against
>>>>> AD.
>>>>> The keytab contains basically the password for the "user" http/<fqdn>
>>>>> which
>>>>> maps in AD to the userprincipalname attribute. In your case
>>>>> squid_kerb_ldap
>>>>> tries to use host/proxy-test-01.xx.yy_at_XX.YY but does not find in AD an
>>>>> entry
>>>>> which has the userprincipalname attribute with that value and therfore
>>>>> can
>>>>> not check group memberships. msktutil has the option --upn which will
>>>>> set
>>>>> the AD attribute accordingly (see
>>>>> alsohttp://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos).
>>>>>
>>>>>
>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Got principal name
>>>>> host/proxy-test-01.xx.yy_at_XX.YY
>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Error while initialising
>>>>> credentials
>>>>> from keytab : Client not found in Kerberos database
>>>>>
>>>>> Regards
>>>>> Markus
>>>>>
>>>>> "Tom Tux" <tomtux80_at_gmail.com> wrote in message
>>>>> news:AANLkTilZ_WeFjeU1bMnPSgvnhAhTe6RJMr6bjA-uuQ_m_at_mail.gmail.com...
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I'm trying to authenticate our clients with squid_kerb_ldap against
>>>>>> our ad. There exists a global-group called "Internet". My squid.conf
>>>>>> looks like this:
>>>>>>
>>>>>> auth_param negotiate program /usr/local/squid/libexec/squid_kerb_auth
>>>>>> -i
>>>>>> auth_param negotiate children 10
>>>>>> auth_param negotiate keep_alive on
>>>>>> external_acl_type SQUID_KERB_LDAP ttl=3600 negative_ttl=3600 %LOGIN
>>>>>> /usr/local/squid_kerb_ldap/bin/squid_kerb_ldap -d -g Internet
>>>>>> acl inetAccess external SQUID_KERB_LDAP
>>>>>> http_access allow inetAccess
>>>>>>
>>>>>>
>>>>>> My "klist -k" looks like this:
>>>>>> proxy-test-01:/usr/local/squid_kerb_ldap/bin # klist -k
>>>>>> Keytab name: FILE:/etc/krb5.keytab
>>>>>> KVNO Principal
>>>>>> ----
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------------
>>>>>> 4 host/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 4 host/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 4 host/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 4 host/proxy-test-01_at_XX.YY
>>>>>> 4 host/proxy-test-01_at_XX.YY
>>>>>> 4 host/proxy-test-01_at_XX.YY
>>>>>> 4 PROXY-TEST-01$@XX.YY
>>>>>> 4 PROXY-TEST-01$@XX.YY
>>>>>> 4 PROXY-TEST-01$@XX.YY
>>>>>> 4 HTTP/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 4 HTTP/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 4 HTTP/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 4 HTTP/proxy-test-01_at_XX.YY
>>>>>> 4 HTTP/proxy-test-01_at_XX.YY
>>>>>> 4 HTTP/proxy-test-01_at_XX.YY
>>>>>> 5 proxy-test-01$@XX.YY
>>>>>> 5 proxy-test-01$@XX.YY
>>>>>> 5 proxy-test-01$@XX.YY
>>>>>> 5 HTTP/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 5 HTTP/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 5 HTTP/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 5 HTTP/proxy-test-01_at_XX.YY
>>>>>> 5 HTTP/proxy-test-01_at_XX.YY
>>>>>> 5 HTTP/proxy-test-01_at_XX.YY
>>>>>> 5 host/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 5 host/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 5 host/proxy-test-01.xx.yy_at_XX.YY
>>>>>>
>>>>>>
>>>>>> Without squid_kerb_ldap, the internet-access is working fine. With
>>>>>> the
>>>>>> helper, I got the following errors in the cache.log:
>>>>>> 2010/06/30 09:45:48| squid_kerb_auth: INFO: User TESTUSER_at_XX.YY
>>>>>> authenticated
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Got User: TESTUSER Domain:
>>>>>> XX.YY
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: User domain loop: group_at_domain
>>>>>> Internet_at_NULL
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Default domain loop:
>>>>>> group_at_domain Internet_at_NULL
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Default group loop:
>>>>>> group_at_domain
>>>>>> Internet_at_NULL
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Found group_at_domain
>>>>>> Internet_at_NULL
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Setup Kerberos credential cache
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Get default keytab file name
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Got default keytab file name
>>>>>> /etc/krb5.keytab
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Get principal name from keytab
>>>>>> /etc/krb5.keytab
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Keytab entry has realm name:
>>>>>> XX.YY
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Found principal name:
>>>>>> host/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Set credential cache to
>>>>>> MEMORY:squid_ldap_22001
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Got principal name
>>>>>> host/proxy-test-01.xx.yy_at_XX.YY
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Error while initialising
>>>>>> credentials from keytab : Client not found in Kerberos database
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: Error during setup of Kerberos
>>>>>> credential cache
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: User TESTUSER is not member of
>>>>>> group_at_domain Internet_at_NULL
>>>>>> 2010/06/30 09:45:48| squid_kerb_ldap: ERR
>>>>>> 2010/06/30 09:45:48| squid_kerb_auth: INFO: User TESTUSER_at_XX.YY
>>>>>> authenticated
>>>>>>
>>>>>> What could this be? The user "testuser" is member of the ad-group
>>>>>> "Internet".
>>>>>> Thanks a lot.
>>>>>> Tom
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Received on Fri Jul 02 2010 - 18:44:53 MDT

This archive was generated by hypermail 2.2.0 : Sat Jul 03 2010 - 12:00:03 MDT