I tried playing with this under RH4 and thought it was not work, although it turns out I needed to reboot to get it recognized (is there a way to re-load pam after changing system-auth?) Changing the pam_unix.so line to 'sufficient' instead of 'required' worked in either the case of having the pam_succeed_if.so' line present or commented out. Leaving that line in, and leaving the pam_unix.so as 'required' also worked, but taking out pam_succeed_if.so and leaving pam_unix.so 'required' failed. And, I'm pretty sure having both pam_succeed_if.so present and having pam_unix.so 'required' failed too, until I rebooted. That is to say, given the machine was up and talking to ldap, if I just unplugged the network cable without rebooting, it failed for me. Since this was the setup before (ie not an issue with PAM recognizing a change) this still concerns me, but at least I know a reboot will get me out of any bind of not being able to log in as root. By the way, you might have noticed I had pam_deny.so commented out. I forget why, but I remember testing and thinking either it didn't work with that in, or made no sense to me. Would I be right in suspecting I should be adding it back in if I make pam_unix.so sufficient instead of required? If I don't will it allow anyone in? If I understand what's going on now, since nsswitch.conf has, for instance, 'passwd' with 'files ldap', the PAM setup is hitting ldap twice, once via pam_unix.so which sees the ldap by way off the nsswitch.conf nss_ldap.so, and then again if it were to invoke pam_ldap.so directly. This seems somewhat redundant, but I don't see a way out of it since I'm pretty sure all hell breaks loose if you don't have ldap in nsswitch.conf (since most regular users are defined on the ldap directory). ULtimately my goal is this: system accounts like root and other locally defined accounts take precedence over ldap, if they are defined locally and have a local password, it does not need to go through ldap or kerberos. On the other hand, because we are transitioning account management, I do have local accounts for users with locked local passwords, and I want the kerberos password to be effective. This seems to work in the current setup, I guess I need to verify it still does if I make this change. -----Original Message----- >From: George Holbert <gholbert at broadcom.com> >Sent: Mar 8, 2007 1:33 AM >To: MJD Shop Account <mjdshop at earthlink.net>, "General discussion list for the Fedora Directory server project." <fedora-directory-users at redhat.com> >Subject: Re: ldap too many connections from clients? following ldap even for local accounts? > >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 at earthlink.net> >To: "George Holbert" <gholbert at broadcom.com>; "General discussion list for >the Fedora Directory server project." <fedora-directory-users at redhat.com> >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 at broadcom.com> >>>Sent: Mar 7, 2007 8:42 PM >>>To: MJD Shop Account <mjdshop at earthlink.net>, "General discussion list for >>>the Fedora Directory server project." <fedora-directory-users at redhat.com> >>>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 at 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 at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>> >>> >>> >>> >> >> >> > >
