Re: Re[4]: Virtual Domains & LDAP
On Wednesday 13 June 2001 16:08, Kevin J. Menard, Jr. wrote:
> RC> Other LDAP servers may do things differently, but most LDAP servers
> have RC> taken code from the University of Michigan LDAP server (which
> is what RC> OpenLDAP was based on).
>
> That's okay. I really only care about how OpenLDAP works ;)
Same here.
> RC> @ sign has no inherant problems, but some software might not like
> it.
>
> This does work with ProFTPd. I tried it out. I have still yet to try
> it out with either Cyrus IMAPd or Postfix.
OK, let us know how it goes.
> RC> Proftpd will do a search of "attribute=$1" where $1 is what the
> user enters RC> at the Name: prompt. Then it will read the
> userPassword attribute of that RC> entry or bind as that DN depending
> on how it's configured.
>
> I see this now. Is one method better than the other? The ProFTPd docs
> say that by binding as the user, different encryption methods could be
> supported (not a big deal since I just user SSHA per RFC 2307). But is
> this manner more secure than binding as the LDAP manager to get the
> userPassword attribute?
The REAL difference is that if the ProFTPd server can read the
userPassword attribute then anyone who can get access to that
configuration for the server has access to all the passwords. This can
be considered a security problem.
If the ProFTPd server binds to the directory then it needs no special
LDAP access, however it has to send the password to the server and this
may be intercepted (I believe that the way it's setup in the standard
Debian packages has it all in clear-text always). This can also be
considered a security problem. :(
> RC> No. I mean making the UID include the company. So within the
> RC> "company.com" domain we have an account named "user". This is the
> only RC> way to do it with proftpd!
>
> Ok. Sorry for my density. Usually the simplest of things are the
> hardest for me to understand :-P So what is the account named: "user"
> or
> "user_company.com"? And what are these two search indexes? What
> performance loss would I suffer by setting my search base to just
> "o=my_org" rather than "ou=company.com, o=my_org"?
It should not make any noticable difference where you put your search
base. However I have not done any performance testing. It may make a
small difference but certainly won't make a large difference.
I suggest giving the user the DN of "uid=user_company.com,
ou=company.com, o=my_org" and the uid attribute will have the value of
"user_company.com".
> >> search within the base of "ou=company.com, o=my_org". Because with
> >> the uid=user_company.com, I'm still searching on a single attribute.
> >> I would think if anything, it would be quicker, because I would
> >> already be searching within the correct ou. If you could elaborate
> >> a little more, I would be most gracious. Likewise, I don't have a
> >> great understanding of how index eq and index pres, and what have
> >> you works. I realize it's pretty LDAP distrib specific, but I don't
> >> see much documentation for OpenLDAP in this regards.
> >>
> >> Btw, sorry you got the cross-post. I've scoured the archives for
> >> debian-isp. Has the debian schema files been produced yet? I was
> >> looking at using the allowedService attribute you drafted up
> >> quickly, to give users access to different services (duh?).
>
> RC> I've produced a few drafts but so far no-one has responded to my
> requests RC> for comments on them. So we are all waiting for some
> input from people RC> who know about LDAP and schema...
>
> Any chance you could post them here if you haven't done so already? If
> so, I'll just go search the posts.
I'll send my latest work here again soon.
> >> Also, do you use proftpd by chance? I would like to do virt
> >> hosting,
>
> RC> Yes. One of my clients recently paid for enhancements to Proftpd
> for RC> better support of this.
>
> I realize you won't be able to share this work, but what sort of
> enhancements? And how do you manage uids and gids?
The work is supposed to have gone into Debian and be shared to save
having the work of independantly maintaining it. It appears not to have
gone into Debian yet though.
It is to use LDAP settings to specify which IP addresses are permissable
as source addresses per user. So if you know the IP address of a user
you can prevent access from other IP addresses.
> >> but I don't feel like killing the IP pool :-P I suppose a
> >> user_company.com system would work, but that'd be unnatural to
> >> users,
>
> RC> Why? I've worked for two ISPs doing bulk commercial hosting with
> that RC> scheme and no problems...
>
> I would just think that people would like to remove the trailing
> _company.com, and just have user names, with the namespace inferred. I
> know you don't use the '@' in an email address like system I proposed,
> but which would you see being better? With my method, the user only
> has to use his email address and password for auth, which I think would
> be nice, but I don't know if that would become too ambiguous with
> "mail" attributes.
Email address should be fine.
But just specifying the user name and having the domain inferred is a bad
idea as you can't have two users with the same account name in different
domains. bofh@company.com has to be different from bofh@company2.com!
> >> whereas an email address like naming scheme wouldn't be too bad.
> >> But
>
> RC> Not sure if an @ sign will be accepted by proftpd. Never tried it.
>
> It worked for me, in case anyone else was wondering.
Oh good!
--
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: