Re: [squid-users] benefits of using ext_kerberos_ldap_group_aclinstead of ext_ldap_group_acl
"Amos Jeffries" wrote in message news:54BE3B5C.8040800 at treenet.co.nz... -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). 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 d
Re: [squid-users] benefits of using ext_kerberos_ldap_group_aclinstead of ext_ldap_group_acl
"Amos Jeffries" wrote in message news:54BE3B5C.8040800 at treenet.co.nz... -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. My idea was to have a backup ldap / active directory server. Assumed querying _ldap._tcp.REALM returns 3 ldap servers. Are all 3 ldap servers queried successively if a previous is not reachable? And is server defined by the -l parameter being queried if all '_ldap._tcp.REALM' are not reachable? > > >> 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 Thx, very helpful. > >> 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 Thx, this is clear now as well > > 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. It think I do not fully understand how the determination of the ldap server works. How is the dns query for SRV _ldap._tcp.REALM related to the missing Kerberos configuration? Why does the helper need the principal from the keytab? I am also a bit confused about the _ldap._tcp and the _kerberis._tcp queries. Can you give me an idea how this determination works step for step? > >> 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 hea
Re: [squid-users] benefits of using ext_kerberos_ldap_group_aclinstead of ext_ldap_group_acl
"Amos Jeffries" wrote in message news:54BE3B5C.8040800 at treenet.co.nz... -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. > >> 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 >>
