Not strictly limited to Kerberos - long login delays when system is offline

Tom Parker tparker at cbnco.com
Fri Aug 10 23:43:44 EDT 2012


Hi Derek.

What I have done is set shorter timeouts in my resolv.conf file

options timeout:1
options attempts:2

and set my LDAP bind timelimits to 3 seconds in /etc/ldap.conf

# Search timelimit
timelimit 3

# Bind/connect timelimit
bind_timelimit 3

I figure that if I can't contact an LDAP server in 3 seconds I am never
going to be able to.  I also have told LDAP to ingore group lookups for
system users by setting nss_initgroups_ignoreusers to the common system
account that I do not have in LDAP. 

# returns NOTFOUND if nss_ldap's initgroups() is called
# for users specified in nss_initgroups_ignoreusers
# (comma separated)
nss_initgroups_ignoreusers
root,ldap,postfix,wwwrun,nobody,man,postgres,rsyncguy,tomcat

The last thing I have done is set my default realm in /etc/krb5.conf
instead of doing a DNS lookup for it. 

[libdefaults]
        default_realm = WI.LS.CBN

All of these changes means that on a system that normally uses Kerberos
for Authentication and LDAP for Authorization I can get logged in as
root (or any other local user) in about 15 seconds even if the whole
network is down and I have no services running.

Hope this helps.

Tom


On 08/10/2012 11:26 PM, Darek M wrote:
> Hi there, I'm sorry that this won't be strictly limited to Kerberos.
>
> I have an MIT/OpenLDAP set up running in a FreeBSD environment where
> nss_ldap provides user data and kerberos the authentication.
>
> The problem is that when the system goes offline (as it can easily
> happen), logging in becomes near impossible.  It takes 5 minutes on a
> console login for LDAP lookups to time out (between DNS lookup
> retries, nss retries, timeouts, etc).  The same delay occurs even for
> a local user, though it appears to me that the system is looking up
> file ownership, environment, etc, because a successful root login is
> immediately logged, but getting a term prompt is still delayed.
>
> If I remove LDAP from nsswitch.conf, the system obviously has no info
> on the user and login fails when trying GSSAPI in OpenSSH alone.
>
> What are you guys doing not to make your systems unusable when LDAP is
> unavailable?  Are you bypassing it entirely and using Kerberos only
> somehow?  Are you making use of NSCD or SSSD to cache LDAP data?
> Would the cache survive a reboot?
>



More information about the Kerberos mailing list