I've migrated RHEL6 user accounts from traditional /etc/passwd, /etc/shadow, and /etc/group files to OpenLDAP. However, trying to log in as the migrated users does not work because of incorrect user password errors:

Example (removed) /etc/passwd line:

leopetr:x:1005:1005:Leo Petr:/mnt/home/leopetr:/bin/bash

Example (removed) /etc/shadow line:


(The hash corresponds to a randomly generated password for an unprivileged account.)

Example LDIF generated by OpenLDAP conversion tools:

dn: uid=leopetr,ou=People,dc=imdemocloud,dc=com
uid: leopetr
cn: Leo Petr
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$6$+7sZw4ID$CyLfaFeo.aDn1Xd5.MCBWXDm131CIOPExg0hgUQb4sdInuXIf4IBU8LxJo7Hz144uIp3nYB6cmnIzLAyI6fzr.
shadowLastChange: 16205
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1005
gidNumber: 1005
homeDirectory: /mnt/home/leopetr
gecos: Leo Petr

I can su - to that user account as root, so the user record is accessible in LDAP. However, I can't log in as that user. Example:

$ su - leopetr
su: incorrect password
  1. Why isn't the password working?

  2. Is {crypt} the right prefix for a sha-512 password hash?

  3. Is userPassword the right LDAP field for a password hash?

Edit: /etc/pam.d/su

auth        sufficient  pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth       sufficient  pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth       required    pam_wheel.so use_uid
auth        include     system-auth
account     sufficient  pam_succeed_if.so uid = 0 use_uid quiet
account     include     system-auth
password    include     system-auth
session     include     system-auth
session     optional    pam_xauth.so


# 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_sss.so use_first_pass
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_sss.so
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 minlen=8 dcredit=-1 ucredit=0 lcredit=-1 ocredit=0 type= reject_username
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so 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_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so
session     optional      pam_ldap.so


config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = LOCAL,LDAP

filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75

reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

cache_credentials = true

id_provider = ldap
auth_provider = ldap

ldap_uri = ldaps://my_hostname.my_domain.com
ldap_search_base = dc=my_domain,dc=com
ldap_id_use_start_tls = true
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt


# /etc/nsswitch.conf
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
# Valid entries include:
#   nisplus         Use NIS+ (NIS version 3)
#   nis         Use NIS (NIS version 2), also called YP
#   dns         Use DNS (Domain Name Service)
#   files           Use the local files
#   db          Use the local database (.db) files
#   compat          Use NIS on compat mode
#   hesiod          Use Hesiod for user lookups
#   [NOTFOUND=return]   Stop searching if not found so far

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     files sss ldap
shadow:     files sss ldap
group:      files sss ldap

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

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

netgroup:   files sss ldap

publickey:  nisplus

automount:  files sss ldap
aliases:    files nisplus

Also, here are the authconfig commands I used:

authconfig --enablesssd --enablesssdauth --enablelocauthorize --enableldap --enableldapauth \
--ldapserver=ldaps://my_hostname.my_domain.com:636 --disableldaptls \
--ldapbasedn=dc=my_domain,dc=com \
--enablerfc2307bis --enablemkhomedir --enablecachecreds --update

authconfig --update --enablesssd --enablesssdauth

authconfig --enablesssd --update
  • Can you reset your password directly to LDAP and retry? From your description seems like you've copied the hashed password from /etc/shadow to the openldap entry. Normally you should reset it with an ldif (or use ApacheDirectoryStudio, whatever fits) – Fredi Nov 6 '15 at 14:45
  • The contents of /etc/pam.d/su and all files included in that file, recursive, are relevant. As are /etc/ldap.conf or /etc/sssd/sssd.conf depending on your setup. – 84104 Nov 6 '15 at 16:46
  • @84104 I've added /etc/pam.d/su and /etc/sssd/sssd.conf to the question – Leo Nov 6 '15 at 17:05
  • Be sure you have sssd on your passwd and shadow entries on /etc/nsswitch.conf. Another thing, on RH6 use authconfig to enable ldap users – Fredi Nov 6 '15 at 18:52
  • @Fredi I've added q/etc/nsswitch.confq and authconfig commands to the question – Leo Nov 6 '15 at 19:24

No, the correct tag for SHA-512 is {SHA-512} but you have to enable a module and to apply an overlay to your data database.

Why not simply generating user passwords with:

sudo ldappasswd -H ldapi:/// -Y EXTERNAL uid=leopetr,ou=People,dc=imdemocloud,dc=com -s secret

If you want to pre-stage password (for ldif ldapmodify insert), have a look at slappasswd, a tool to generate password in the correct format.

Yes, userPassword is fine.

  • I need something that can be automated and doesn't require knowing the user passwords, just hashes. I've tried modifying the userPassword for that user to start with {SSHA} or {SHA-512} instead of {crypt}, but the error hasn't changed. I'm looking into whether there are any modules I need to load. – Leo Nov 6 '15 at 17:08

When migrating password hashes from /etc/shadow to LDAP entries the correct LDAP password scheme to use is {CRYPT}, no matter what crypt(3) scheme is used.

The disadvantage is that those password hashes are platform-specific and are thus not always portable. You can see which schemes are available on your specific Linux/FreeBSD/whatever platform in the crypt(3) man-page installed on your system.

Besides this you should not use a remote shadow map at all, especially since exposing the hashes of all user passwords to all systems via LDAP is horrible security practice.

sssd or nss-pam-ldapd will send LDAP simple bind requests for checking user's password. Therefore they don't need read access to password hashes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.