[squid-users] benefits of usingext_kerberos_ldap_group_aclinstead of ext_ldap_group_acl
Simon Stäheli
sis at open.ch
Thu Feb 12 16:41:30 UTC 2015
>
>
> From: "Markus Moeller" <huaraz at moeller.plus.com>
> Subject: Re: [squid-users] benefits of usingext_kerberos_ldap_group_aclinstead of ext_ldap_group_acl
> Date: 11. Februar 2015 22:32:11 MEZ
> To: squid-users at squid-cache.org
>
>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> On 20/01/2015 11:31 p.m., Simon Stäheli wrote:
>>>>>>> Are there any other benefits in using ext_kerberos_ldap_group_acl
>>>>>>> instead of ext_ldap_group_acl except the "Netbios name to Kerberos
>>>>>>> domain name” mappings provided by the -N option. As far as I can
>>>>>>> tell, this mapping can also easily be done by writing you own
>>>>>>> helper perl script which is doing the mapping and finally feeds the
>>>>>>> more common ext_ldap_group_acl helper.
>>>>>>>
>>>>>>
>>>>>> Whatever floats your boat. The point of the Addon/Plugin/helpers API
>>>>>> is that you can use scripts if thy serve your needs better.
>>>>>>
>>>>>> All the usual Open Source benefits of "many eyeballs" and somebody
>>>>>> else doing code maintenance for you applies to using a bundled helper
>>>>>> over a custom written one.
>>>>>>
>>>>>> Beyond that the kerberos helper also provides automatic detection of
>>>>>> which LDAP server to use via mutiple auto-configuration methods.
>>>>>>
>>>>>
>>>>> The idea of the helper was to automate most of the configuration (
>>>>> ignoring
>>>>> some performance ) and avoid using a username/password, support users
>>>>> from
>>>>> multiple domains. Secondly I wanted check for nested groups which was
>>>>> not
>>>>> available in the existing helper and thirdly I also check now against
>>>>> the
>>>>> primary group of the user.
>>>>>
>>>>
>>>> Thank you Markus for your explanations. I played around with
>>>> ext_kerberos_ldap_group_acl and would like to go into some details:
>>>>
>>>> 1) it is possible to define more than one LDAP server (e.g. for high
>>>> availability reasons)? The -l parameter allows only one ldap url while
>>>> -S allows several "server > realm" - mappings.
>>>>
>>>
>>> I didn't see the need. The -l was more for cases when digest or basic auth
>>> is used and I do not know the domain to check against. So a fallback
>>> option.
>>>
>>>
>>>> 2) It is correct, that compared to ext_ldap_group_acl,
>>>> ext_kerberos_ldap_group_acl does not require a groupname as input (from
>>>> stdin), because -g -t -T or -D control the group name?!
>>>>
>>>
>>> You have two options with ext_kerberos_ldap_group_acl as input or as -g ..
>>> control
>>>
>>>
>>>> 3) What is the use case for defining -g GROUP@? What is the difference
>>>> to -g GROUP (without @)
>>>>
>>>
>>> -g GROUP is for all users including the once with nor provided domain
>>>
>>>
>>> The an pages describe it a bit under Note:
>>>
>>> 1) For user at REALM
>>> a) Query DNS for SRV record _ldap._tcp.REALM
>>> b) Query DNS for A record REALM
>>> c) Use LDAP_URL if given
>>>
>>> 2) For user
>>> a) Use domain -D REALM and follow step 1)
>>> b) Use LDAP_URL if given
>>>
>>> The Groups to check against are determined as follows:
>>>
>>> 1) For user at REALM
>>> a) Use values given by -g option which contain a @REALM e.g. -g
>>> GROUP1 at REALM:GROUP2 at REALM
>>> b) Use values given by -g option which contain a @ only e.g. -g
>>> GROUP1@:GROUP2@
>>> c) Use values given by -g option which do not contain a realm e.g.
>>> -g GROUP1:GROUP2
>>>
>>> 2) For user
>>> a) Use values given by -g option which do not contain a realm e.g.
>>> -g GROUP1:GROUP2
>>>
>>> 3) For NDOMAIN\user
>>> a) Use realm given by -N NDOMAIN at REALM and then use values given by
>>> -g option which contain a @REALM e.g. -g GROUP1 at REALM:GROUP2 at REALM
>>>
>>>
>>>
>>>> 4) The "query DNS for SRV record _ldap._tcp.REALM" mechanism seems no to
>>>> work for me although the DNS server is configured correctly and querying
>>>> with "dig SRV _ldap._tcp.REALM" works fine. Anything to consider here?
>>>> _ldap._tcp.REALM SRV query was never sent so far.
>>>>
>>>
>>> I would not see an obvious reason. Does -d show any hints ? I can only
>>> imagine that REAM is not what is send by the client.
>>>
>>>> 5) Similar issues with the Kerberos feature. Keytab und Kerberos config
>>>> are available and exported, but the helper only says:
>>>> support_ldap.cc(888): DEBUG: Setup Kerberos credential cache
>>>> support_ldap.cc(897): DEBUG: Kerberos is not supported. Use
>>>> username/password with ldap url instead
>>>>
>>>
>>> The message support_ldap.cc(897): DEBUG: Kerberos is not supported. means
>>> your Kerberos installation is not fully available. It means HAVE_KRB5 is not
>>> set ( maybe header files were missing).
>>
>>
>> Can you give me some further information about the requirements of the helper regarding kerberos? I am trying to use it with Heimdal kerberos (Heimdal 1.3.3). negotiate_kerberos_auth for example works very well with the present kerberos libraries.
>>
>>
>
> Can you send the config.log file ? For some reason HAVE_KRB5 is not set ( which is a bit strange as it is also used for the auth helper)
hmh, HAVE_KRB5 seems not to be set in include/autoconf.h
What is the correct way to provide squid the path to the kerberos header files?
./configure —help doesn’t show a useful option as --with-krb5-config= seems not to be the right option.
What I did: set KRBINCS and KRBLIBS to following values:
KRB5INCS="-DHAVE_GSSAPI -DHAVE_GSSAPI_GSSAPI_H -DHAVE_GSSAPI_H -DHAVE_HEIMDAL_KERBEROS -I/path/to/krb5/include -DHAVE_STRING_H -DHAVE_STDOI_H -DHAVE_NETDB_H -DHAVE_UNISTD_H -DHAVE_TIME_H”
KRB5LIBS="-L/path/to/krb5/lib -lgssapi -lkrb5 -lcom_err -lasn1 -lroken”
and executed ./configure with following parameters
./configure --prefix=/path/to/squid --sysconfdir=/path/to/squid/etc --mandir=/usr/share/man --enable-auth --enable-auth-basic="LDAP" --enable-auth-digest="none" --enable-auth-ntlm="none" --enable-auth-negotiate="kerberos,wrapper" --enable-url-rewrite-helpers="none" --enable-storeio="ufs,aufs" --with-default-user=squid --enable-delay-pools --with-large-files --enable-icap-client --with-pthreads --disable-ident-lookups --disable-icmp --enable-ipv6 --with-filedescriptors=65536 --disable-translation --enable-removal-policies="heap,lru" --enable-ssl --enable-ssl-crtd --enable-log-daemon-helpers="file" --disable-translation --disable-auto-locale --enable-stacktraces —includedir=“/path/to/krb5/include" --with-krb5-config=“/path/to/krb5/include” --enable-external-acl-helpers="LDAP_group,wbinfo_group,kerberos_ldap_group”
kerberos_ldap_group does not compile automatically when executing make. I had to compile it manually by executing make in ./helpers/external_acl/kerberos_ldap_group
negotiate_kerberos_auth works this way.
>
>>>
>>>> Instead of that I found a dns SRV _kerberos._udp.REALM query which was
>>>> actually answered by the dns. I assume this is related to the Kerberos
>>>> feature?
>>>
>>> yes it is. It is a way to find the kdc.
>>>
>>>>
>>>> 6) It is possible to use the helper when DNS service is not reachable?
>>>> Got some error messages during testing:
>>>>
>>>> kerberos_ldap_group: DEBUG: Canonicalise ldap server name
>>>> 213.156.236.111:3268
>>>> kerberos_ldap_group: ERROR: Error while resolving ip address with
>>>> getnameinfo: Temporary failure in name resolution
>>>> kerberos_ldap_group: DEBUG: Error during initialisation of ldap
>>>> connection: Success
>>>>
>>>
>>> If you add a line to your hosts file and use the approriate nsswitch.conf it
>>> should work. You can also add a line to the hosts file for the domain for
>>> the case the SRV record fails.
>>>
>>>
>>>> Beside this tiny issues the helper works excellent (tested with basic,
>>>> NTLM and Kerberos authentication). I am just trying to discover the
>>>> whole potential. Thank you very much for any responses.
>>>>
>>>> Regards
>>>> Simon
>>>>
>>>
>>> Regards
>>> Markus
>>>
>>>>>> If you can demonstrate that the ext_kerberos_ldap_group_acl does
>>>>>> provides a superset of the functionality of ext_ldap_group_acl helper
>>>>>> then I can de-duplicate the two helpers.
>>>>>>
>>>>>> Amos
>>>>>
>>>>> Regards
>>>>> Markus
>>>>
>>>
> Markus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150212/e4088593/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4030 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150212/e4088593/attachment-0001.bin>
More information about the squid-users
mailing list