Buchan Milne wrote:
On Thursday 25 June 2009 16:58:10 Zdenek Styblik wrote:
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.
Evening!
Yeah, of course. Sorry, I've got carried away. Understood.
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 ....
I've read on SALS back and forth, and it just didn't fit. I have SSL/TLS enforced wherever possible - I think it's good for now. And as you say, some mechanisms were supported, some weren't...
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).
No problem:
LDAPServer 127.0.0.1 LDAPPort 389 LDAPBaseDN dc=turnovfree,dc=net LDAPBindDN cn=Pureftp,dc=turnovfree,dc=net LDAPBindPW verySecretPassword LDAPDefaultUID 2000 LDAPDefaultGID 2000 LDAPFilter (&(objectClass=posixAccount)(uid=\L)) LDAPUseTLS True
This user has access to 'userPassword'. Documentation says: "- LDAPBindDN is the DN we should bind the server for simple authentication. If you don't need authentication (ie. anonymous users can browse that part of the LDAP directory), just remove that line."
But we need to bind to the LDAP, or we won't be allowed to read anything at all.
Anyway. I've tried to delete 'LDAPBindDN' and here goes result: slapd[14940]: conn=1490 op=1 BIND dn="" method=128 .... slapd[14940]: conn=1513 op=2 SEARCH RESULT tag=101 err=50 nentries=0 text=
...and it doesn't work. err=50 is insufficient access, but - isn't an empty dn equivalent for anonymous?
Regards, Buchan
Regards, Zdenek