Just wanted to give one final update (mostly for anybody who ends up searching the archives) about the resolution. Turns my nss_ldap updates were a basic autoconf tools issue. I had previously used the incorrect configure options and running "make clean" and re-running configure didn't help. I finally deleted the source, re-unarchived it, and build + install. Worked great.
So to recap, for you people running RHEL:
1. Grab latest version of nss_ldap from padl http://www.padl.com/download/nss_ldap.tgz
2. Extract it. Configure with the following options: (atleast worked for me)
./configure --enable-paged-results --enable-rfc2307bis --enable-schema-mapping --with-ldap-lib=openldap
3. make; make install
4. Make minor updates to your /etc/ldap.conf per Josh's suggestion.
echo 'nss_initgroups_ignoreusers root,ldap' >> /etc/ldap.conf
Also update the various timeouts to your liking.
Should be golden.
-- Jon Miller
On 10/17/06, Jon Miller <jonebird@xxxxxxxxx> wrote:
Thank you!
I had to upgrade my version of nss_ldap. I was at version 207 and according to the changelog that option was introduced at version 245.
Unfortunately, I have updated built and installed the latest version and now 'getent passwd' returns nothing. But I think I'll be able to work through it.
-- Jon Miller--On 10/16/06, Joshua Miller < joshua@xxxxxxxxxxxxxxxxx> wrote:You problem is indeed a very common one. The reason that your login is
hanging is that although root is a local account, nss_ldap is looking to
find out how many LDAP groups that root belongs to. To get around this,
you can employ the nss_initgroups_ignoreusers directive to force
nss_ldap to not query ldap for root's group membership:
nss_initgroups_ignoreusers root,ldap
As you can see above, I include root and the ldap user so that OpenLDAP
starts up quickly. I also include three additional directives which aid
in the smooth operation of my servers when OpenLDAP is not available.
timelimit 15 # Search timelimit
bind_timelimit 15 # Bind timelimit - abort after 15 seconds if fail
to bind
bind_policy soft # After failing to bind once, do not retry for
this request
I hope you find something here that may work for you.
- Josh, RHCE
Jon Miller wrote:
> Hopefully this is a easy/common problem which I've simply not hit upon
> yet. I have several RHEL 3.0 machines which have setup to authenticate
> to a pair of openldap servers. Normally things are fine, but lately
> we've had some issues with our LDAP servers where a query would hang in
> the middle. Even worse, the replication server too displayed the same
> behavior. Ouch, no logins.
> Ideally this scenario would only affect employees logging into the
> servers since our applications use locally setup accounts. However, this
> is not the case and our LDAP issue can actually affect local account
> authentication as well.
>
> Let me jump straight into a quick test case matrix: ( here, I have
> changed my /etc/ldap.conf to point to a couple of bogus servers which
> are merely running netcat to simulate a "hung" ldap query)
> NSS Queried Successful | Comments
> LDAP LDAP ? Login? |
> -----------------------------------------------------------------------------|--------------------
> root login No No Yes |
> pam_unix indirectly querying ldap via nss?
> ldap login No Yes No |
> "illegal user" without nss.
> root login Yes Yes No |
> queries ldap before giving prompt; ssh timeout.
> ldap login Yes Yes Yes |
> obvious. (only with correct servers in ldap.conf, ofcourse)
> legend: "NSS LDAP": No means I only left "files" for the various
> dbs(passwd, shadow, group). Yes means "ldap" is listed second in the
> /etc/nsswitch.conf.
>
> The case I am interested in solving is the third. While trying to ssh
> into the machine, you are never prompted a password because it is busy
> querying LDAP. Compare that with my first test case with ldap left out
> of the nsswitch.conf and the root login succeeds without _ever_
> attempting to query our LDAP server.
>
> Here is what my /etc/pam.d/system-auth file looks like:
> #%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 debug
> auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
> audit
> auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
> debug
> auth required /lib/security/$ISA/pam_deny.so debug
>
> account required /lib/security/$ISA/pam_unix.so debug
> account sufficient /lib/security/$ISA/pam_localuser.so
> account required /lib/security/$ISA/pam_ldap.so
>
> password required /lib/security/$ISA/pam_cracklib.so retry=3 type=
> password sufficient /lib/security/$ISA/pam_unix.so nullok
> use_authtok shadow
> password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
> password required /lib/security/$ISA/pam_deny.so
>
> session requisite /lib/security/$ISA/pam_mkhomedir.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
>
> I have methodically tested various scenarios and at this point believe
> pam_unix is, one way or another, querying LDAP during it's
> pam_sm_authenticate routine. But I have yet to either prove or disprove
> that theory. I have the latest (RHEL 3.0) pam-0.75-69 rpm on the machine.
>
> --
> Thanks,
> Jon
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pam-list mailing list
> Pam-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/pam-list
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
Later,
Jon
--
Later,
Jon
_______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
