For RHEL3,
change:
account required /lib/security/$ISA/pam_unix.so broken_shadow
to:
account sufficient /lib/security/$ISA/pam_unix.so broken_shadow
Keep in mind that this will make the account stack succeed in most cases
before it hits pam_ldap, which means pam_ldap won't be used for enforcing
account policy. See below for an alternate method, if this matters for you.
For RHEL4, disconnected root login _should_ already be working, beause of
the extra line:
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100
quiet
As you can probably tell, this line makes the stack succeed if the user's
uid is less than 100, which is of course true for root.
The alternate RHEL3 fix would be to manually compile and deploy
pam_succeed_if.so on your RHEL3 clients, and use the same system-auth you
currently have on your RHEL4 clients.
----- Original Message -----
From: "MJD Shop Account" <mjdshop@xxxxxxxxxxxxx>
To: "George Holbert" <gholbert@xxxxxxxxxxxx>; "General discussion list for
the Fedora Directory server project." <fedora-directory-users@xxxxxxxxxx>
Sent: Wednesday, March 07, 2007 8:13 PM
Subject: Re: ldap too many connections from
clients? following ldap even for local accounts?
My RH3 system-auth is as follows:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so broken_shadow
account [default=bad success=ok user_unknown=ignore]
/lib/security/$ISA/pam_ldap.so
account [default=bad success=ok user_unknown=ignore]
/lib/security/$ISA/pam_krb5.so
#account required /lib/security/$ISA/pam_deny.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok
use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
password sufficient /lib/security/$ISA/pam_krb5.so use_authtok
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session optional /lib/security/$ISA/pam_ldap.so
session optional /lib/security/$ISA/pam_krb5.so
My RH4 version is the same, with this difference:
--- system-auth.RH3 2006-10-25 22:49:19.000000000 -0400
+++ system-auth.RH4 2006-10-25 22:42:05.000000000 -0400
@@ -8,6 +8,7 @@
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so broken_shadow
+account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100
quiet
account [default=bad success=ok user_unknown=ignore]
/lib/security/$ISA/pam_ldap.so
account [default=bad success=ok user_unknown=ignore]
/lib/security/$ISA/pam_krb5.so
#account required /lib/security/$ISA/pam_deny.so
-----Original Message-----
From: George Holbert <gholbert@xxxxxxxxxxxx>
Sent: Mar 7, 2007 8:42 PM
To: MJD Shop Account <mjdshop@xxxxxxxxxxxxx>, "General discussion list for
the Fedora Directory server project." <fedora-directory-users@xxxxxxxxxx>
Subject: Re: ldap too many connections from
clients? following ldap even for local accounts?
If a machine is disconnected from the network, a login attempt as
'root' user (with local passwd file entry and password) fails.
...
I think I need to configure something such that the nsswitch.conf
entry tells it to stop if it finds the 'files' entry and not proceed
to the 'ldap' entry. I thought this would happen by default.
At least for authentication, this behavior depends also on your PAM
config.
You need to make sure that the auth and account stacks will succeed for
local accounts (e.g., root) without asking pam_ldap.
What's in your /etc/pam.d/system-auth files on your RHEL3 and RHEL4
clients?
MJD Shop Account wrote:
I'm having some odd ldap issues with connection or lack thereof to
ldap server when nsswitch.conf and pam.d/system-auth are configured to
used FDS ldap server.
I'm running both RHEL3 and RHEL4 clients. My servers are RHEL4 update
4 and FDS 1.0.4. My /etc/ldap.conf is configured with two host
names. I've noticed these issues:
* If a machine is disconnected from the network, a login attempt
as 'root' user (with local passwd file entry and password)
fails. The system appears to accept the password, but sits for
maybe a minute, then dumps you back to the login prompt. I've
had to boot off rescue CD and shell in to remove 'ldap' from
the /etc/nsswitch.conf file to get around this in some instances.
My relevant /etc/ldap.conf entries are:
passwd: files ldap
shadow: files
group: files ldap
netgroup: files ldap
* I noticed that a anhy randomly chosen client has a few
connections to the ldap server that persist. The connections
are tied to processes that also should have local entries only
in the local /etc/passwd files. Here's an example:
# netstat -a | grep ldap
tcp 38 0 clienthostname:32771 serverhostname:ldap
CLOSE_WAIT
# fuser 32771/tcp
here: 32771
32771/tcp: 3729
# ps -ef | grep 3729 | grep -v grep
ntp 3729 1 0 Feb23 ? 00:00:00 ntpd -u ntp:ntp
-p /var/run/ntpd.pid -g
#
* I notice that doing a "netstat -a" on the server that most
clients are using takes a long time. It spits out a bunch,
then slows down when reporting the entries that are ESTABLISHED
ldap connections:
tcp 0 0 ldapserver:ldap ldapclient:35908 ESTABLISHED
I see that some clients have very many connections, I would
expect just one or two. Here's one client that had a whole
bunch, most disappeared before I could capture this bash shell
command output. This output is for jobs associated with ports
connecting to ldap server:
# for i in `netstat -a | grep ldap | cut -d: -f2 | cut -d" "
-f1`; do for j in `(fuser $i/tcp | cut -b 23-26)`; do ps -ef |
grep $j | grep -v grep; done; done
xfs 2726 1 0 Feb20 ? 00:00:00 xfs -droppriv
-daemon
root 3138 3031 0 Feb20 ? 00:00:00
/usr/bin/gdm-binary bell-style none
root 3418 3138 0 18:32 ? 00:00:02 /usr/X11R6/bin/X
:0 -auth /var/gdm/:0.Xauth vt7
gdm 3430 3138 0 18:32 ? 00:00:00
/usr/bin/gdmgreeter
root 2477 2617 0 18:22 ? 00:00:01 sshd: root@pts/0
root 2481 2477 0 18:22 pts/0 00:00:00 -tcsh
I ran a similar command on a client computer where the user is
running a lot of jobs, I got 53 lines of output. Basically
every job is maintaining an ldap connection, I guess.
* I think I need to configure something such that the
nsswitch.conf entry tells it to stop if it finds the 'files'
entry and not proceed to the 'ldap' entry. I thought this would
happen by default.
* I think the above problem is possibly leading to many more ldap
connections than are necessary which in turn may be causing
performance issues on the server, ALTHOUGH the cpu load and
memory load does not appear inordinately heavy
* I tried running nscd (for caching the info) once, it seemed to
cause too many problems so I turned it off. I have tried
something like implementing pam_ccache, I don't think it would
help the too-many-connections, just the issue with no logins
when off the net.
* Here's my /etc/ldap.conf minus the usual comment lines, I'm
doing anonymous binds. Maybe there's some keepalive flag that
should be set or unset?:
host server1 server2
base dc=example,dc=com
ldap_version 3
scope sub
bind_timelimit 10
pam_lookup_policy yes
pam_password exop
nss_base_passwd ou=People,dc=example,dc=com?one
nss_base_group ou=Group,dc=example,dc=com?one
nss_base_services ou=Services,dc=example,dc=com?one
nss_base_aliases ou=Aliases,dc=example,dc=com?one
nss_base_netgroup ou=Netgroup,dc=example,dc=com?one
ssl start_tls
tls_checkpeer yes
tls_cacertfile /usr/share/ssl/certs/servercert.pem
tls_ciphers TLSv1
pam_password md5
Any suggestions on what I might be doing wrong are greatly appreciated!
-Marty
------------------------------------------------------------------------
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
