OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Contrib/5856
Full headers

From: kartik_subbarao@hp.com
Subject: adauth overlay contribution
Compose comment
Download message
State:
0 replies:
8 followups: 1 2 3 4 5 6 7 8

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 12 Dec 2008 19:31:46 GMT
From: kartik_subbarao@hp.com
To: openldap-its@OpenLDAP.org
Subject: adauth overlay contribution
Full_Name: Kartik Subbarao
Version: 2.4
OS: Red Hat Enterprise Linux
URL: ftp://ftp.openldap.org/incoming/adauth.tar.gz
Submission from: (NULL) (76.99.180.78)


As discussed with Howard Chu, HP is contributing the code for an Active
Directory Authentication overlay (written by Neil Dunbar) to OpenLDAP.

The adauth overlay provides passthrough authentication to Active Directory for
LDAP simple bind operations. The local LDAP entry referenced in the bind
operation is mapped to its counterpart in the Active Directory, an LDAP bind
operation is performed against Active Directory, and results are returned based
on the results of that remote operation. If a local userPassword attribute is
populated for the entry, it is used instead of the AD authentication.


Followup 1

Download message
Date: Mon, 15 Dec 2008 18:38:49 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: kartik_subbarao@hp.com
Cc: openldap-its@openldap.org
Subject: Re: (ITS#5856) adauth overlay contribution
On Fri, Dec 12, 2008 at 07:31:47PM +0000, kartik_subbarao@hp.com wrote:

> As discussed with Howard Chu, HP is contributing the code for an Active
> Directory Authentication overlay (written by Neil Dunbar) to OpenLDAP.
> 
> The adauth overlay provides passthrough authentication to Active Directory
for
> LDAP simple bind operations. The local LDAP entry referenced in the bind
> operation is mapped to its counterpart in the Active Directory, an LDAP
bind
> operation is performed against Active Directory, and results are returned
based
> on the results of that remote operation. If a local userPassword attribute
is
> populated for the entry, it is used instead of the AD authentication.

This is very good news, as it deals with a common requirement without
having to configure saslauthd.

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.

It is worth noting that this overlay raises issues similar to those
raised by the contributed adpwc/extpwc module - see ITS#5042. In this
case the access to AD is via LDAP rather than Kerberos, but most of
the arguments are similar. 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.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------



Followup 2

Download message
Subject: Re: (ITS#5856) adauth overlay contribution
From: Neil Dunbar <neil.dunbar@hp.com>
To: openldap-its@OpenLDAP.org
Cc: kartik_subbarao@hp.com, Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Date: Tue, 16 Dec 2008 14:52:30 +0000
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. If you define default_domain
to be some rubbish, and default_realm to be the remote AD server, then
everything else (including the remote bind DN) can be fetched from the DIT.
But I haven't tried this. But what wouldn't get passed back is any
information flowing from password controls - and that's an annoyance, which
is why I didn't generalise the code (and because HP had no business need
for that approach anyway).

Cheers,

Neil
-- 
SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited
Registered Office:
 Cain Road, Bracknell, Berks
 RG12 1HN                             Registered No: 690597 England



Followup 3

Download message
Subject: Re: (ITS#5856) adauth overlay contribution
From: Neil Dunbar <neil.dunbar@hp.com>
To: openldap-its@OpenLDAP.org
Cc: kartik_subbarao@hp.com, Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Date: Wed, 17 Dec 2008 13:04:08 +0000
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.

The tarball is uploaded as adauth-20081217.tar.gz

Neil
-- 
SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited
Registered Office:
 Cain Road, Bracknell, Berks
 RG12 1HN                             Registered No: 690597 England



Followup 4

Download message
Subject: Re: (ITS#5856) adauth overlay contribution
From: Neil Dunbar <neil.dunbar@hp.com>
To: openldap-its@OpenLDAP.org
Cc: kartik_subbarao@hp.com, Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Date: Fri, 27 Feb 2009 14:29:26 +0000
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.

Cheers,

Neil
-- 
SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited
Registered Office:
 Cain Road, Bracknell, Berks
 RG12 1HN                             Registered No: 690597 England



Followup 5

Download message
Subject: Re: (ITS#5856) adauth overlay contribution
From: Neil Dunbar <neil.dunbar@hp.com>
To: openldap-its@OpenLDAP.org
Cc: subbarao@computer.org, Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Date: Wed, 18 Mar 2009 13:12:57 +0000
Still nothing? I can resubmit if the tarball has rotted away to nothing
on the incoming server. ;-)

I don't mind if the code needs rewriting (it almost certainly does!), or
if it isn't felt to be the right fit for contrib, but a little feedback
would be helpful in getting things right.

Cheers,

Neil
-- 
SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited
Registered Office:
 Cain Road, Bracknell, Berks
 RG12 1HN                             Registered No: 690597 England



Followup 6

Download message
Date: Wed, 18 Mar 2009 10:31:35 -0700
From: Howard Chu <hyc@symas.com>
To: neil.dunbar@hp.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#5856) adauth overlay contribution
neil.dunbar@hp.com wrote:
> Still nothing? I can resubmit if the tarball has rotted away to nothing
> on the incoming server. ;-)
>
> I don't mind if the code needs rewriting (it almost certainly does!), or
> if it isn't felt to be the right fit for contrib, but a little feedback
> would be helpful in getting things right.

Sorry, we've been in bugfix-only mode for the past couple months. After this 
next (2.4.16) release is frozen we'll get back to working on new features.
>
> Cheers,
>
> Neil


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



Followup 7

Download message
Date: Thu, 09 Apr 2009 12:33:22 -0700
From: Howard Chu <hyc@symas.com>
To: neil.dunbar@hp.com
CC: openldap-its@openldap.org
Subject: 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/



Followup 8

Download message
From: "Dunbar, Neil" <neil.dunbar@hp.com>
To: Howard Chu <hyc@symas.com>
CC: "openldap-its@openldap.org" <openldap-its@openldap.org>
Date: Tue, 14 Apr 2009 09:54:26 +0000
Subject: RE: (ITS#5856) adauth overlay contribution
Howard,

Fair comments - the package was basically wrapped up from an internal packa=
ge used in HP (which indeed has internal processes to map ED accounts to th=
eir equivalent AD DNs). The desire was to donate the package rather than se=
e it live only in HP - at least someone might find a use for it. Clearly yo=
u think that the friction of installation limits its utility - and that's a=
 perfectly fine observation.

A lot of the "mapping" name stuff was legacy from when there was a lot more=
 functionality in the package, since it did NTLM authentication as well, to=
 a multitude of NT4 domain controllers. In that world, there really was a m=
apping, but that's not true in the simplified world of Adauth.

In light of the comments, it's probably better to drop the package in its e=
ntirety until I have time to address the structural issues highlighted.

Cheers,

Neil


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org