Aw: Re: [squid-users] Kerberos / Authentication / squid

From: Berthold Zettler <zettler.berthold_at_gmx.de>
Date: Thu, 28 Nov 2013 10:42:47 +0100 (CET)

Hi Madhav,

all relevant a systems (AD-Controllers and the clients (Windows 7)) have a value for "MaxTokenSize" of 65535.

Therefore i don't think, that this failure was caused by AD- or client settings.

The tokensize (27332) reported by the MS tokensz.exe tool is far below this value.
Our other kerberized systems (Apaches) are working fine with this large tokensize.

So i think it's a squid / buffer or kerberos-helper related issue

kg

Berthold

> Gesendet: Mittwoch, 27. November 2013 um 18:41 Uhr
> Von: "Madhav V Diwan" <mdiwan_at_diwanconsulting.com>
> An: "Berthold Zettler" <zettler.berthold_at_gmx.de>
> Cc: squid-users_at_squid-cache.org
> Betreff: Re: [squid-users] Kerberos / Authentication / squid
>
> Berthold
>
> if you look in
>
> squid-3.3.10/helpers/negotiate_auth/kerberos/negotiate_kerberos_auth.cc
>
> the define states
>
> #ifndef MAX_AUTHTOKEN_LEN
> #define MAX_AUTHTOKEN_LEN 65535
> #endif
>
>
> which makes it look as if it is probably not squid's helper app that has
> the issue .. default WINDOWS token size is somewhere in windows registry
> set at 12000
>
> you should make certain that you have changed the windows registry value
> to 65535 in Decimal or FFFFF in Hex in your windows server registry
>
> if using an AD farm you will have to do it to every AD Domain
> Controller- manually
>
>
>
> -----Original Message-----
> From: Berthold Zettler <zettler.berthold_at_gmx.de>
> To: squid-users_at_squid-cache.org
> Subject: [squid-users] Kerberos / Authentication / squid
> Date: Wed, 27 Nov 2013 13:41:09 +0100 (CET)
>
> Hello to all,
>
> we are using squid as a authentication proxy with kerberos/ldap-helpers.
> This works fine, but (few) users can't be authenticated by the squid (kerberos-helper).
>
> Further investigation are showing a possible relationship to the tokensize (computed with the MS-Tool tokensz.exe) of these users.
>
> Our squid (Version 3.3.10) has been compiled with the following options:
>
> -->
> --disable-strict-error-checking' '--with-build-environment=default' '--prefix=/opt/squid-cit' '--enable-storeio=aufs,diskd,ufs' '--enable-internal-dns' '--enable-auth' '--enable-auth-negotiate=kerberos' '--enable-auth-basic=LDAP' '--enable-external-acl-helpers=LDAP_group,kerberos_ldap_group' '--with-maxfd=16384' '--enable-delay-pools' '--with-aufs-threads=30' '--with-large-files' '--enable-ssl'
> <--
>
> The OS is a SLES 11 SP1 (Kernel Version 2.6.32.54-0.3-default).
>
>
> How to reproduce the error:
>
> No Access:
> When the user is member of many groups in the AD (ActiceDirectory), we see, that he has no access to the webserver. If if we start the helper (negotiate_kerberos_auth) with -d, we have no additional info in the cache.log. We had to enable debugging (squid -k debug) to see some information. In this case the tokensize was 27332.
>
>
> Access:
> If the same user reduces his number of groups (tokensize 12252), he can access the website.
>
>
>
> What can be done to debug/solve this problem?
>
> kg
>
> Berthold
>
>

-- 
Diese E-Mail wurde aus dem Sicherheitsverbund E-Mail made in
Germany versendet: http://www.gmx.net/e-mail-made-in-germany
Received on Thu Nov 28 2013 - 09:43:01 MST

This archive was generated by hypermail 2.2.0 : Thu Nov 28 2013 - 12:00:06 MST