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@xxxxxxxxxxxxxxxxxxx> > An: "Berthold Zettler" <zettler.berthold@xxxxxx> > Cc: squid-users@xxxxxxxxxxxxxxx > Betreff: Re: 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@xxxxxx> > To: squid-users@xxxxxxxxxxxxxxx > Subject: 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
