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.
Thanks.
--
Kevin
Reply to: