On Sat, Oct 21, 2006 at 10:30:48AM +0200, MIGEON Jean-Yves wrote: > On Fri, Oct 20, 2006 at 08:41:44PM -0400, Roberto C. Sanchez wrote: > > OK. So, I don't normally make it a habit of replying to 14 month old > > emails, but I just recently figured this out, so I thought I'd comment > > for the benefit of people searching for the solution. > > Very kind of you. > No problem. > After all the hard work for setting up a full > distributed authentication and accounting service with ldap/kerberos, I > decided to write a full detailed how to, explaining all the necessary > steps for setting it up. > > I'm pretty sure it will be finished in a few weeks. Since I didn't find > such info on the net, I hope this how-to will help some admin with this > tricky system. Oh man, ldap/kerberos caused me real headaches, but it > was worth the try :o If it could avoid the hassle, so be it. > Excellent. I would be interested in seeing it. Regards, -Roberto > > On Sat, Aug 06, 2005 at 12:38:42PM +0200, Jean-Yves Migeon wrote: > > > However, it doesn't seem to work as intended. > > > > > I recently setup LDAP and also wanted to restrict which users could > > login to certain hosts. So, what I did was use the host field in LDAP. > > So, my main workstation is miami and if I want a particular user to be > > able to login to miami, I add a field "host: miami" to the LDAP entry > > for that user. If I want a user to be able to log in to any host which > > authenticates against the directory, then I just put "host: *" for that > > user. > > > > Once that is done, placing the following line in /etc/libnss-ldap.conf > > and /etc/pam_ldap.conf made it work: > > > > pam_filter |(host=miami)(host=\*) > > > > This works if you do not have too many hosts. If you have many, say at > > a university with many computer labs, then this could get very annoying > > very quickly. In that case, you can probably add "host: lab1group" and > > then put something like this: > > > > pam_filter |(host=hostname1)(host=lab1group)(host=\*) > > > > Note, I have not tested this last setup, but it should work. > > I eventually managed to make it work. I thought I had reported it to the > ML, but it seems not. > You may have and I may have missed it. I did not search the archives. > Your solution is quite a nice one. Instead of controlling from a > group_member attribute, you add a filter to the ldap scheme in NSS and > pam, so users that do not obey to the filter's rule won't be able to log in. > I guess that the restricted users won't be listed on miami through a > "# getent passwd" , is that right? > Actually, this is incorrect. Since the user is in the directory, he/she will show up even if he/she is not authorized to log in to the host. > Anyway, I'll give some details, in case people would be interested in > getting it work through a pam_groupdn attribute in pam_ldap.conf . > > First, be sure to have such a line in your /etc/pam.d/service_name (in > our case, /etc/login): > > "account required pam_ldap.so" > > If not, restricted users will still be able to login, since pam_unix.so > do not understand the pam_groupdn attribute (with NIS, access policy is > directly controlled in /etc/passwd and /etc/shadow - or /etc/master.passwd - with +@mygroup:x::::: lines). > > Second, for testing, better turn off nscd daemon. > This is a good tip. I forgot to do this and puzzled for a while when my changes did not seem to take effet. > Thirdly, just add these to /etc/pam_ldap.conf: > pam_groupdn cn=<hostname>,ou=<hosts>,dc=bde,dc=espci,dc=fr > pam_member_attribute member # or anything that suits your ldap schema > > For both examples, I do not think that adding such rules to > libnss-ldap.conf is necessary. Libnss-ldap is mainly used for the name > service switch (passwd, group, shadow, hosts) and distributing it without > restriction to a full subnet is quite necessary: it will avoid many > headaches for those that use NFS (or any auth_sys based services). > > To make it simplier, I would use libnss-ldap.conf with pam_filter to > distribute different lists of hosts and users on a particular subnet (we > are doing so in my eng. school), and fine tuning ACLs for each host with pam_ldap.conf (quite convenient if you use ldap as a DNS replacement). > > Please note that this is just an advice... > > However, using pam_filter in libnss_ldap.conf is a very well thought solution, > since pam_groupdn doesn't exist for NSS (as expected, access should be > controlled and granted through pam). > Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com
Attachment:
signature.asc
Description: Digital signature