On Wed, 16 May 2007, James Craig wrote:
On Wed, 16 May 2007, Ralph R???~_ner wrote:
On Sun, May 13, 2007 at 04:11:31PM -0400, James Craig wrote:
[...]
In any case, what I have discovered is that if I have netgroups
used in the passwd file:
[..]
[EMAIL PROTECTED]:x:::::
[EMAIL PROTECTED]:x:::::
[EMAIL PROTECTED]:x:::::
[EMAIL PROTECTED]:x:::::
[EMAIL PROTECTED]:x:::::
[..]
logging in vis ssh takes a LONG time. I see the openldap server
is spinning through what looks like ALL of my netgroups a few times,
and then I finally get a password prompt. I then type in the
password
and wait a while longer (the ldap server does the same thing) and
then I get in. When I removed the netgroups from the password table
the login process speeds up significantly.
Has anyone else experienced this?
Not as such because we have dropped the "compat" style passwd entries
before. What you describe is to be expected though, when you replace NIS
netgroups by LDAP netgroups 1:1.
Basically, netgroup support via LDAP is very inefficient. Unless my
memory fails me, NIS has a) a netgroup-matching operation (i.e. the
match is done server-side) and b) a "reversed" netgroup representation
that is keyed to usernames. So a test if "someuser" is a member of any
of the netgroups listed in your passwd translates into a "tell me
someuser's netgroups" NIS call, a fast search operation in the NIS
server, and a client-side comparison of the result to the netgroup list.
Netgroup via LDAP has neither advantage, so the same test translates
into reading all netgroup data from the server and scanning netgroup
member entries for any appearance of "someuser" and comparing the
matches. This has to be done client-side because the LDAP server does
not know the matching rules for a (user,host,domain) netgroup triple
(which is stored in this textual form, instead of splitting into three
attributes!).
This bites you twice because the nss_ldap is invoked for each of the
authentication and authorization steps of the PAM login.
So you may be able to tune your LDAP server somewhat, and nscd may help
you avoid the second lookup but whatever you do, your login will be
a much more expensive operation than the NIS based one.
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.
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
/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.
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?
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
And have different profiles on each class of machine:
lab machine: (default, everyone can access)
NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=People,dc=cs,dc=rit,dc=edu?sub
faculty: (faculty and system staff)
NS_LDAP_SERVICE_SEARCH_DESC= passwd:
ou=People,ou=Faculty,dc=cs,dc=rit,dc=edu;ou=People,ou=Staff,dc=cs,dc=rit,dc=edu
This would get ugly for me since some of the groups will be temporary,
some groups include students and faculty, and some people shift all
over the place. As far as I can tell, this is NOT going to be the
way to go.
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.
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)))
Once the machine profiles are generated, each user can be given access
to that machine with the right attribute. (This is assuming this will
work-- I will be testing this shortly)
The downside is that I will need to create a bunch of profiles for
the machines.
Am I totally going in the wrong direction?
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?
I still haven't found anything out on this issue...
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.
