[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5856) adauth overlay contribution



neil.dunbar@hp.com wrote:
> On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote:
>> Andrew:
>>> One suggestion following a very quick scan of the code: I think it
>>> would be worth bringing the warning about turning off TLS checks
>>> into the manual page.
>>
>> Agreed. Done.
>>
>>> In particular, there is no reason for this
>>> to be AD-specific and it should be easy to adapt it to authenticate
>>> against any [collection of] remote LDAP servers.
>>
>> Actually, it may not be AD specific as is.
>
> Are we any further forward to getting this rolled into contrib? Is there
> more we need to do to make it fit better? The tarball has been sitting
> there a while, it would seem.

I've reviewed the package and have some comments.

I'm puzzled by the design of this overlay; in ActiveDirectory a user can exist 
in only one domain and there is a one-to-one mapping between their domain name 
and the suffix of their LDAP DN. As such, the lookup of the
adauth_domain_attribute seems clumsy and unnecessary.

The adauth_default_realm and adauth_default_domain terms are confusing. Your 
adauth_default_realm item is really just the hostname of a particular server. 
Your use of the word "realm" is basically inconsistent with common usage of 
this term.

The usage for adauth_mapping is clumsy; you could simply have made it a list 
of LDAP URLs and not bothered with an external file. Is there a commonly used 
external file that other software uses, that prompted this approach?

The description of adauth_dn_attribute is misleading. Is it a DN, or is it a 
userPrincipalName? In what way is this a "map" at all? Examining the code, it 
is simply "the DN of the user to Bind against on the remote LDAP server" - it 
is not a map, nor is it a userPrincipalName.

I wonder in what context this overlay is easily used. If I have 100,000 users 
in my LDAP directory, I don't want to maintain 100,000 AD_DN attributes for 
them; I want a simple rule that actually performs an algorithmic mapping of 
their local DN to their remote DN. I suppose using an AD_DN attribute for the 
users whose DNs don't easily map might be a good fallback, but it shouldn't be 
the primary mechanism for linking a local user to a remote user. I would 
re-use the authz-regexp machinery here.

It seems there's a lot of AD-specific overhead in this code, for what is 
really a pretty simple and generic operation - passthru Bind to a remote LDAP 
server. I would have used the back-ldap/chain.c code instead, which would also 
provide connection pooling and the other benefits of back-ldap's already 
comprehensive support for communicating with remote LDAP servers.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/