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
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
Re[4]: Virtual Domains & LDAP
Hey Russell, Wednesday, June 13, 2001, 8:21:36 AM, you wrote: RC> Firstly I've replied to this with the list CC'd as I think that other RC> people are likely to benefit from the answers and it seems that there is RC> nothing secret being discussed. I hope you don't mind. No problem. I was just trying to cut down on the list traffic. RC> The OpenLDAP server uses some sort of hash, it uses the GNU DBM library or RC> equivalent libraries for indexing each attribute separately. Nifty. 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 ;) 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. 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? >> RC> Searching for "uid=user_company.com" with a search base of >> RC> "ou=company.com, o=my_org" requires searching through two indexes >> which RC> isn't as fast. But if the uid attribute has a unique value >> (which it RC> will have if it is the user-name concatenated with the >> company name) then RC> you can just search by the attribute value. >> >> Ok. This is where I lose you, unless you meant uid=user. And then to 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"? >> 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. >> 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? >> 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. >> 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. >> realistically, should I just follow in the steps of ISPMan, and allow >> ftp access to one user per domain? RC> No, that sucks. That's what I was thinking :-P Thanks a lot for all the info. -- Kevin
Re[4]: Virtual Domains & LDAP
Hey Russell, Wednesday, June 13, 2001, 8:21:36 AM, you wrote: RC> Firstly I've replied to this with the list CC'd as I think that other RC> people are likely to benefit from the answers and it seems that there is RC> nothing secret being discussed. I hope you don't mind. No problem. I was just trying to cut down on the list traffic. RC> The OpenLDAP server uses some sort of hash, it uses the GNU DBM library or RC> equivalent libraries for indexing each attribute separately. Nifty. 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 ;) 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. 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? >> RC> Searching for "uid=user_company.com" with a search base of >> RC> "ou=company.com, o=my_org" requires searching through two indexes >> which RC> isn't as fast. But if the uid attribute has a unique value >> (which it RC> will have if it is the user-name concatenated with the >> company name) then RC> you can just search by the attribute value. >> >> Ok. This is where I lose you, unless you meant uid=user. And then to 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"? >> 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. >> 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? >> 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. >> 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. >> realistically, should I just follow in the steps of ISPMan, and allow >> ftp access to one user per domain? RC> No, that sucks. That's what I was thinking :-P Thanks a lot for all the info. -- Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact
