LDAP where DN does not include UID attribute

--001636e0b962cdc50204738f98ce
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I have an LDAP server where the DN looks like:

cn=robert fleming,cn=users,dc=abc,dc=example,dc=com

But I would like to authenticate to PostgreSQL using the "uid" LDAP
attribute, which you may notice is *not* in the DN. It seems to me that
PostgreSQL's LDAP support does not allow this.

Other software products I've seen support this by doing an LDAP query
*first*, and then fetching/building the DN from the search result, and then
using that DN to do the bind. Looking at the PostgreSQL source code, it
seems like PostgreSQL expects to be able to do a bind without doing a search
first.

==Examples for reference==
===MediaWiki===
====LocalSettings.php====
$wgLDAPServerNames = array("example"=>"ldap.example.com");
$wgLDAPSearchAttributes = array("example"=>"uid");
$wgLDAPBaseDNs = array("loral"=>"cn=users,dc=abc,dc=example,dc=com");

====LdapAuthentication.php====
see <
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/L dapAuthentication/LdapAuthentication.php?view=markup
>
Look for "function getUserDN"

===Bugzilla===
====params====
%param = (
'LDAPBaseDN' => 'cn=users,dc=ssd,dc=loral,dc=com',
'LDAPbinddn' => '',
'LDAPfilter' => '',
'LDAPmailattribute' => 'mail',
'LDAPserver' => 'ldap.example.com',
'LDAPstarttls' => 0,
'LDAPuidattribute' => 'uid',
....

====LDAP.pm====
see <http://mxr.mozilla.org/bugzilla/source/Bugzilla/Auth/Verify/LDAP.pm>
Look at about line 64 to see that they do a LDAP search before the LDAP
bind.

In contrast, PostgreSQL's backend/libpq/auth.c does ldap_simple_bind_s() but
never does a LDAP search.

Thanks,
Robert

--001636e0b962cdc50204738f98ce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello, I have an LDAP server where the DN looks like: cn=3Dro=
bert fleming,cn=3Dusers,dc=3Dabc,dc=3Dexample,dc=3Dcom But I would l=
ike to authenticate to PostgreSQL using the "uid" LDAP attribute,=
which you may notice is *not* in the DN.=A0 It seems to me that PostgreSQL=
's LDAP support does not allow this. 
 Other software products I've seen support this by doing an LDAP que=
ry *first*, and then fetching/building the DN from the search result, and t=
hen using that DN to do the bind.=A0 Looking at the PostgreSQL source code,=
it seems like PostgreSQL expects to be able to do a bind without doing a s=
earch first. 
 =3D=3DExamples for reference=3D=3D =3D=3D=3DMediaWiki=3D=3D=3D =
=3D=3D=3D=3DLocalSettings.php=3D=3D=3D=3D $wgLDAPServerNames =3D array(&=
quot;example"=3D>"<a href=3D"http://ldap.example.com">ldap.exa=
mple.com</a>"); $wgLDAPSearchAttributes =3D array("example&quo=
t;=3D>"uid"); 
$wgLDAPBaseDNs =3D array("loral"=3D>"cn=3Dusers,dc=3Dabc,=
dc=3Dexample,dc=3Dcom"); =3D=3D=3D=3DLdapAuthentication.php=3D=
=3D=3D=3D see <<a href=3D"http://svn.wikimedia.org/viewvc/mediawiki/t=
runk/extensions/LdapAuthentication/LdapAuthentication.php?vi ew=3Dmarkup">ht=
tp://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Lda pAuthentication=
/LdapAuthentication.php?view=3Dmarkup</a>> 
Look for "function getUserDN" =3D=3D=3DBugzilla=3D=3D=3D<b=
r>=3D=3D=3D=3Dparams=3D=3D=3D=3D %param =3D ( =A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 'LDAPBaseDN' =3D> 'cn=3Dusers,dc=3Dssd,dc=3Dloral,=
dc=3Dcom', =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 'LDAPbinddn' =3D&g=
t; '', 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 'LDAPfilter' =3D> '', =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 'LDAPmailattribute' =3D> 'mai=
l', =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 'LDAPserver' =3D> '=
;<a href=3D"http://ldap.example.com">ldap.example.com</a>', 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 'LDAPstarttls' =3D> 0, =A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 'LDAPuidattribute' =3D> 'uid',<=
br>... =3D=3D=3D=3DLDAP.pm=3D=3D=3D=3D see <<a href=3D"http://=
mxr.mozilla.org/bugzilla/source/Bugzilla/Auth/Verify/LDAP.pm ">http://mxr.mo=
zilla.org/bugzilla/source/Bugzilla/Auth/Verify/LDAP.pm</a>> 
Look at about line 64 to see that they do a LDAP search before the LDAP bin=
d. In contrast, PostgreSQL's backend/libpq/auth.c does ldap_simp=
le_bind_s() but never does a LDAP search. Thanks, Robert 

--001636e0b962cdc50204738f98ce--

Robert Fleming <fleminra [at] gmail.com> writes:
> But I would like to authenticate to PostgreSQL using the "uid" LDAP
> attribute,

What value does that have that would justify doubling the time needed
to authenticate? (I presume two LDAP requests will take about twice
as long as one...)

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--001636e1fb619900990473924b93
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl [at] sss.pgh.pa.us> wrote:

> Robert Fleming <fleminra [at] gmail.com> writes:
> > But I would like to authenticate to PostgreSQL using the "uid" LDAP
> > attribute,
>
> What value does that have that would justify doubling the time needed
> to authenticate? (I presume two LDAP requests will take about twice
> as long as one...)

That's just the way the company LDAP is setup -- it's out of my control
unfortunately.

Our schema used to have the uid in the DN, and I always wrote our enterprise
software to just do the bind without a search. When the LDAP schema
changed, my reaction was the same as yours, but when I saw that Bugzilla,
MediaWiki, etc. accommodate it without flinching, I figured it wasn't too
uncommon, so I changed my own software. Other software that supports it:
Tiki wiki, Apache's mod_authnz_ldap, ejabberd. I think I had to tweak some
Perl for jabberd <jabberd.org> to handle it.

It might be twice as slow, but if PostgreSQL were smart or configurable
enough, it could skip the search when not necessary. So performance needn't
be impacted.

Robert

--001636e1fb619900990473924b93
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <<a href=3D"=
mailto:tgl [at] sss.pgh.pa.us">tgl [at] sss.pgh.pa.us</a>> wrote: <div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"border-left=
: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1e=
x;">
<div class=3D"im">Robert Fleming <<a href=3D"mailto:fleminra [at] gmail.com">=
fleminra [at] gmail.com</a>> writes: 
> But I would like to authenticate to PostgreSQL using the "uid&quo=
t; LDAP 
> attribute, 
 
</div>What value does that have that would justify doubling the time needed=
 
to authenticate? =A0(I presume two LDAP requests will take about twice 
as long as one...)</blockquote></div> That's just the way the compan=
y LDAP is setup -- it's out of my control unfortunately. Our sch=
ema used to have the uid in the DN, and I always wrote our enterprise softw=
are to just do the bind without a search.=A0 When the LDAP schema changed, =
my reaction was the same as yours, but when I saw that Bugzilla, MediaWiki,=
etc. accommodate it without flinching, I figured it wasn't too uncommo=
n, so I changed my own software.=A0 Other software that supports it: Tiki w=
iki, Apache's mod_authnz_ldap, ejabberd.=A0 I think I had to tweak some=
Perl for jabberd <<a href=3D"http://jabberd.org">jabberd.org</a>> to=
handle it. 
 It might be twice as slow, but if PostgreSQL were smart or configurable=
enough, it could skip the search when not necessary.=A0 So performance nee=
dn't be impacted. Robert 

--001636e1fb619900990473924b93--

On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <fleminra [at] gmail.com> wrote:
> On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl [at] sss.pgh.pa.us> wrote:
>>
>> Robert Fleming <fleminra [at] gmail.com> writes:
>> > But I would like to authenticate to PostgreSQL using the "uid" LDAP
>> > attribute,
>>
>> What value does that have that would justify doubling the time needed
>> to authenticate? =A0(I presume two LDAP requests will take about twice
>> as long as one...)
>
> That's just the way the company LDAP is setup -- it's out of my control
> unfortunately.
>
> Our schema used to have the uid in the DN, and I always wrote our enterpr=
ise
> software to just do the bind without a search.=A0 When the LDAP schema
> changed, my reaction was the same as yours, but when I saw that Bugzilla,
> MediaWiki, etc. accommodate it without flinching, I figured it wasn't too
> uncommon, so I changed my own software.=A0 Other software that supports i=
t:
> Tiki wiki, Apache's mod_authnz_ldap, ejabberd.=A0 I think I had to tweak =
some
> Perl for jabberd <jabberd.org> to handle it.
>
> It might be twice as slow, but if PostgreSQL were smart or configurable
> enough, it could skip the search when not necessary.=A0 So performance ne=
edn't
> be impacted.

On a large ldap schema it's WAY more than twice as slow. A Search is
about 10 to 20 times slower on most ldap servers. I've seen machines
handling 1,000 or more auths per second slow to a crawl due to this
type of change.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Tue, Sep 15, 2009 at 12:27 AM, Robert Fleming
<fleming [at] cs.washington.edu> wrote:
> On Mon, Sep 14, 2009 at 4:56 PM, Scott Marlowe <scott.marlowe [at] gmail.com>
> wrote:
>>
>> On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <fleminra [at] gmail.com>
>> wrote:
>> > On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl [at] sss.pgh.pa.us> wrote:
>> >>
>> >> Robert Fleming <fleminra [at] gmail.com> writes:
>> >> > But I would like to authenticate to PostgreSQL using the "uid" LDAP
>> >> > attribute,
>> >>
>> >> What value does that have that would justify doubling the time needed
>> >> to authenticate? =A0(I presume two LDAP requests will take about twice
>> >> as long as one...)
>> >
>> > That's just the way the company LDAP is setup -- it's out of my control
>> > unfortunately.
>> >
>> > Our schema used to have the uid in the DN, and I always wrote our
>> > enterprise
>> > software to just do the bind without a search.=A0 When the LDAP schema
>> > changed, my reaction was the same as yours, but when I saw that
>> > Bugzilla,
>> > MediaWiki, etc. accommodate it without flinching, I figured it wasn't
>> > too
>> > uncommon, so I changed my own software.=A0 Other software that supports
>> > it:
>> > Tiki wiki, Apache's mod_authnz_ldap, ejabberd.=A0 I think I had to twe=
ak
>> > some
>> > Perl for jabberd <jabberd.org> to handle it.
>> >
>> > It might be twice as slow, but if PostgreSQL were smart or configurable
>> > enough, it could skip the search when not necessary.=A0 So performance
>> > needn't
>> > be impacted.
>>
>> On a large ldap schema it's WAY more than twice as slow. =A0A Search is
>> about 10 to 20 times slower on most ldap servers. I've seen machines
>> handling 1,000 or more auths per second slow to a crawl due to this
>> type of change.
>
> I'll come up with a patch to support search+bind a la Apache, etc., and
> retain the existing logic as an optimized sub-case. =A0I think the cost o=
f an
> additional conditional branch instruction will be negligible w.r.t. the L=
DAP
> bind. =A0I suppose this should go to the development list.
> I mainly just wanted to confirm with this list that this is a scenario th=
at
> is not currently covered by PostgreSQL.

Yeah, it's really a question of scalability. If a app is constantly
authenticating then it could be a problem. The problem stems from
authentication being a bolt on for LDAP, instead of a primary
function, like kerberos. If it was just username and password, check
out a token, you'd have it easy(ier?), right?

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--001636b2be57922ff0047392cb1e
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 14, 2009 at 4:56 PM, Scott Marlowe <scott.marlowe [at] gmail.com>wrote:

> On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <fleminra [at] gmail.com>
> wrote:
> > On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl [at] sss.pgh.pa.us> wrote:
> >>
> >> Robert Fleming <fleminra [at] gmail.com> writes:
> >> > But I would like to authenticate to PostgreSQL using the "uid" LDAP
> >> > attribute,
> >>
> >> What value does that have that would justify doubling the time needed
> >> to authenticate? (I presume two LDAP requests will take about twice
> >> as long as one...)
> >
> > That's just the way the company LDAP is setup -- it's out of my control
> > unfortunately.
> >
> > Our schema used to have the uid in the DN, and I always wrote our
> enterprise
> > software to just do the bind without a search. When the LDAP schema
> > changed, my reaction was the same as yours, but when I saw that Bugzilla,
> > MediaWiki, etc. accommodate it without flinching, I figured it wasn't too
> > uncommon, so I changed my own software. Other software that supports it:
> > Tiki wiki, Apache's mod_authnz_ldap, ejabberd. I think I had to tweak
> some
> > Perl for jabberd <jabberd.org> to handle it.
> >
> > It might be twice as slow, but if PostgreSQL were smart or configurable
> > enough, it could skip the search when not necessary. So performance
> needn't
> > be impacted.
>
> On a large ldap schema it's WAY more than twice as slow. A Search is
> about 10 to 20 times slower on most ldap servers. I've seen machines
> handling 1,000 or more auths per second slow to a crawl due to this
> type of change.
>

First, as I mentioned, I'm not proposing to impose a "search" operation on
all users. It could be a configuration option, or it might be possible for
PostgreSQL to be smart enough to know that it doesn't need to do a search.
FWIW, a quick look at the Apache source code makes me think that they are
not concerned with this overhead.

Second (only for the sake of argument), I could imagine designing an LDAP
server for which this particular search operation is no slower than a bind.
(This I say without the benefit of having implemented or administered any
LDAP server.)

I will probably make the mod myself because of course I won't see this
feature in a release in the near future, in any case, and it's an easy
change. My goal of writing to this list was mainly to confirm that
PostgreSQL is currently *not* able to handle this scenario. Based on the
conversation so far I take it that that is a correct assessment?

Thanks,
Robert

--001636b2be57922ff0047392cb1e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

 <div class=3D"gmail_quote">On Mon, Sep 14, 2009 at 4:56 PM, Scott M=
arlowe <<a href=3D"mailto:scott.marlowe [at] gmail.com">sco=
tt.marlowe [at] gmail.com</a>> wrote: <blockquote class=3D"gmail_qu=
ote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0p=
t 0.8ex; padding-left: 1ex;">
<div><div></div><div class=3D"h5">On Mon, Sep 14, 2009 at 5:47 PM, Robert F=
leming <<a href=3D"mailto:fleminra [at] gmail.com">fleminra [at] gmail.com</a>>=
wrote: 
> On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <<a href=3D"mailto:tgl [at] ss=
s.pgh.pa.us">tgl [at] sss.pgh.pa.us</a>> wrote: 
>> 
>> Robert Fleming <<a href=3D"mailto:fleminra [at] gmail.com">fleminra [at] =
gmail.com</a>> writes: 
>> > But I would like to authenticate to PostgreSQL using the &quo=
t;uid" LDAP 
>> > attribute, 
>> 
>> What value does that have that would justify doubling the time nee=
ded 
>> to authenticate? =A0(I presume two LDAP requests will take about t=
wice 
>> as long as one...) 
> 
> That's just the way the company LDAP is setup -- it's out of m=
y control 
> unfortunately. 
> 
> Our schema used to have the uid in the DN, and I always wrote our ente=
rprise 
> software to just do the bind without a search.=A0 When the LDAP schema=
 
> changed, my reaction was the same as yours, but when I saw that Bugzil=
la, 
> MediaWiki, etc. accommodate it without flinching, I figured it wasn=
9;t too 
> uncommon, so I changed my own software.=A0 Other software that support=
s it: 
> Tiki wiki, Apache's mod_authnz_ldap, ejabberd.=A0 I think I had to=
tweak some 
> Perl for jabberd <<a href=3D"http://jabberd.org" target=3D"_blank">=
jabberd.org</a>> to handle it. 
> 
> It might be twice as slow, but if PostgreSQL were smart or configurabl=
e 
> enough, it could skip the search when not necessary.=A0 So performance=
needn't 
> be impacted. 
 
</div></div>On a large ldap schema it's WAY more than twice as slow. =
=A0A Search is 
about 10 to 20 times slower on most ldap servers. I've seen machines<br=
>
handling 1,000 or more auths per second slow to a crawl due to this 
type of change. 
</blockquote></div> First, as I mentioned, I'm not proposing to impo=
se a "search" operation on all users.=A0 It could be a configurat=
ion option, or it might be possible for PostgreSQL to be smart enough to kn=
ow that it doesn't need to do a search.=A0 FWIW, a quick look at the Ap=
ache source code makes me think that they are not concerned with this overh=
ead. 
 Second (only for the sake of argument), I could imagine designing an LD=
AP server for which this particular search operation is no slower than a bi=
nd.=A0 (This I say without the benefit of having implemented or administere=
d any LDAP server.) 
 I will probably make the mod myself because of course I won't see t=
his feature in a release in the near future, in any case, and it's an e=
asy change.=A0 My goal of writing to this list was mainly to confirm that P=
ostgreSQL is currently *not* able to handle this scenario.=A0 Based on the =
conversation so far I take it that that is a correct assessment? 
 Thanks, Robert 

--001636b2be57922ff0047392cb1e--

LDAP where DN does not include UID attribute

Re: LDAP where DN does not include UID attribute

Re: LDAP where DN does not include UID attribute

Re: LDAP where DN does not include UID attribute

Re: LDAP where DN does not include UID attribute

Re: LDAP where DN does not include UID attribute