[Date Prev][Date Next]
Re: ldap auth from external application
Buchan Milne wrote:
> On Wednesday 24 June 2009 19:59:07 Zdenek Styblik wrote:
>> I'd like to ask why is auth from external applications like eg. ftp
>> server done via proxy user, and not straight with user provided
thank you for your reply. Your assumption is correct.
> I am assuming you are asking why a proxy user is required. Typically, the
> proxy user is *not* used to "authenticate" the user, but to identify the DN to
> bind as. Once the DN has been identified, the password supplied is used to bind
> as the DN that the application determined is correct for the username that was
> Of course, this is in the case of a simple bind.
I can see your point. It's hard to say as I've disabled anonymous sneaks
and peaks into LDAP directory. You can browse, but authenticate first.
Btw use of such user is done in nss-ldap from Padl, isn't it?
One thing came to my mind, and it's - may be I misunderstood binding as
'anonymous' user in "many" applications. Such anonymous bind could be
used to search for correct dn, and then- you've already said what is
next. [but I still refuse anonymous searches through LDAP tree]
> The other alternatives are:
> -Use a SASL mechanism, and ensure that the LDAP server maps a SASL username to
> the correct DN
Well, SASL has its limits - at least for me. Cleartext password, or if
hashed, it's something very specific. Or external passwords (secrets) in
sasldb, which somewhat ruins whole beauty of integration of LDAP. Even
it wouldn't be that hard to pass passwords into sasldb, I'm trying to
stay off the SASL (for now).
> -Do DN construction (which has significant disadvantages)
I didn't understand at first, and I'm not sure if I do. But - do you
mean when users have very different dn, right?
That would be somewhat problematic, yes.
But we have everybody under ou=people, so it's fairly simple and basic
search dn eg. 'uid=%u,ou=people,...' is enough.
>> Could somebody, please, clarify this for me? I'm sure there are really
>> good reasons no to so (straight auth), still I've "found" pros in not
>> having additional user which is capable to read others (even hashed)
>> passwords, and probably no need to be password hash dependent as whole
>> auth would be LDAPs domain.
> This sounds like your application is broken, and is comparing passwords on the
> client side. Most applications like this can be configured to do a BIND to
> validate the password instead, and this gives you a lot more flexibility (e.g.,
> use new password hashes supported by the LDAP server, but not necessarily by
> all applications).
Yeah, it looks so. I can't tell straight away, but if I disable proxy
user access to attribute 'userPassword', then I'm unable to log into ftp
[530 auth failed]. I assume it's just comparing passwords. I could
probably write a "better" authentication module for this application
[btw it's pure-ftpd] :)
> In a decent setup, no DN should need to read passwords to do authentication.
> Maybe you need to provide details of your application and it's configuration.
I was just asking about good practices. I'm facing coding a (sort of)
web site and it just felt odd to do it via proxy user. If it's some
application and it's nothing "problematic", I can adapt (as in case of
Have a nice evening,