Hey Russell,
Wednesday, June 13, 2001, 4:05:22 PM, you wrote: >> Well, even if you have the user himself bind, you would need an entry >> with sufficient enough permissions to access any other entry. Are you >> proposing adding another entry, like a lesser LDAP Admin, that simply >> doesn't have access to the userPassword attribute of other entries? RC> I am not sure what you are saying here. Well, if I understood you correctly, you said that having the LDAP manager retrieve the userPassword attribute, rather than having the user bind himself, was a security issue because if someone were to recover the proftpd.conf file, they would have the password of the LDAP manager. But even if the user binds himself, won't the LDAP manager need to be specified in LDAPDNInfo? RC> I believe that the usual proceedure is to allow a user to have "write" RC> access to their own userPassword attribute and to have anonymous have RC> "auth" access. "auth" means that anyone who has the password can bind as RC> any entry. If the user supplies a password that allows binding to the RC> entry indicated by their user-name then they are authenticated. RC> The server MAY need privs to search the directory to find the DN, but RC> even that may not be necessary depending on the application. Ok. Maybe I'm incorrect in my previous assertion of needing LDAPDNInfo. RC> Consider the case of users having the DN RC> "[EMAIL PROTECTED],ou=COMPANY,o=ISP" where "ISP" is the name of the ISP, RC> "COMPANY" is "wpi.edu", "coker.com.au", "debian.org" or whatever the RC> domain name is, and "USER" is the user name. If I logged on as RC> [EMAIL PROTECTED] then the server could know that it should try RC> binding as "[EMAIL PROTECTED],ou=coker.com.au,o=isp" and therefore RC> the server wouldn't even need search access! How would it know the "ou=coker.com, o=isp"? Is that info filled in after the uid is found and the dn retrieved? >> RC> If the ProFTPd server binds to the directory then it needs no >> special RC> LDAP access, however it has to send the password to the >> server and this RC> may be intercepted (I believe that the way it's >> setup in the standard RC> Debian packages has it all in clear-text >> always). This can also be RC> considered a security problem. :( >> >> Well, wouldn't the password have to be sent over in clear text anyway? >> That's the nature of FTP without an SSL tunnel. The FTP -> LDAP >> connection is on a localhost anyway. I wonder if you could configure >> it to use SSL LDAP. Probably RC> Proftpd has code to allow SSL LDAP, but it is not enabled in the Debian RC> package because of license issues. You should be able to change a single RC> line in a header file and recompile to get it. What sort of license issues? The whole strong encryption exportation thing? RC> As for FTP SSL, this can be done, there are already ftpd-ssl and ftp-ssl RC> packages in Debian. I don't think that proftpd supports that (yet). I don't think so either, but couldn't proftpd be sent over stunnel or something? >> RC> It should not make any noticable difference where you put your >> search RC> base. However I have not done any performance testing. It >> may make a RC> small difference but certainly won't make a large >> difference. >> >> I would imagine this would make a difference with a search scope of one >> level or something though :-P RC> Last time I looked at the OpenLDAP setup in detail regarding this issue RC> (which was some time ago) it seemed to have a database of objects to RC> sub-objects which would make one-level searches quite fast. I have RC> checked now on my 2.0.11 OpenLDAP installation and it's not there. I had RC> not intentionally turned that off so I'm not sure what's happened. Hmm . . . >> RC> The work is supposed to have gone into Debian and be shared to save >> having RC> the work of independantly maintaining it. It appears not to >> have gone into RC> Debian yet though. RC> Incidentally I recommend writing a policy document specifying the above RC> whenever you do a Linux installation at a corporate site. It's easy to RC> get staff or consultants to produce custom versions of Debian packages, RC> but having the skills to keep updating them with every version is beyond RC> most corporate sites. Things such as minor security enhancements to a RC> FTP server offer no significant competitive advantage and are best RC> published so that new versions can just be installed by APT. Agreed. But would the more proper avenue be to submit security enhancements to the proper software maintainer (in this case, the proftpd team), and see if they'll implement it? >> RC> But just specifying the user name and having the domain inferred is >> a bad RC> idea as you can't have two users with the same account name >> in different RC> domains. [EMAIL PROTECTED] has to be different from >> [EMAIL PROTECTED] >> >> Well, I was figuring all look ups would have to search for uid=user and >> domain=company.com. But two searches would probably be slower anyway. RC> Two searches would probably be slower and would definately be more of a RC> PITA. Writing LDAP filters to search on two attributes isn't that RC> difficult, but when you have to do it on the command line it becomes a RC> real PITA (especially as the meta-characters *|! operate in both the RC> command-line and the LDAP filter syntax). How exactly does the search function work? Say I filtered the searches for user=kevin, domain=wpi.edu. Would it scan the entire DIT and when it finds a match for user=kevin, then check to see if domain=wpi.edu as well? Also, is there anyway to specify a one-hit then end search type of thing? So once the search finds something that meets the criteria, it ends the search? I know there's ways to do this in the slapd.conf file for all searches, but I'm talking more like a temporary thing, so other searches could return more than one value. Thanks. -- Kevin
