local accounts unavailable during ldap issue

[Jon Miller]

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 at itsecureadmin.com> 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 at redhat.com
> > https://www.redhat.com/mailman/listinfo/pam-list
>
> _______________________________________________
> Pam-list mailing list
> Pam-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pam-list
>



-- 
Later,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pam-list/attachments/20061017/e2543390/attachment.htm>