Re: Re[6]: Virtual Domains & LDAP
On Wednesday 13 June 2001 20:40, Kevin J. Menard, Jr. wrote:
> RC> The REAL difference is that if the ProFTPd server can read the
> userPassword RC> attribute then anyone who can get access to that
> configuration for the RC> server has access to all the passwords. This
> can be considered a security RC> problem.
>
> 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?
I am not sure what you are saying here.
I believe that the usual proceedure is to allow a user to have "write"
access to their own userPassword attribute and to have anonymous have
"auth" access. "auth" means that anyone who has the password can bind as
any entry. If the user supplies a password that allows binding to the
entry indicated by their user-name then they are authenticated.
The server MAY need privs to search the directory to find the DN, but
even that may not be necessary depending on the application.
Consider the case of users having the DN
"uid=USER@COMPANY,ou=COMPANY,o=ISP" where "ISP" is the name of the ISP,
"COMPANY" is "wpi.edu", "coker.com.au", "debian.org" or whatever the
domain name is, and "USER" is the user name. If I logged on as
russell@coker.com.au then the server could know that it should try
binding as "uid=russell@coker.com.au,ou=coker.com.au,o=isp" and therefore
the server wouldn't even need search access!
> 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
Proftpd has code to allow SSL LDAP, but it is not enabled in the Debian
package because of license issues. You should be able to change a single
line in a header file and recompile to get it.
As for FTP SSL, this can be done, there are already ftpd-ssl and ftp-ssl
packages in Debian. I don't think that proftpd supports that (yet).
> 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
Last time I looked at the OpenLDAP setup in detail regarding this issue
(which was some time ago) it seemed to have a database of objects to
sub-objects which would make one-level searches quite fast. I have
checked now on my 2.0.11 OpenLDAP installation and it's not there. I had
not intentionally turned that off so I'm not sure what's happened.
> 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.
Incidentally I recommend writing a policy document specifying the above
whenever you do a Linux installation at a corporate site. It's easy to
get staff or consultants to produce custom versions of Debian packages,
but having the skills to keep updating them with every version is beyond
most corporate sites. Things such as minor security enhancements to a
FTP server offer no significant competitive advantage and are best
published so that new versions can just be installed by APT.
> 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.
Two searches would probably be slower and would definately be more of a
PITA. Writing LDAP filters to search on two attributes isn't that
difficult, but when you have to do it on the command line it becomes a
real PITA (especially as the meta-characters *|! operate in both the
command-line and the LDAP filter syntax).
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: