[squid-users] benefits ofusing ext_kerberos_ldap_group_aclinstead of ext_ldap_group_acl

Wed Feb 11 21:28:47 UTC 2015

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

The 3 servers returned by the SRV will be checked. I will take priority and 
weight into account when choosing which ldap server to check firts.

-l  is used when the user has no REALM information and no default REALM is 
provided and as last resort

>>
>>
>>> 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 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.
>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?

The DNS query is done based on the full name (including domain/realm) of the 
user.   e.g. if the user is abc at DOM1  the helper will look for SRV records 
for _ldap._tcp.DOM1 .   If your Kerberos configuration is for DOM2 then you 
won't get valid responses.

Can you send the output created with the -d option ?

>>
>>> 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.
>Thx for the hint regarding nsswitch.conf
>>
>>> 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
>>

Markus 