On Thursday 25 June 2009 16:58:10 Zdenek Styblik wrote:
Buchan Milne wrote:
On Wednesday 24 June 2009 19:59:07 Zdenek Styblik wrote:
Hi,
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 credentials.
Hello,
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 supplied.
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]
But, the distinction here is that authentication doesn't require the proxy user to have access to any special attributes, they in fact require minimal access just to be able to identify the DN from the username they were supplied with.
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).
SASL-GSSAPI against Heimdal with Heimdal users stored in LDAP is one solution, depending on your requirements. SASL-EXTERNAL with SSL client certificates is another. However, many application support neither ....
-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?
eg. uid=charlie,ou=sales,dc=domain,dc=tld eg. uid=foxy,ou=level1,ou=technicians,ou=railway,...
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.
Different containers is only one issue, assuming that the naming attribute(s) is the "username" is another.
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 pure-ftpd).
Please supply the LDAP-specific parts of your pure-ftpd configuration. I am sure I have had pure-ftpd authenticate by BINDing, but I don't have configs handy (where I run FTP authenticating against LDAP at them moment I am using proftpd).
Regards, Buchan