On Thu, May 17, 2007 at 10:45:52AM -0400, James Craig wrote: > On Wed, 16 May 2007, James Craig wrote: > > >On Wed, 16 May 2007, Ralph Rö�~_ner wrote: [...] > >> > >>My suggestion is, avoid the netgroup references in your passwd entirely. > >>Just allow NSS to list all your LDAP users but disallow access to > >>userPassword fields. Make up an LDAP group that contains all LDAP users > >>that > >>should be able to log into the host (the union of the netgroups from > >>your passwd file) and use pam_ldap to allow access to this group of > >>users. Stack it with pam_unix, which does the same for local users (but > >>not for LDAP users because you have hidden the password hashes). The > >>result should be a great speed up for the login procedure because of > >>very selective LDAP searches. The downside is that all LDAP users are > >>visible on every machine (which may or may not trouble you) and that you > >>have to maintain extra groups to implement the login restrictions (but > >>you may be able to drop some of your netgroups, depending on where else > >>you use them). > > I have done some looking into this, and I understand the pieces of > what you are suggesting but I can't figure out how to put them all > together. I may be missing something based on what you suggested.
Well, the reason for being a bit unspecific here is that I am not up to date yet with the particulars for the Solaris 9/10 pam_ldap and client profile implementation. So I cannot talk at the "put this line into that file" level. > > At the moment, my nsswitch.conf file has these lines: > passwd: compat > passwd_compat: ldap > > I assume need to change that to > passwd: files ldap Yes. > > /var/ldap/ldap_client_file looks like this: > NS_LDAP_FILE_VERSION= 2.0 > NS_LDAP_SERVERS= manetheren.cs.rit.edu, tear.cs.rit.edu > NS_LDAP_SEARCH_BASEDN= dc=cs,dc=rit,dc=edu > NS_LDAP_AUTH= tls:simple > NS_LDAP_SEARCH_REF= TRUE > NS_LDAP_SEARCH_SCOPE= one > NS_LDAP_SEARCH_TIME= 30 > NS_LDAP_CACHETTL= 43200 > NS_LDAP_PROFILE= tear_test > NS_LDAP_CREDENTIAL_LEVEL= proxy > NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=People,dc=cs,dc=rit,dc=edu?one > NS_LDAP_SERVICE_SEARCH_DESC= group: ou=Group,dc=cs,dc=rit,dc=edu?one > NS_LDAP_SERVICE_SEARCH_DESC= shadow: ou=People,dc=cs,dc=rit,dc=edu?one > NS_LDAP_SERVICE_SEARCH_DESC= netgroup: ou=Netgroup,dc=cs,dc=rit,dc=edu?one > NS_LDAP_BIND_TIME= 2 > > > > I am still unsure what you are meaning by putting everyone who should > have access to the machine into a group, or how to get the system to > only accept users in that group. Hmm, my experience so far is mainly with the padl.com pam_ldap implementation, and that allows to specifiy a group dn for access control. It works with a groupOfUniqueNames like to one you show here: > > my first stab at this was to do something like: > > dn: cn=Faculty,ou=groups,dc=cs,dc=rit,dc=edu > objectclass: top > objectclass: groupOfUniqueNames > cn: Faculty > ou groups > uniqueMember: uid=ProfPlum, ou=People,dc=cs,dc=rit,dc=edu > uniqueMember: uid=MissScarlet, ou=People,dc=cs,dc=rit,dc=edu > > but I can't quite figure out how to get the client machine to check > for the user's inclusion of this group. Ie, if this machine is a > faculty only machine, how do I limit the access to them? I had expected Solaris to provide a setting to achieve this. But a quick look at the online resources did not turn one up. This may mean that this way is not open to Solaris clients - can any Solaris expert make a definite statement? > > my second thought was to break users into groups like this: > > ou=People,ou=Faculty,dc=cs,dc=rit,dc=edu > ou=People,ou=Students,dc=cs,dc=rit,dc=edu > ou=People,ou=Staff,dc=cs,dc=rit,dc=edu [...] But that is awkward, just as you say. > > So I did a bit more looking, and thought I could try another route: > If I create an attribute to add to each user, I can then grant each > user various attributes that will be sought on a machine. That is an alternative (or rather, inverse) approach, denoting group membership in the account entities. If you have to work through account visibility (because explicit group restriction is impossible) then this is the way to go. > each user would have some of these added to their object: > > machineAccess: faculty > machineAccess: cluster > > and for the various client machines create profiles for them that > include various filters: > > lab machine: (default, everyone can access) > NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=People,dc=cs,dc=rit,dc=edu?one > > faculty: (faculty and system staff) > NS_LDAP_SERVICE_SEARCH_DESC= passwd: > ou=People,dc=cs,dc=rit,dc=edu?one?(&(&(objectClass=posixAccount)(uid=username))(|(machineAccess=faculty)(machineAccess=systemstaff))) The (uid=username) part is extraneous, remember that this filter will also be used for listing all (visible) accounts on the machine and the username will be unset in that case. The posixAccount restriction is probably redundant. [...] > The downside is that I will need to create a bunch of profiles for > the machines. Well, one for every access scenario. You can reuse profiles for several machines, or so the ldapclient(1M) command reference suggests. > Am I totally going in the wrong direction? No, this should work fine. > > > > Do you know (or anyone, off hand) if keeping netgroups for machines > > in the dfstab will have the same impact? Are the netgroups checked > > regularly, or only at mount time? Should I look for other > > options when it comes to allowing NFS access to a set of machines? NFS share access lists are checked at mount time, hence those checks may be quite slow without causing harm. Indeed, the share_nfs(1M) reference only lists hostname, IP (or subnet), and netgroup as options for share access restrictions, so you are stuck with the netgroups for now. Ralph R��ner --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
