LDAP authentication problem with Local user auth when LDAP not available
Hi,
I have a problem with LDAP authentication on RHEL6.4. Using nslcd authenticating against Domino LDAP.
I have no problems with talking to LDAP and its authenticating users with no problems, issue appears when there is no available LDAP server to respond (i.ex: network interface down / not yet configured vm deployed from template).
I can not log in using console login either. There is a message flashing quickly (something about no authentication mechanism found or similar) and gets back to Login prompt:.
secure log just shows: pam_ldap: ldap_simple_bind Can't contact LDAP server.
I tried to google and all answers I got was referring to use: nss_initgroups_ignoreusers
my /etc/nslcd.conf:
uri ldap://ldap-ah.internal.XX.XX.com/ ldap://ldap-lhc.internal.XX.XX.com/
ldap_version 3
base o=TPP
binddn cn=<LDAP user>
bindpw <ldap pass>
bind_timelimit 30
timelimit 30
nss_initgroups_ignoreusers ALLLOCAL
map passwd uid unixloginid
map shadow uid unixloginid
map group uniqueMember member
uid nslcd
gid ldap
/etc/pam_ldap.conf:
host ldap-ah.internal.XX.XX.com ldap-lhc.internal.XX.XX.com
base o=TPP
ldap_version 3
binddn cn=<LDAP user>
bindpw <LDAP pass>
pam_filter objectclass=inetOrgPerson
pam_login_attribute unixloginid
pam_template_login_attribute unixloginid
pam_password md5
pam_password_prohibit_message Please contact internal.support@XX.XX.com to change your password
nss_map_attribute uid unixloginid
/etc/nsswitch.conf:
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
rpc: files
services: files
netgroup: nisplus
publickey: nisplus
automount: files nisplus
aliases: files nisplus
/etc/sysconfig/authconfig:
IPADOMAINJOINED=no
USEMKHOMEDIR=yes
USEPAMACCESS=yes
CACHECREDENTIALS=yes
USESSSDAUTH=no
USESHADOW=yes
USEWINBIND=no
USEDB=no
FORCELEGACY=no
USEFPRINTD=yes
FORCESMARTCARD=no
PASSWDALGORITHM=sha512
USELDAPAUTH=yes
USEPASSWDQC=no
IPAV2NONTP=no
USELOCAUTHORIZE=yes
USECRACKLIB=yes
USEIPAV2=no
USEWINBINDAUTH=no
USESMARTCARD=no
USELDAP=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESSSD=no
USEHESIOD=no
/etc/pam.d/password-auth-ac:
#%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 sufficient pam_ldap.so use_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_ldap.so md5 use_authok
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
session optional pam_mkhomedir.so skel=/etc/skel umask=077
/etc/pam.d/system-auth-ac:
#%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 sufficient pam_ldap.so use_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_ldap.so md5 use_authok
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
session optional pam_mkhomedir.so skel=/etc/skel umask=077
Any tips, suggestions are welcome.
Thanks
Pawel
Responses
Red Hat
25369 points
Hi Pawel, and welcome.
Hopefully someone will be able to help out here with some suggestions, but based on your description of the issue I suspect you will need to open a support case.
Hi David,
Thanks for your reply. I guess I will have to eventually as further search on that issue still did not resolve anything.
You'd probably want to muck with the nsswitch.conf file, specifying appropriate actions for 'success', 'notfound' and 'unavail' (the last being "what to do if the service isn't available" - default is usually "continue"). That said, I'm unless your LDAP server actively returns a connection-refused kind of response, the "unavail" action won't get triggered until your ldap service's timeout is reached. You'd probably set that in your ldap client config file to something more-agressive than what it's currently set to.
Hi Tom, Thanks for suggestion. I did look at that as well. Maybe I am missing something or got the idea of that file wrong.
if it is set like: passwd files ldap - shouldn't it check for local files/users first and if success (default return) allow to log in?
I am recreating this by disabling network cards so I do have Unavailable as reply from LDAP.
I even tried with: passwd: ldap [!SUCCESS=continue] files
still the same, I see lots of messages in logs about: failed to bind to LDAP, or no available LDAP server found
When I try to log in as root from other console (local).
If you could shed some light on that nsswitch or if I understand it correctly I will appreciate.
Usually, when you've got "files
I might have found the resolution for this issue. Will do full description later as I still have to compare files and changes to my original files, in short: after I had all the above setup, I have run the command: authconfig-tui and checked the "Use MD5 Passwords" to addition what it was there (full description on next post later). It added then some changes to my config files, not much yet that kind of seems to fixed the problem.
First, sorry for long delay on this (busy time).
Changes to original (apart some order in password-auth-ac and system-auth-ac) and me changing timeout from 30 to 10 (as it still ties to find ldap before allows local login).
/etc/pam.d/password-auth-ac:
change: account required pam_unix.so
to: account required pam_unix.so broken_shadow
added: account required pam_access.so
change: password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
to: password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
/etc/sysconfig/authconfig:
change: PASSWDALGORITHM=sha512
to: PASSWDALGORITHM=md5
Summary, seems like main change is the password algorithm from sha to md5... weird is that my root password in /etc/shadow is still in sha512 format.
I have to admit I don't understand why these changes made a difference but - that is the solution that made my problem go away (still no ideal as it tries to connect to LDAP when no network available and username is root but at least it works).
Cheers
Changing default password algorithm only effects passwords changed after you've made the setting change. If you want root's password-string to change from $6... to $1..., you'll need to change root's password (even if you're just changing it to what it already is).
Just out of curiosity: what are you using as your LDAP backend? Active Directory and most newer LDAPs should support the SHA* suites. As an aside, MD5 would be viewed as a step backwards in your security posture that you should be avoiding unless something like a (broken) authentication-source didn't support better algorithms.
Hi Tom,
I did not changed my default algorithm on OS level. The only change related to password algorithm was that LDAP configuration. Also when it was SHA512 I could still authenticate to LDAP, but then I could not authenticate as local user when LDAP was unavailable. My backend LDAP is Domino Server.
Issue is not LDAP server but some weird setting (maybe not weird but atm I don't understand why) that changed, but I can't find where, that this time it does timeout (when LDAP offlice) and allows log in as root. I am 95% sure that above differences might not have nothing to do with it, yet these are the only ones I have found in config files related to LDAP/Auth.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.