Hey Russell,
Wednesday, June 13, 2001, 12:24:42 PM, you wrote:
RC> OK, let us know how it goes.
Will do.
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?
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> 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> I suggest giving the user the DN of "uid=user_company.com,
RC> ou=company.com, o=my_org" and the uid attribute will have the value of
RC> "user_company.com".
Ok. Glad we're on the same page ;)
RC> I'll send my latest work here again soon.
Great. I can't wait.
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> It is to use LDAP settings to specify which IP addresses are permissable
RC> as source addresses per user. So if you know the IP address of a user
RC> you can prevent access from other IP addresses.
That could be useful ;)
RC> Email address should be fine.
Great. Like I said, I'll have to see how Cyrus IMAP and Postfix like it :-p
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.
Thanks again for the help/info.
--
Kevin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
