[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re[8]: Virtual Domains & LDAP

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> "uid=USER@COMPANY,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> russell@coker.com.au then the server could know that it should try 
RC> binding as "uid=russell@coker.com.au,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.  bofh@company.com has to be different from
>> bofh@company2.com!
>> 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.



Reply to: