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

From: Tom Tux <tomtux80_at_gmail.com>
Date: Fri, 2 Jul 2010 14:05:45 +0200

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")?

Do I have to renew it with a kinit [username]? As much I understand, I
have not to renew it....correct?
I had destroy the ticket on the squid with "kdestroy" and the client
is still able to connect.....why?

Regards,
Tom

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 - 12:05:53 MDT

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