Ask Your Question

Ldap user offline login not working when i am restart my system

asked 2017-11-23 03:06:14 -0500

Nicky gravatar image

The client successfully logged on when I start a server one time. One time server start necessary for offline ldap user access. Then,when I restart my client machine,the LDAP user not logged on.image description

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2017-11-23 04:53:59 -0500

scottro gravatar image

I remember a bug in RH based systems, and have no idea if it was ever fixed. I mention it on a very dated page of mine (written for CentOS-5) ,at . I have no idea if it's still the case, but, from that page.

There is a bug in RH based systems. (This is why I suggest changing the bindpolicy from hard to soft.) It was reported 5 years ago and hasn't been fixed yet. In theory, "files ldap" in nsswitch.conf means that it should check the local system files first and only then go to an ldap server. Although it does seem to do this, the bug is that if an LDAP server is not available, the system will hang, and possibly refuse to authenticate--if it does authenticate, it may take 20 minutes or more. This is one of those things which I don't quite understand--that is, why the bindpolicy should even be necessary if it's told to check local files first, however, as many other articles on LDAP will mention, the documentation is often hard to find.

The odd thing about this, from my experience, is that as long as an LDAP server is available, everything is fine, irrespective of whether the account in question is on the LDAP server or not or whether bind_policy is set to hard or soft. That is, if I have user john, who is NOT on the ldap server, as long as the server is running and the local machine can reach it, john can log in normally. It doesn't have to use the LDAP server for authentication--it just seems to want to know there is an LDAP server, as if it needs reassurance.

Therefore, this can be a problem if the LDAP server is taken off the network. To repeat, the way to avoid this seems to be change the bind_policy line from hard to soft in /etc/ldap.conf. (Also to repeat, that isn't a typo, change /etc/ldap.conf, NOT /etc/openldap/ldap.conf.)

I don't know where, on modern Fedora systems, that bind_policy is defined, but if it is, it might be worth changing it from hard to soft and seeing if that solves the problem.

edit flag offensive delete link more

Question Tools


Asked: 2017-11-23 03:06:14 -0500

Seen: 63 times

Last updated: Nov 23 '17