LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Fedora (http://www.linuxquestions.org/questions/fedora-35/)
-   -   login via ldap not working in FC15 (http://www.linuxquestions.org/questions/fedora-35/login-via-ldap-not-working-in-fc15-881049/)

jcrowley 05-16-2011 03:40 PM

login via ldap not working in FC15
 
Have LDAP server running on FC14. Works OK for local logins, etc.

Installed FC15 (beta) and cannot login using LDAP.

ldapsearch works from the new machine and returns exactly what is expected, so we are getting through to the LDAP database. Login to any user in LDAP does not work, 'id' command says 'No such user', 'su' to any user says user does not exist, and NFS mount shows 'nobody' as owner & group.

ldap.conf file is here (used from several places via symlinks):

#
# LDAP.CONF file used by LDAP Clients. This exists in these places:
# /etc/openldap/ldap.conf <--- used by the OpenLDAP utilities
# /etc/ldap.conf <--- used by everyone else
# /etc/nss_ldap.conf <--- showed up in Fedora 14
# /etc/pam_ldap.conf <--- ditto
#

# Client closes connection if idle for N seconds
idle_timelimit 15

# /etc/hosts was setup by earlier script to define standard host-names
uri ldap://spcldapprivate/
base dc=screenpc,dc=com

tls_cacertdir /etc/openldap/cacerts
pam_password md5

# Next line is to solve a hang at reboot
# NSS (or someone) is trying to access LDAP before slapd has been started
# See https://bugzilla.redhat.com/show_bug.cgi?id=186527 for details

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus

/etc/nsswitch.conf file is:

# NSSWITCH.CONF file for Screen PC installations
#
# The aaaINSTALL_...LDAP_SETUP script will insert a SYMLINK to this
# file in /etc/nsswitch.conf
#
# Once created, then LDAP will be used for authentication of logins.
#
passwd: files ldap
shadow: files ldap
group: files ldap
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks: files
networks: files
protocols: files ldap
rpc: files
services: files ldap

netgroup: files ldap

publickey: nisplus

automount: files ldap
aliases: files nisplus

/etc/pam.d/password-auth file is:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_fprintd.so
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_localuser.so
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 [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so

/etc/pam.d/system-auth is the same as passwd-auth


Must be missing some piece of configuration on the new client machine -- but what????

Thanks for any assistance.

John VV 05-16-2011 09:59 PM

did the bug report help ?

if not post a new bur report at bugzilla

so that rc2 can get a fix

this is what BUG TESTING a rc1 if for

reporting the bugs and the fixes.

jcrowley 05-17-2011 07:42 AM

Understand. Am initially going under the assumption that it is not a bug but some screwup in setting up the config on the client, but so far cannot find anything.

On the LDAP server we're tracing all inquiries, so we can see any access in the log (ldapsearch shows up as expected). When a login to the client occurs, there is nothing in the server log. Also nothing in either dmesg or /var/log/messages on the client side. At this point it does seem that the nsswitch.conf and various pam.d config files are not directing the authentication process to ldap at all.

Is there any sort of "debug trace" flag that you can turn on to log all of the steps of a login?

jcrowley 05-17-2011 08:06 AM

May have found it -- install scripts did not install the pam_ldap and nss_ldap libraries.

nss_ldap will not install on FC15 because of a dependency -- will enter bug report.

Question: Why no log messages anywhere if PAM config said to use LDAP but these libraries were not installed?

jcrowley 05-27-2011 08:55 AM

Similar problem after installing released version of FC15. nss_ldap and pam_ldap libraries are installed correctly.

Complete hang on boot. Server will not even respond to a 'ping'.

If /etc/nsswitch.conf, /etc/pam.d/system_auth, /etc/pam.d/password_auth, /etc/nss_ldap.conf, and /etc/pam_ldap.conf are all switched back to default values (not using LDAP) then the system boots as expected.

Current suspicion is that the order of startup of system services during boot is leading to hang. Will be investigated next.

Has anyone else seen similar problems w FC15 using LDAP for authentication? This seems like a pretty common configuration.

jcrowley 05-27-2011 03:33 PM

This is nuts! If nssswitch.conf is the original (not using LDAP), the system boots fine. If nsswitch.conf uses LDAP, it hangs during boot. Ctrl-alt-F2 gets a command prompt, but cannot login as root.

We're about to abandon Fedora completely!

jcrowley 05-30-2011 07:41 PM

OK, complete re-install and setup from the install DVD.

Get to exactly the same point as before -- if nsswitch.conf is setup as above, the system will hang on boot.

jcrowley 08-24-2011 12:54 PM

Found that there is something missing for groups.

In nsswitch.conf has the line:

group: file ldap

then the boot hangs -- for probably 30+ minutes, then finally clears.

If this is changed to drop the 'ldap':

group: file

then the boot is normal.

Tried to find out what 'group' was missing from the files, but no luck.

scottro11 08-24-2011 02:37 PM

This might be the result of a rather old bug that was never fixed, to my knowledge. In many cases, that hang can be fixed by changing /etc/nss_ldap.conf's entry of bind_policy from hard to soft.

linux4guru 12-05-2011 08:28 PM

Had similar issue here with fc15 - I got ldap to authenticate but I can seem to login with an ldap user account to GDM.

If I login as root user and then su - ldap user, this works.

linux4guru 12-06-2011 01:42 AM

Just in case - I got my FC15 client working...

Do this... assuming you have the openldap-clients installed already.

1. yum install nss-pam-ldapd
2. vi /etc/sysconfig/authconfig file and change the "no" to "yes" on FORCELEGACY
3. run authconfig-tui and then...
4. uncheck kerberos and only select the LDAP authentication on the right side of the screen...
5. I also assume you already configured your LDAP server by using the system-config-authentication

Good luck...!


All times are GMT -5. The time now is 10:23 AM.