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. The only thing I came up with is that there is possible risk with hi-jacking session due to flaw in application, still- I'm missing the big picture here. Or return code 49 is not enough for failed auth?
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.
Thanks, Zdenek
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.
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.
The other alternatives are: -Use a SASL mechanism, and ensure that the LDAP server maps a SASL username to the correct DN -Do DN construction (which has significant disadvantages)
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).
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.
Regards, Buchan
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]
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?
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.
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).
Regards, Buchan
Have a nice evening, Zdenek
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
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
On Thursday 25 June 2009 20:47:46 Zdenek Styblik wrote:
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
After reading the README.LDAP, I didn't see any description of how authentication is done, so I looked, and in src/log_ldap.c, we have this:
void pw_ldap_check(AuthResult * const result, const char *account, const char *password, const struct sockaddr_storage * const sa, const struct sockaddr_storage * const peer) { struct passwd *pw; const char *spwd; /* Stored pwd */ const char *cpwd = NULL; /* Computed pwd */ signed char nocase = 0; /* Insensitive strcmp */
(void) sa; (void) peer; result->auth_ok = 0; if (account == NULL || *account == 0 || password == NULL || (pw = pw_ldap_getpwnam(account, result)) == NULL) { return; } result->auth_ok--; /* -1 */ spwd = pw->pw_passwd; if (strncasecmp(spwd, PASSWD_LDAP_MD5_PREFIX, sizeof PASSWD_LDAP_MD5_PREFIX - 1U) == 0) { spwd += (sizeof PASSWD_LDAP_MD5_PREFIX - 1U); if (strlen(spwd) >= 32U) { nocase++; } cpwd = crypto_hash_md5(password, nocase); } else if (strncasecmp(spwd, PASSWD_LDAP_SHA_PREFIX, sizeof PASSWD_LDAP_SHA_PREFIX - 1U) == 0) { spwd += (sizeof PASSWD_LDAP_SHA_PREFIX - 1U); if (strlen(spwd) >= 40U) { nocase++; } cpwd = crypto_hash_sha1(password, nocase); } else if (strncasecmp(spwd, PASSWD_LDAP_SSHA_PREFIX, sizeof PASSWD_LDAP_SSHA_PREFIX - 1U) == 0) { spwd += (sizeof PASSWD_LDAP_SSHA_PREFIX - 1U); cpwd = crypto_hash_ssha1(password, spwd); } else if (strncasecmp(spwd, PASSWD_LDAP_SMD5_PREFIX, sizeof PASSWD_LDAP_SMD5_PREFIX - 1U) == 0) { spwd += (sizeof PASSWD_LDAP_SMD5_PREFIX - 1U); cpwd = crypto_hash_smd5(password, spwd); } else if (strncasecmp(spwd, PASSWD_LDAP_CRYPT_PREFIX, sizeof PASSWD_LDAP_CRYPT_PREFIX - 1U) == 0) { spwd += (sizeof PASSWD_LDAP_CRYPT_PREFIX - 1U); cpwd = (const char *) crypt(password, spwd); } else if (*password != 0) { cpwd = password; /* Cleartext */ } else { return; /* Refuse null passwords */ } if (cpwd == NULL) { return; } if (nocase != 0) { if (strcasecmp(cpwd, spwd) != 0) { return; } } if (strcmp(cpwd, spwd) != 0) { return; }
IOW, pure-ftpd is retrieving the password hash from LDAP, hashing the password from the user with the same hash (we hope), and comparing the resulting character arrays.
It would have been much easier to bind as the user's DN, and look at the result code ...
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?
I would: 1)File a bug on pure-ftpd, that it should offer an option (my preference would be that this should be the default) to bind as the user to validate the password. 2)Switch to a different FTP server (e.g. proftpd) until this is fixed in pure- ftpd.
Regards, Buchan
Buchan Milne wrote:
On Thursday 25 June 2009 20:47:46 Zdenek Styblik wrote:
After reading the README.LDAP, I didn't see any description of how authentication is done, so I looked, and in src/log_ldap.c, we have this:
Neither did I, but I just assumed/guessed. I didn't have time to look at the source (yet).
void pw_ldap_check(AuthResult * const result,...
IOW, pure-ftpd is retrieving the password hash from LDAP, hashing the password from the user with the same hash (we hope), and comparing the resulting character arrays.
That's what I've expected.
It would have been much easier to bind as the user's DN, and look at the result code ...
Agreed. And I'm very glad to hear that. Thanks for confirmation. I almost know I'm going to be too lazy to implement, but- the proper way is to implement search for dn, right? User with almost no rights, just to search for dn by some parameter (cn/uid/whatever), fetch dn, try to authenticate against fetched dn by user provided password, check error code -> revoke/auth.
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?
I would: 1)File a bug on pure-ftpd, that it should offer an option (my preference would be that this should be the default) to bind as the user to validate the password.
That might be just matter of opinions (security [flame], here we go). But I do agree with you.
2)Switch to a different FTP server (e.g. proftpd) until this is fixed in pure- ftpd.
I see what can be done. Pure-ftpd is somewhat missing groups support and we need this feature at our site. There is some patch for it, but I'd like to have internal support for this, rather than some external script/mechanism. But that's a different story. Thank you for suggestion - point taken.
Regards, Buchan
Thanks for clarification and confirmation on this topic.
Have a nice day, Zdenek
openldap-technical@openldap.org
-
Buchan Milne -
Zdenek Styblik