[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: local accounts unavailable during ldap issue



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 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 redhat com
> https://www.redhat.com/mailman/listinfo/pam-list

_______________________________________________
Pam-list mailing list
Pam-list redhat com
https://www.redhat.com/mailman/listinfo/pam-list



--
Later,
Jon
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]