4

I would appreciate any help in the following problem:

I have an openladp (2.3.39) server (Fedora 8) which authenticates users from other ldap clients (various versions of Fedora). On my attempt to upgrade the whole infrastructure, ldap users with tcsh (as their default shell) cannot login in a new client running CentOS 7. On the contrary, ldap users with bash as well as local users (no matter their default shell) login without a problem.

Ldap tcsh users can't login neither from console nor from ssh. While from console, the message I receive is:

pam_unix(login:auth) authentication failure pam_unix(login:session) session opened for user

and from ssh (without a failure part):

pam_unix(sshd:session) session opened for user

However, the user never gets a shell prompt, indicating that the login hangs. I have no idea whether the problem is pam related, but find below my /etc/pam.d/system-auth-ac as it was created automatically by system-authconfig:

#%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_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_access.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 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 optional pam_systemd.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

Thanks in advance.

Update: The problem seems to be related with the nfs exported home directories. If I unmount the shared partition from the client, the user is Logging in with home = "/", though.

Improve this question
7
  • a) is tcsh actually installed b) is tcsh defined in /etc/shells as a valid login shell? Commented May 6, 2016 at 12:33
  • @HBruijn yes. That's why local tcsh users have no problem to login. Commented May 6, 2016 at 12:44
  • Is the path for the shell in the LDAP entry for the user valid? Eg. if it points to /bin/tcsh, is there a valid shell there? Commented May 6, 2016 at 12:45
  • @Sven Yes, /bin/tcsh is there. Commented May 6, 2016 at 13:01
  • And does loginShell in the LDAP directory for tcsh users point to /bin/tcsh? Also, what happens if you just do su <username> as root for the affected users? Commented May 6, 2016 at 13:02

1 Answer 1

Reset to default
1

Finally it turned out that nfs was responsible. Client was v.4, while server v.3 and therefore, mount option sec=sys was necessary at the client part.

Thanks to all who bothered.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.