"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.
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?!
3) What is the use case for defining -g GROUP@? What is the difference
to -g GROUP (without @)
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.
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
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?
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
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
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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
