LDAP-UX slowing Server...

[Demerson Zounar_1]

Hi to all...

I have some LDAP-UX clients (J4269AA) using a central LDAP Server (NDS-HPUX) to authenticate some users.

There's a problem that when there's no connection between the server and the clients the clients started to slow down, increasing uptime. Every time the client tries to authenticate some user, even if it's local, the client doesn't respond. All is back to normal when the link is up.

My nsswitch.conf:

#
# /etc/nsswitch.ldap:
#
# An example file that could be copied over to /etc/nsswitch.conf. It
# uses LDAP (Lightweight Directory Access Protocol) in conjunction with
# dns & files.
#

passwd: files ldap
group: files ldap
hosts: dns [NOTFOUND=continue] files networks: files
protocols: files
rpc: files
publickey: files
netgroup: files
automount: files
aliases: files
services: files

My pam.conf

# PAM configuration
#
# This pam.conf file is intended as an example only.
#
# Please note that this configuration file has only been modified for the
# default services. Other services can be added or modified as
# needed or desired. If a service is not listed, it will use the
# OTHER classification
#
# the format for a entry is
#
#
# see pam.conf(4) for more details
#
# Authentication management
#
login auth sufficient /usr/lib/security/libpam_unix.1
login auth required /usr/lib/security/libpam_ldap.1 try_first_pass
su auth sufficient /usr/lib/security/libpam_unix.1
su auth required /usr/lib/security/libpam_ldap.1 try_first_pass
dtlogin auth sufficient /usr/lib/security/libpam_unix.1
dtlogin auth required /usr/lib/security/libpam_ldap.1 try_first_pass
dtaction auth sufficient /usr/lib/security/libpam_unix.1
dtaction auth required /usr/lib/security/libpam_ldap.1 try_first_pass
ftp auth sufficient /usr/lib/security/libpam_unix.1
ftp auth required /usr/lib/security/libpam_ldap.1 try_first_pass
OTHER auth sufficient /usr/lib/security/libpam_unix.1
OTHER auth required /usr/lib/security/libpam_ldap.1 try_first_pass
#
# Account management
#
login account sufficient /usr/lib/security/libpam_unix.1
login account required /usr/lib/security/libpam_ldap.1
su account sufficient /usr/lib/security/libpam_unix.1
su account required /usr/lib/security/libpam_ldap.1
dtlogin account sufficient /usr/lib/security/libpam_unix.1
dtlogin account required /usr/lib/security/libpam_ldap.1
dtaction account sufficient /usr/lib/security/libpam_unix.1
dtaction account required /usr/lib/security/libpam_ldap.1
ftp account sufficient /usr/lib/security/libpam_unix.1
ftp account required /usr/lib/security/libpam_ldap.1
OTHER account sufficient /usr/lib/security/libpam_unix.1
OTHER account required /usr/lib/security/libpam_ldap.1
#
# Session management
#
login session sufficient /usr/lib/security/libpam_unix.1
login session required /usr/lib/security/libpam_ldap.1
dtlogin session sufficient /usr/lib/security/libpam_unix.1
dtlogin session required /usr/lib/security/libpam_ldap.1
dtaction session sufficient /usr/lib/security/libpam_unix.1
dtaction session required /usr/lib/security/libpam_ldap.1
OTHER session sufficient /usr/lib/security/libpam_unix.1
OTHER session required /usr/lib/security/libpam_ldap.1
#
# Password management
#
login password sufficient /usr/lib/security/libpam_unix.1
login password required /usr/lib/security/libpam_ldap.1 try_first_pass
passwd password sufficient /usr/lib/security/libpam_unix.1
passwd password required /usr/lib/security/libpam_ldap.1 try_first_pass
dtlogin password sufficient /usr/lib/security/libpam_unix.1
dtlogin password required /usr/lib/security/libpam_ldap.1 try_first_pass
dtaction password sufficient /usr/lib/security/libpam_unix.1
dtaction password required /usr/lib/security/libpam_ldap.1 try_first_pass
OTHER password sufficient /usr/lib/security/libpam_unix.1
OTHER password required /usr/lib/security/libpam_ldap.1 try_first_pass


Hope this helps...

My pam.conf

[Steven E. Protter]

Shalom Demerson,

There needs to be a good connection between the client and the ldap server for the authentication scheme to work properly.

These slowdowns seem to be normal for when the central server is offline.

Perhaps its the ldap configuration itself, not pam. This client needs to be like an NIS client, capable of functioning independently when the Master is offline.

http://docs.hp.com/en/J4269-90016/ch01s01.html

http://docs.hp.com/en/J4269-90016/ch04s01.html

Second link looks promising.

SEP

[Jeff Schussele]

Hi,

You should have a master LDAP server that replicates to a standby server that can be accessed when the master is offline. There would be minor slowdowns for the initial timeout but at least it could authenticate.
LDAP is every bit as important as DNS & you wouldn't think of running a solo DNS server would you?

Rgds,
Jeff

[Bill Hassell]

DNS and LDAP share a similar resposibility and status. The responsibility is incredibly important -- they aren't just sources for IP addresses and passwords, they have security responsibility for the entire network. Unfortunately, some admins and IT managers look at these as just another box to manage. Both DNS and LDAP must be the most reliable AND secure systems in the network!! All other machines depend on them - as they should.

[Demerson Zounar_1]

Thanks everybody...

I know all of this concerns... But the fact is that it's taking too much time (about 5 minutes, or more) to authenticate a local user. And the uptime increases to a whooping 10, 15, even 60! I wonder if there's no kind of timeout to try ldapuxclientd to stop trying to authenticate...

I simply remove /etc/nssswitch.conf for authentication not use ldap source.

Thanks again...

[Don Mallory]

Hi there,

You show in your nsswitch.conf:

hosts: dns [NOTFOUND=continue] files networks: files

Your DNS server wouldn't happen to be the same host as your LDAP server would it?

You should see some slowdown, but not that much. In most of my testing, when the LDAP server is missing, mostly there is no user and group info. Local accounts aren't affected.

The issues I have seen are with respect to Kerberos more than LDAP (I'm authenticating to a Windows AD) and most of that is because my DNS servers are also my KDCs.

Don