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 - 11:24:44 MDT
This archive was generated by hypermail 2.2.0 : Fri Jul 02 2010 - 12:00:03 MDT