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. 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. > 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. 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? 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 [EMAIL PROTECTED]:x::::: lines). Second, for testing, better turn off nscd daemon. 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). My 2 cents :) -- Jean-Yves Migeon Down, not across. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
