> > > From: "Markus Moeller" <hua...@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-us...@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@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@REALM >>> a) Use values given by -g option which contain a @REALM e.g. -g >>> GROUP1@REALM:GROUP2@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@REALM and then use values given by >>> -g option which contain a @REALM e.g. -g GROUP1@REALM:GROUP2@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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users