On Fri, 18 May 2007, Ralph R???~_ner wrote:
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.
Fair enough. I do appreciate the time you have taken to help me out
with this.
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:
After a lot of digging and experimenting, I did figure out what you
were suggesting- and I need the padl.com pam_ldap to do it. I
had been trying to do everything with the native Solaris libraries
and it just doesn't seem possible. Last night I looked through the
padl.com pam_ldap and I think I will save myself a lot of pain and
grief if I just put that on all of my machines.
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.
I started to realize that when testing- I finally got the filter
formatting right but still had some issues with this. I am going
to set this solution path aside and go with padl.com's pam_ldap.
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.
I just came across that too. Thank you for your help!
jim craig
---
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.
