[squid-users] benefits of using ext_kerberos_ldap_group_aclinstead of ext_ldap_group_acl

[Markus Moeller]

>>> "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 at 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 at REALM
   a)  Use  values  given  by -g option which contain a @REALM e.g. -g
GROUP1 at REALM:GROUP2 at 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 at REALM and then use values given by
-g option which contain a @REALM e.g. -g GROUP1 at REALM:GROUP2 at 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
>