<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><br><br><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica';">"Markus Moeller" <<a href="mailto:huaraz@moeller.plus.com">huaraz@moeller.plus.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica';"><b>Re: [squid-users] benefits of usingext_kerberos_ldap_group_aclinstead of ext_ldap_group_acl</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica';">11. Februar 2015 22:32:11 MEZ<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(127, 127, 127, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica';"><a href="mailto:squid-users@squid-cache.org">squid-users@squid-cache.org</a><br></span></div><br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>On 20/01/2015 11:31 p.m., Simon Stäheli wrote:<br><blockquote type="cite">Are there any other benefits in using ext_kerberos_ldap_group_acl<br>instead of ext_ldap_group_acl except the "Netbios name to Kerberos<br>domain name” mappings provided by the -N option. As far as I can<br>tell, this mapping can also easily be done by writing you own<br>helper perl script which is doing the mapping and finally feeds the<br>more common ext_ldap_group_acl helper.<br><br></blockquote><br>Whatever floats your boat. The point of the Addon/Plugin/helpers API<br>is that you can use scripts if thy serve your needs better.<br><br>All the usual Open Source benefits of "many eyeballs" and somebody<br>else doing code maintenance for you applies to using a bundled helper<br>over a custom written one.<br><br>Beyond that the kerberos helper also provides automatic detection of<br>which LDAP server to use via mutiple auto-configuration methods.<br><br></blockquote><br>The idea of the helper was to automate most of the configuration (<br>ignoring<br>some performance ) and avoid using a username/password, support users<br>from<br>multiple domains. Secondly I wanted check for nested groups which was<br>not<br>available in the existing helper and thirdly I also check now against<br>the<br>primary group of the user.<br><br></blockquote><br>Thank you Markus for your explanations. I played around with<br>ext_kerberos_ldap_group_acl and would like to go into some details:<br><br>1) it is possible to define more than one LDAP server (e.g. for high<br>availability reasons)? The -l parameter allows only one ldap url while<br>-S allows several "server > realm" - mappings.<br><br></blockquote><br>I didn't see the need. The -l was more for cases when digest or basic auth<br>is used and I do not know the domain to check against. So a fallback<br>option.<br><br><br><blockquote type="cite">2) It is correct, that compared to ext_ldap_group_acl,<br>ext_kerberos_ldap_group_acl does not require a groupname as input (from<br>stdin), because -g -t -T or -D control the group name?!<br><br></blockquote><br>You have two options with ext_kerberos_ldap_group_acl as input or as -g ..<br>control<br><br><br><blockquote type="cite">3) What is the use case for defining -g GROUP@? What is the difference<br>to -g GROUP (without @)<br><br></blockquote><br>-g GROUP is for all users including the once with nor provided domain<br><br><br>The an pages describe it a bit under Note:<br><br>1) For user@REALM<br> a) Query DNS for SRV record _ldap._tcp.REALM<br> b) Query DNS for A record REALM<br> c) Use LDAP_URL if given<br><br>2) For user<br> a) Use domain -D REALM and follow step 1)<br> b) Use LDAP_URL if given<br><br>The Groups to check against are determined as follows:<br><br>1) For user@REALM<br> a) Use values given by -g option which contain a @REALM e.g. -g<br>GROUP1@REALM:GROUP2@REALM<br> b) Use values given by -g option which contain a @ only e.g. -g<br>GROUP1@:GROUP2@<br> c) Use values given by -g option which do not contain a realm e.g.<br>-g GROUP1:GROUP2<br><br>2) For user<br> a) Use values given by -g option which do not contain a realm e.g.<br>-g GROUP1:GROUP2<br><br>3) For NDOMAIN\user<br> a) Use realm given by -N NDOMAIN@REALM and then use values given by<br>-g option which contain a @REALM e.g. -g GROUP1@REALM:GROUP2@REALM<br><br><br><br><blockquote type="cite">4) The "query DNS for SRV record _ldap._tcp.REALM" mechanism seems no to<br>work for me although the DNS server is configured correctly and querying<br>with "dig SRV _ldap._tcp.REALM" works fine. Anything to consider here?<br>_ldap._tcp.REALM SRV query was never sent so far.<br><br></blockquote><br>I would not see an obvious reason. Does -d show any hints ? I can only<br>imagine that REAM is not what is send by the client.<br><br><blockquote type="cite">5) Similar issues with the Kerberos feature. Keytab und Kerberos config<br>are available and exported, but the helper only says:<br>support_ldap.cc(888): DEBUG: Setup Kerberos credential cache<br>support_ldap.cc(897): DEBUG: Kerberos is not supported. Use<br>username/password with ldap url instead<br><br></blockquote><br>The message support_ldap.cc(897): DEBUG: Kerberos is not supported. means<br>your Kerberos installation is not fully available. It means HAVE_KRB5 is not<br>set ( maybe header files were missing).<br></blockquote><br><br>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.<br><br><br></blockquote><br>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)<br></blockquote><div><br></div><div><br></div><div>hmh, HAVE_KRB5 seems not to be set in include/autoconf.h</div><div><br></div><div>What is the correct way to provide squid the path to the kerberos header files? </div><div><br></div><div>./configure —help doesn’t show a useful option as --with-krb5-config= seems not to be the right option.</div><div><br></div><div>What I did: set KRBINCS and KRBLIBS to following values:</div><div><br></div><div>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”</div><div>KRB5LIBS="-L/path/to/krb5/lib -lgssapi -lkrb5 -lcom_err -lasn1 -lroken”</div><div><br></div><div>and executed ./configure with following parameters</div><div><br></div><div>./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”</div><div><br></div><div>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</div><div><br></div><div>negotiate_kerberos_auth works this way.</div><div><br></div><div><br></div><br><blockquote type="cite"><br><blockquote type="cite"><blockquote type="cite"><br><blockquote type="cite">Instead of that I found a dns SRV _kerberos._udp.REALM query which was<br>actually answered by the dns. I assume this is related to the Kerberos<br>feature?<br></blockquote><br>yes it is. It is a way to find the kdc.<br><br><blockquote type="cite"><br>6) It is possible to use the helper when DNS service is not reachable?<br>Got some error messages during testing:<br><br>kerberos_ldap_group: DEBUG: Canonicalise ldap server name<br>213.156.236.111:3268<br>kerberos_ldap_group: ERROR: Error while resolving ip address with<br>getnameinfo: Temporary failure in name resolution<br>kerberos_ldap_group: DEBUG: Error during initialisation of ldap<br>connection: Success<br><br></blockquote><br>If you add a line to your hosts file and use the approriate nsswitch.conf it<br>should work. You can also add a line to the hosts file for the domain for<br>the case the SRV record fails.<br><br><br><blockquote type="cite">Beside this tiny issues the helper works excellent (tested with basic,<br>NTLM and Kerberos authentication). I am just trying to discover the<br>whole potential. Thank you very much for any responses.<br><br>Regards<br>Simon<br><br></blockquote><br>Regards<br>Markus<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">If you can demonstrate that the ext_kerberos_ldap_group_acl does<br>provides a superset of the functionality of ext_ldap_group_acl helper<br>then I can de-duplicate the two helpers.<br><br>Amos<br></blockquote><br>Regards<br>Markus<br></blockquote><br></blockquote><br></blockquote></blockquote>Markus <br><br><br></blockquote></div><br></body></html>