"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 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
