allowing local accounts when LDAP is unavailable?

[r.stricklin]

Folks;

I'm running pam_ldap 180 on SuSE SLES 10 SP2. I just discovered that
when the LDAP clients cannot access the LDAP server (for example, when
the network goes down), users that are defined locally (i.e. root)
cannot log in until LDAP becomes available again. This is a problem if,
for example, LDAP cannot be reached because of a network configuration
problem on the client.

Apr 30 13:08:19 vm-ldap-2 login[1854]: pam_ldap: ldap_starttls_s: Can't
contact LDAP server

This text appears on the console:

Error in service module

I tried adding ignore_authinfo_unavailable to the options following
pam_ldap.so in all the config files which refer to it. It didn't or
change the behavior in any obvious way.

Is this a bug in pam_ldap, or am I misunderstanding what
ignore_authinfo_unavailable is designed to do? More importantly, what
can I do to allow locally defined users to log in while LDAP is
unavailable?

Thanks!

ok
r.

[Howard Chu]

Stricklin, Raymond J wrote:

>
> Folks;
>
> I'm running pam_ldap 180 on SuSE SLES 10 SP2. I just discovered that
> when the LDAP clients cannot access the LDAP server (for example, when
> the network goes down), users that are defined locally (i.e. root)
> cannot log in until LDAP becomes available again. This is a problem if,
> for example, LDAP cannot be reached because of a network configuration
> problem on the client.
>
> Apr 30 13:08:19 vm-ldap-2 login[1854]: pam_ldap: ldap_starttls_s: Can't
> contact LDAP server
>
> This text appears on the console:
>
> Error in service module
>
> I tried adding ignore_authinfo_unavailable to the options following
> pam_ldap.so in all the config files which refer to it. It didn't or
> change the behavior in any obvious way.
>
> Is this a bug in pam_ldap, or am I misunderstanding what
> ignore_authinfo_unavailable is designed to do? More importantly, what
> can I do to allow locally defined users to log in while LDAP is
> unavailable?

Sounds like you just need to tweak the success config in pam.conf - I use
"sufficient" and it just falls back to pam_unix if pam_ldap fails.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

[r.stricklin]

 

> -----Original Message-----
> From: Howard Chu [mailto:hyc@...]
> > what can I do to allow locally defined users to log in while LDAP is

> > unavailable?
>
> Sounds like you just need to tweak the success config in
> pam.conf - I use "sufficient" and it just falls back to
> pam_unix if pam_ldap fails.

Here are the relevant parts of my pam config:

account required pam_ldap.so  ignore_unknown_user
ignore_authinfo_unavail
account required pam_unix2.so

auth required   pam_env.so
auth sufficient pam_unix2.so
auth sufficient pam_ldap.so  use_first_pass ignore_authinfo_unavail
auth required   pam_deny.so

password required pam_pwcheck.so nullok
password required pam_ldap.so    try_first_pass ignore_unknown_user
ignore_authinfo_unavail
password required pam_unix2.so   nullok use_authtok

session required pam_limits.so
session optional pam_ldap.so   ignore_authinfo_unavail
session required pam_unix2.so


The 'ignore_authinfo_unavail' options were all added today. It works the
same in this situation with or without.

I wonder if it's failing in 'account'. It seems like I had to have it
the way I have it, to make something important work correctly. I may
have to dig back through my notes. I think it may have been related to
LDAP password policy enforcement.

ok
r.

[jlintz]

I too am running into this same issue on centos 5.3.  Here is the
revelant information from my pam setup

auth        required      pam_env.so
auth        required      pam_listfile.so onerr=fail item=group
sense=allow file=/etc/ldapgroups
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass
use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

- Justin Lintz



On Thu, Apr 30, 2009 at 7:21 PM, Stricklin, Raymond J
<raymond.j.stricklin@...> wrote:

>
>
>> -----Original Message-----
>> From: Howard Chu [mailto:hyc@...]
>> > what can I do to allow locally defined users to log in while LDAP is
>
>> > unavailable?
>>
>> Sounds like you just need to tweak the success config in
>> pam.conf - I use "sufficient" and it just falls back to
>> pam_unix if pam_ldap fails.
>
> Here are the relevant parts of my pam config:
>
> account required pam_ldap.so  ignore_unknown_user
> ignore_authinfo_unavail
> account required pam_unix2.so
>
> auth required   pam_env.so
> auth sufficient pam_unix2.so
> auth sufficient pam_ldap.so  use_first_pass ignore_authinfo_unavail
> auth required   pam_deny.so
>
> password required pam_pwcheck.so nullok
> password required pam_ldap.so    try_first_pass ignore_unknown_user
> ignore_authinfo_unavail
> password required pam_unix2.so   nullok use_authtok
>
> session required pam_limits.so
> session optional pam_ldap.so   ignore_authinfo_unavail
> session required pam_unix2.so
>
>
> The 'ignore_authinfo_unavail' options were all added today. It works the
> same in this situation with or without.
>
> I wonder if it's failing in 'account'. It seems like I had to have it
> the way I have it, to make something important work correctly. I may
> have to dig back through my notes. I think it may have been related to
> LDAP password policy enforcement.
>
> ok
> r.
>

[jlintz]

Some more information,

It appears it's never timing out when trying to connect to the ldap
server and falling back to local users.  It just keeps trying even
though I have set a 15 second timeout on the bind connection to ldap


- Justin Lintz



On Fri, May 1, 2009 at 4:55 PM, Justin Lintz <jlintz@...> wrote:

> I too am running into this same issue on centos 5.3.  Here is the
> revelant information from my pam setup
>
> auth        required      pam_env.so
> auth        required      pam_listfile.so onerr=fail item=group
> sense=allow file=/etc/ldapgroups
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        requisite     pam_succeed_if.so uid >= 500 quiet
> auth        sufficient    pam_ldap.so use_first_pass
> auth        required      pam_deny.so
>
> account     required      pam_unix.so broken_shadow
> account     sufficient    pam_succeed_if.so uid < 500 quiet
> account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
> account     required      pam_permit.so
>
> password    requisite     pam_cracklib.so try_first_pass retry=3
> password    sufficient    pam_unix.so md5 shadow nullok try_first_pass
> use_authtok
> password    sufficient    pam_ldap.so use_authtok
> password    required      pam_deny.so
>
> session     optional      pam_keyinit.so revoke
> session     required      pam_limits.so
> session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
> session     [success=1 default=ignore] pam_succeed_if.so service in
> crond quiet use_uid
> session     required      pam_unix.so
> session     optional      pam_ldap.so
>
> - Justin Lintz
>
>
>
> On Thu, Apr 30, 2009 at 7:21 PM, Stricklin, Raymond J
> <raymond.j.stricklin@...> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Howard Chu [mailto:hyc@...]
>>> > what can I do to allow locally defined users to log in while LDAP is
>>
>>> > unavailable?
>>>
>>> Sounds like you just need to tweak the success config in
>>> pam.conf - I use "sufficient" and it just falls back to
>>> pam_unix if pam_ldap fails.
>>
>> Here are the relevant parts of my pam config:
>>
>> account required pam_ldap.so  ignore_unknown_user
>> ignore_authinfo_unavail
>> account required pam_unix2.so
>>
>> auth required   pam_env.so
>> auth sufficient pam_unix2.so
>> auth sufficient pam_ldap.so  use_first_pass ignore_authinfo_unavail
>> auth required   pam_deny.so
>>
>> password required pam_pwcheck.so nullok
>> password required pam_ldap.so    try_first_pass ignore_unknown_user
>> ignore_authinfo_unavail
>> password required pam_unix2.so   nullok use_authtok
>>
>> session required pam_limits.so
>> session optional pam_ldap.so   ignore_authinfo_unavail
>> session required pam_unix2.so
>>
>>
>> The 'ignore_authinfo_unavail' options were all added today. It works the
>> same in this situation with or without.
>>
>> I wonder if it's failing in 'account'. It seems like I had to have it
>> the way I have it, to make something important work correctly. I may
>> have to dig back through my notes. I think it may have been related to
>> LDAP password policy enforcement.
>>
>> ok
>> r.
>>
>

[wrogers]

You don't have to do anything with pam to get failover to /etc/passwd
if you have an LDAP outage, just use proper ordering of
/etc/nsswitch.conf

Wes

On Fri, May 1, 2009 at 16:57, Justin Lintz <jlintz@...> wrote:

> Some more information,
>
> It appears it's never timing out when trying to connect to the ldap
> server and falling back to local users.  It just keeps trying even
> though I have set a 15 second timeout on the bind connection to ldap
>
>
> - Justin Lintz
>
>
>
> On Fri, May 1, 2009 at 4:55 PM, Justin Lintz <jlintz@...> wrote:
>> I too am running into this same issue on centos 5.3.  Here is the
>> revelant information from my pam setup
>>
>> auth        required      pam_env.so
>> auth        required      pam_listfile.so onerr=fail item=group
>> sense=allow file=/etc/ldapgroups
>> auth        sufficient    pam_unix.so nullok try_first_pass
>> auth        requisite     pam_succeed_if.so uid >= 500 quiet
>> auth        sufficient    pam_ldap.so use_first_pass
>> auth        required      pam_deny.so
>>
>> account     required      pam_unix.so broken_shadow
>> account     sufficient    pam_succeed_if.so uid < 500 quiet
>> account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
>> account     required      pam_permit.so
>>
>> password    requisite     pam_cracklib.so try_first_pass retry=3
>> password    sufficient    pam_unix.so md5 shadow nullok try_first_pass
>> use_authtok
>> password    sufficient    pam_ldap.so use_authtok
>> password    required      pam_deny.so
>>
>> session     optional      pam_keyinit.so revoke
>> session     required      pam_limits.so
>> session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
>> session     [success=1 default=ignore] pam_succeed_if.so service in
>> crond quiet use_uid
>> session     required      pam_unix.so
>> session     optional      pam_ldap.so
>>
>> - Justin Lintz
>>
>>
>>
>> On Thu, Apr 30, 2009 at 7:21 PM, Stricklin, Raymond J
>> <raymond.j.stricklin@...> wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Howard Chu [mailto:hyc@...]
>>>> > what can I do to allow locally defined users to log in while LDAP is
>>>
>>>> > unavailable?
>>>>
>>>> Sounds like you just need to tweak the success config in
>>>> pam.conf - I use "sufficient" and it just falls back to
>>>> pam_unix if pam_ldap fails.
>>>
>>> Here are the relevant parts of my pam config:
>>>
>>> account required pam_ldap.so  ignore_unknown_user
>>> ignore_authinfo_unavail
>>> account required pam_unix2.so
>>>
>>> auth required   pam_env.so
>>> auth sufficient pam_unix2.so
>>> auth sufficient pam_ldap.so  use_first_pass ignore_authinfo_unavail
>>> auth required   pam_deny.so
>>>
>>> password required pam_pwcheck.so nullok
>>> password required pam_ldap.so    try_first_pass ignore_unknown_user
>>> ignore_authinfo_unavail
>>> password required pam_unix2.so   nullok use_authtok
>>>
>>> session required pam_limits.so
>>> session optional pam_ldap.so   ignore_authinfo_unavail
>>> session required pam_unix2.so
>>>
>>>
>>> The 'ignore_authinfo_unavail' options were all added today. It works the
>>> same in this situation with or without.
>>>
>>> I wonder if it's failing in 'account'. It seems like I had to have it
>>> the way I have it, to make something important work correctly. I may
>>> have to dig back through my notes. I think it may have been related to
>>> LDAP password policy enforcement.
>>>
>>> ok
>>> r.
>>>
>>
>

[jlintz]

nssswitch.conf is set to files ldap, for passwd, shadow and group, yet
the problem still exists.
- Justin Lintz



On Fri, May 1, 2009 at 10:16 PM, Weston Rogers <wrogers@...> wrote:

> You don't have to do anything with pam to get failover to /etc/passwd
> if you have an LDAP outage, just use proper ordering of
> /etc/nsswitch.conf
>
> Wes
>
> On Fri, May 1, 2009 at 16:57, Justin Lintz <jlintz@...> wrote:
>> Some more information,
>>
>> It appears it's never timing out when trying to connect to the ldap
>> server and falling back to local users.  It just keeps trying even
>> though I have set a 15 second timeout on the bind connection to ldap
>>
>>
>> - Justin Lintz
>>
>>
>>
>> On Fri, May 1, 2009 at 4:55 PM, Justin Lintz <jlintz@...> wrote:
>>> I too am running into this same issue on centos 5.3.  Here is the
>>> revelant information from my pam setup
>>>
>>> auth        required      pam_env.so
>>> auth        required      pam_listfile.so onerr=fail item=group
>>> sense=allow file=/etc/ldapgroups
>>> auth        sufficient    pam_unix.so nullok try_first_pass
>>> auth        requisite     pam_succeed_if.so uid >= 500 quiet
>>> auth        sufficient    pam_ldap.so use_first_pass
>>> auth        required      pam_deny.so
>>>
>>> account     required      pam_unix.so broken_shadow
>>> account     sufficient    pam_succeed_if.so uid < 500 quiet
>>> account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
>>> account     required      pam_permit.so
>>>
>>> password    requisite     pam_cracklib.so try_first_pass retry=3
>>> password    sufficient    pam_unix.so md5 shadow nullok try_first_pass
>>> use_authtok
>>> password    sufficient    pam_ldap.so use_authtok
>>> password    required      pam_deny.so
>>>
>>> session     optional      pam_keyinit.so revoke
>>> session     required      pam_limits.so
>>> session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
>>> session     [success=1 default=ignore] pam_succeed_if.so service in
>>> crond quiet use_uid
>>> session     required      pam_unix.so
>>> session     optional      pam_ldap.so
>>>
>>> - Justin Lintz
>>>
>>>
>>>
>>> On Thu, Apr 30, 2009 at 7:21 PM, Stricklin, Raymond J
>>> <raymond.j.stricklin@...> wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Howard Chu [mailto:hyc@...]
>>>>> > what can I do to allow locally defined users to log in while LDAP is
>>>>
>>>>> > unavailable?
>>>>>
>>>>> Sounds like you just need to tweak the success config in
>>>>> pam.conf - I use "sufficient" and it just falls back to
>>>>> pam_unix if pam_ldap fails.
>>>>
>>>> Here are the relevant parts of my pam config:
>>>>
>>>> account required pam_ldap.so  ignore_unknown_user
>>>> ignore_authinfo_unavail
>>>> account required pam_unix2.so
>>>>
>>>> auth required   pam_env.so
>>>> auth sufficient pam_unix2.so
>>>> auth sufficient pam_ldap.so  use_first_pass ignore_authinfo_unavail
>>>> auth required   pam_deny.so
>>>>
>>>> password required pam_pwcheck.so nullok
>>>> password required pam_ldap.so    try_first_pass ignore_unknown_user
>>>> ignore_authinfo_unavail
>>>> password required pam_unix2.so   nullok use_authtok
>>>>
>>>> session required pam_limits.so
>>>> session optional pam_ldap.so   ignore_authinfo_unavail
>>>> session required pam_unix2.so
>>>>
>>>>
>>>> The 'ignore_authinfo_unavail' options were all added today. It works the
>>>> same in this situation with or without.
>>>>
>>>> I wonder if it's failing in 'account'. It seems like I had to have it
>>>> the way I have it, to make something important work correctly. I may
>>>> have to dig back through my notes. I think it may have been related to
>>>> LDAP password policy enforcement.
>>>>
>>>> ok
>>>> r.
>>>>
>>>
>>
>

[wrogers]

You need to set it to ldap first, then files.

Wes

On Sat, May 2, 2009 at 21:01, Justin Lintz <jlintz@...> wrote:

> nssswitch.conf is set to files ldap, for passwd, shadow and group, yet
> the problem still exists.
> - Justin Lintz
>
>
>
> On Fri, May 1, 2009 at 10:16 PM, Weston Rogers <wrogers@...> wrote:
>> You don't have to do anything with pam to get failover to /etc/passwd
>> if you have an LDAP outage, just use proper ordering of
>> /etc/nsswitch.conf
>>
>> Wes
>>
>> On Fri, May 1, 2009 at 16:57, Justin Lintz <jlintz@...> wrote:
>>> Some more information,
>>>
>>> It appears it's never timing out when trying to connect to the ldap
>>> server and falling back to local users.  It just keeps trying even
>>> though I have set a 15 second timeout on the bind connection to ldap
>>>
>>>
>>> - Justin Lintz
>>>
>>>
>>>
>>> On Fri, May 1, 2009 at 4:55 PM, Justin Lintz <jlintz@...> wrote:
>>>> I too am running into this same issue on centos 5.3.  Here is the
>>>> revelant information from my pam setup
>>>>
>>>> auth        required      pam_env.so
>>>> auth        required      pam_listfile.so onerr=fail item=group
>>>> sense=allow file=/etc/ldapgroups
>>>> auth        sufficient    pam_unix.so nullok try_first_pass
>>>> auth        requisite     pam_succeed_if.so uid >= 500 quiet
>>>> auth        sufficient    pam_ldap.so use_first_pass
>>>> auth        required      pam_deny.so
>>>>
>>>> account     required      pam_unix.so broken_shadow
>>>> account     sufficient    pam_succeed_if.so uid < 500 quiet
>>>> account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
>>>> account     required      pam_permit.so
>>>>
>>>> password    requisite     pam_cracklib.so try_first_pass retry=3
>>>> password    sufficient    pam_unix.so md5 shadow nullok try_first_pass
>>>> use_authtok
>>>> password    sufficient    pam_ldap.so use_authtok
>>>> password    required      pam_deny.so
>>>>
>>>> session     optional      pam_keyinit.so revoke
>>>> session     required      pam_limits.so
>>>> session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
>>>> session     [success=1 default=ignore] pam_succeed_if.so service in
>>>> crond quiet use_uid
>>>> session     required      pam_unix.so
>>>> session     optional      pam_ldap.so
>>>>
>>>> - Justin Lintz
>>>>
>>>>
>>>>
>>>> On Thu, Apr 30, 2009 at 7:21 PM, Stricklin, Raymond J
>>>> <raymond.j.stricklin@...> wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Howard Chu [mailto:hyc@...]
>>>>>> > what can I do to allow locally defined users to log in while LDAP is
>>>>>
>>>>>> > unavailable?
>>>>>>
>>>>>> Sounds like you just need to tweak the success config in
>>>>>> pam.conf - I use "sufficient" and it just falls back to
>>>>>> pam_unix if pam_ldap fails.
>>>>>
>>>>> Here are the relevant parts of my pam config:
>>>>>
>>>>> account required pam_ldap.so  ignore_unknown_user
>>>>> ignore_authinfo_unavail
>>>>> account required pam_unix2.so
>>>>>
>>>>> auth required   pam_env.so
>>>>> auth sufficient pam_unix2.so
>>>>> auth sufficient pam_ldap.so  use_first_pass ignore_authinfo_unavail
>>>>> auth required   pam_deny.so
>>>>>
>>>>> password required pam_pwcheck.so nullok
>>>>> password required pam_ldap.so    try_first_pass ignore_unknown_user
>>>>> ignore_authinfo_unavail
>>>>> password required pam_unix2.so   nullok use_authtok
>>>>>
>>>>> session required pam_limits.so
>>>>> session optional pam_ldap.so   ignore_authinfo_unavail
>>>>> session required pam_unix2.so
>>>>>
>>>>>
>>>>> The 'ignore_authinfo_unavail' options were all added today. It works the
>>>>> same in this situation with or without.
>>>>>
>>>>> I wonder if it's failing in 'account'. It seems like I had to have it
>>>>> the way I have it, to make something important work correctly. I may
>>>>> have to dig back through my notes. I think it may have been related to
>>>>> LDAP password policy enforcement.
>>>>>
>>>>> ok
>>>>> r.
>>>>>
>>>>
>>>
>>
>

[Josh Miller]

> On Sat, May 2, 2009 at 21:01, Justin Lintz <jlintz@...> wrote:
>> nssswitch.conf is set to files ldap, for passwd, shadow and group, yet
>> the problem still exists.
>> - Justin Lintz

Please post your /etc/ldap.conf.

[wrogers]

host ldaplb1 ldaplb2 ldaplb3

base ou=Users,ou=Employees,dc=example,dc=com
binddn cn=dcAuth,ou=Applications,dc=example,dc=com
bindpw example
scope sub

# Search timelimit
timelimit 5

# Bind/connect timelimit
bind_timelimit 2

# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
bind_policy soft

# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
idle_timelimit 3600

# must be set or sudo will ignore LDAP
sudoers_base   ou=sudo,ou=Applications,dc=example,dc=com

# verbose sudoers matching from ldap
#sudoers_debug 2

nss_base_passwd         ou=Users,ou=Employees,dc=example,dc=com?sub
nss_base_shadow         ou=Users,ou=Employees,dc=example,dc=com?sub
nss_base_group            ou=Group,ou=Employees,dc=example,dc=com?sub
nss_base_netgroup       ou=Netgroups,dc=example,dc=com?sub

# Just assume that there are no supplemental groups for these named users
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon

ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5

On Sun, May 3, 2009 at 12:19, Josh Miller <joshua@...> wrote:

>> On Sat, May 2, 2009 at 21:01, Justin Lintz <jlintz@...> wrote:
>>>
>>> nssswitch.conf is set to files ldap, for passwd, shadow and group, yet
>>> the problem still exists.
>>> - Justin Lintz
>
> Please post your /etc/ldap.conf.
>
>
>

[r.stricklin]

 

> -----Original Message-----
> From: Josh Miller [mailto:joshua@...]
> > On Sat, May 2, 2009 at 21:01, Justin Lintz <jlintz@...> wrote:
> >> nssswitch.conf is set to files ldap, for passwd, shadow and group,
> >> yet the problem still exists.
> >> - Justin Lintz
>
> Please post your /etc/ldap.conf.

Here's mine, since I orginally reported the problem.

host vm-ldap-1
base dc=vlx
ldap_version 3
bind_policy soft
pam_lookup_policy yes
pam_check_host_attr yes
pam_password exop
nss_base_passwd         ou=people,dc=vlx?one
nss_base_group          ou=group,dc=vlx?one
ssl start_tls
nss_initgroups_ignoreusers      root,ldap,man,postfix

ok
r.

[jlintz]

base dc=example,dc=net
binddn cn=Manager,dc=example,dc=net
bindpw example
timelimit 15
bind_timelimit 15
idle_timelimit 3600
nss_initgroups_ignoreusers
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman
pam_filter objectclass=posixaccount
pam_member_attribute memberuid
nss_base_passwd ou=People,dc=example,dc=net?one
nss_base_shadow ou=People,dc=example,dc=net?one
nss_base_group ou=Groups,dc=example,dc=net?one
uri ldaps://prodldap01.example.net/ ldaps://prodldap02.example.net/
ssl on
tls_cacertdir /etc/openldap/cacerts
tls_checkpeer no
pam_password md5

- Justin Lintz



On Sun, May 3, 2009 at 3:36 PM, Stricklin, Raymond J
<raymond.j.stricklin@...> wrote:

>
>
>> -----Original Message-----
>> From: Josh Miller [mailto:joshua@...]
>> > On Sat, May 2, 2009 at 21:01, Justin Lintz <jlintz@...> wrote:
>> >> nssswitch.conf is set to files ldap, for passwd, shadow and group,
>> >> yet the problem still exists.
>> >> - Justin Lintz
>>
>> Please post your /etc/ldap.conf.
>
> Here's mine, since I orginally reported the problem.
>
> host vm-ldap-1
> base dc=vlx
> ldap_version 3
> bind_policy soft
> pam_lookup_policy yes
> pam_check_host_attr yes
> pam_password exop
> nss_base_passwd         ou=people,dc=vlx?one
> nss_base_group          ou=group,dc=vlx?one
> ssl start_tls
> nss_initgroups_ignoreusers      root,ldap,man,postfix
>
> ok
> r.
>

[jlintz]

Changing the order had no effect.  The /var/log/secure log shows
nss_ldap trying to connect over and over again and not trying to stop
- Justin Lintz



On Sun, May 3, 2009 at 10:17 AM, Weston Rogers <wrogers@...> wrote:
> You need to set it to ldap first, then files.
>
> Wes

[Josh Miller]

Justin Lintz wrote:

> base dc=example,dc=net
> binddn cn=Manager,dc=example,dc=net
> bindpw example
> timelimit 15
> bind_timelimit 15
> idle_timelimit 3600
> nss_initgroups_ignoreusers
> root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman
> pam_filter objectclass=posixaccount
> pam_member_attribute memberuid
> nss_base_passwd ou=People,dc=example,dc=net?one
> nss_base_shadow ou=People,dc=example,dc=net?one
> nss_base_group ou=Groups,dc=example,dc=net?one
> uri ldaps://prodldap01.example.net/ ldaps://prodldap02.example.net/
> ssl on
> tls_cacertdir /etc/openldap/cacerts
> tls_checkpeer no
> pam_password md5

Justin, try setting your bind_policy to soft:

#/etc/ldap.conf
...
bind_policy soft

Otherwise, you'll continue to try to connect indefinitely.

--
Josh Miller, RHCE/VCP
Seattle, WA
Linux Solutions Provider
Website:  http://itsecureadmin.com/

[padrik]

>> bind_policy soft
>> Otherwise, you'll continue to try to connect indefinitely.

I have up to 95% similar settings on my SLES10SP2 servers and the bind_policy soft does not work either.
Novell does not support LDAP unless it's there directory service. Lucky us.
At first sight it looks like it also has something to do with TLS. Turning off TLS on the client side appears to be a have some influence on the timeout. So I stopped nscd for a direct ldap response for nss_ldap and looked if that changed anything. Yes and No. Yes if the network is up and the ldap servers are unreachable, No if the network interface is down. I googled around and found that for this version of nss_ldap there is a timeout bug so whatever we do it won't help a bit.
The only workaround so far is to install an ldap server on each box and replicate from the master ldap server until Novell updates nss_ldap to a newer version.

P