[RESOLVED] - SSH authentication with 389-ds fails now
- warron.french
- Posts: 616
- Joined: 2014/03/27 20:21:58
[RESOLVED] - SSH authentication with 389-ds fails now
I have had 389-ds working on my CentOS-6.7 environment for the past month.
I am running CentOS-6.7,
389-ds-base-1.2.11.15-72.el6_7.x86_64 with
pam-1.1.1-20.el6_7.x86_64, and
openssh-server-5.3p1-114.el6_7.x86_64
I have been implementing STIG security requirements starting on Friday. I have in this environment local (/etc/shadow & passwd file entries) accounts and also 389-ds accounts on this network of 6 workstations and 1 server. I made several changes to dt5; and only dt5. All of the other machines were deliberately isolated from the changes so that I would only ruin/have to repair a single system (plus I will rebuild them with my hardening script that is run in the kickstart %post section when I have tested successfully the changes I am trying to make).
After making changes to several files, to include a new file for /etc/modprobe.d (which I believe has nothing to do with this, but mention for full disclosure) I can no longer login with my LDAP (389-ds) credentials (or any other 389 accounts for that matter). I didn't make a single change that directly affects the 389-ds software installed on my single server; and I just reconfirmed that the process is currently up and running.
I did make changes to the firewall rules, I had to change the incoming rules from ACCEPT to DROP (could this be it, I don't know?).
I did make changes to /etc/pam.d/system-auth and password-auth and have reconfirmed the text looks correct according to the provided documentation.
I did make changes to /etc/login.defs.
However, I don't know what else I could have possibly changed that broke this workstation's ability to accept LDAP user authentication. Other machines, purposely not changed, still work just fine, but not this machine dt5.
While reviewing the /var/log/secure file on dt5; and tailing the log file as I attempted to initiate a new console session as my own user from LDAP (I performed a Switch User attempt) I see the following:
<DATE_STAMP1> sshd[3110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=srv1.dom.ain user=wsf29221
<DATE_STAMP1> sshd[3110]: Failed password for wsf29221 from <IP_attempting_SSH_From> port 63337 ssh2
<DATE_STAMP2> Connection closed by <IP_attempting_SSH_From>.
Since seeing all of these errors, and I mentioned that I did change /etc/login.defs-- PASS_MIN_LEN and set it to 15, from the original 8; I have also gone into 389-console and set the password requirements to match the same values to ensure that wasn't the reason for failure.
Even after I changed my password to match the new password_complexity, the problem still did not go away.
My Local account does work fine, without any adjustment, not even for the new password complexity.
Please help, I don't know what else to back out to resolve this problem,
I am running CentOS-6.7,
389-ds-base-1.2.11.15-72.el6_7.x86_64 with
pam-1.1.1-20.el6_7.x86_64, and
openssh-server-5.3p1-114.el6_7.x86_64
I have been implementing STIG security requirements starting on Friday. I have in this environment local (/etc/shadow & passwd file entries) accounts and also 389-ds accounts on this network of 6 workstations and 1 server. I made several changes to dt5; and only dt5. All of the other machines were deliberately isolated from the changes so that I would only ruin/have to repair a single system (plus I will rebuild them with my hardening script that is run in the kickstart %post section when I have tested successfully the changes I am trying to make).
After making changes to several files, to include a new file for /etc/modprobe.d (which I believe has nothing to do with this, but mention for full disclosure) I can no longer login with my LDAP (389-ds) credentials (or any other 389 accounts for that matter). I didn't make a single change that directly affects the 389-ds software installed on my single server; and I just reconfirmed that the process is currently up and running.
I did make changes to the firewall rules, I had to change the incoming rules from ACCEPT to DROP (could this be it, I don't know?).
I did make changes to /etc/pam.d/system-auth and password-auth and have reconfirmed the text looks correct according to the provided documentation.
I did make changes to /etc/login.defs.
However, I don't know what else I could have possibly changed that broke this workstation's ability to accept LDAP user authentication. Other machines, purposely not changed, still work just fine, but not this machine dt5.
While reviewing the /var/log/secure file on dt5; and tailing the log file as I attempted to initiate a new console session as my own user from LDAP (I performed a Switch User attempt) I see the following:
<DATE_STAMP1> sshd[3110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=srv1.dom.ain user=wsf29221
<DATE_STAMP1> sshd[3110]: Failed password for wsf29221 from <IP_attempting_SSH_From> port 63337 ssh2
<DATE_STAMP2> Connection closed by <IP_attempting_SSH_From>.
Since seeing all of these errors, and I mentioned that I did change /etc/login.defs-- PASS_MIN_LEN and set it to 15, from the original 8; I have also gone into 389-console and set the password requirements to match the same values to ensure that wasn't the reason for failure.
Even after I changed my password to match the new password_complexity, the problem still did not go away.
My Local account does work fine, without any adjustment, not even for the new password complexity.
Please help, I don't know what else to back out to resolve this problem,
Last edited by warron.french on 2016/06/09 23:15:29, edited 1 time in total.
Thanks,
War
War
Re: SSH authentication with 389-ds fails now
Don't know the details, but whatever...STIG security requirements
Okay so now I assume you have passwd/shadow objects in LDAP.389-ds accounts on this network
Who is dt5 and why should i care?I made several changes to dt5; and only dt5
Very good idea, I wish more people would have your risk aversion.All of the other machines were deliberately isolated from the changes so that I would only ruin/have to repair a single system
Bugger is the most often received word for these kind of scenarios.I can no longer login with my LDAP
Are you sure? LDAP is a distributed system.I didn't make a single change that directly affects the 389-ds software installed on my single server;
Big clue: LDAP is TCP/389 (thus the Fedora/iPlanet project name) and 636/tcp for LDAPSI did make changes to the firewall rules, I had to change the incoming rules from ACCEPT to DROP (could this be it, I don't know?).
That's probably the source of error - PAM blows fish like barrels hold water....I did make changes to /etc/pam.d/system-auth and password-auth and have reconfirmed the text looks correct according to the provided documentation.
Ah dt5. Well start at the beginning, does it bind to the directory server? Given the fact that it's only *this* machine, suggests a local issue.However, I don't know what else I could have possibly changed that broke this workstation's ability to accept LDAP user authentication. Other machines, purposely not changed, still work just fine, but not this machine dt5.
Yeah PAM still blows, could be one of many issues, no real clue here, except "it no work!" Mind, PAM could have a different stack with sshd versus console login (or even telnet) - it depends on what's been done.<DATE_STAMP1> sshd[3110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=srv1.dom.ain user=wsf29221
<DATE_STAMP1> sshd[3110]: Failed password for wsf29221 from <IP_attempting_SSH_From> port 63337 ssh2
<DATE_STAMP2> Connection closed by <IP_attempting_SSH_From>.
Well are you using a passwd length of more than 14?I did change /etc/login.defs-- PASS_MIN_LEN and set it to 15, from the original 8; I have also gone into 389-console and set the password requirements to match the same values to ensure that wasn't the reason for failure.
So now is guess time. The shadow objects (RFC2307) work pretty much like yp/NIS (bar RPC used in place of LDAP). "Inside" (attributes) them LDAP objects is the algo. used (crypt/SSHA etc.) perhaps a mismatch there? Are the attributes readable? Can we bind to the LDAP server(s)?Even after I changed my password to match the new password_complexity, the problem still did not go away.
So the issue is with LDAP - but very probably with PAM.My Local account does work fine, without any adjustment, not even for the new password complexity.
So to attempt to summarize:
1) Relax. Sh*t happens .
2) Can the client bind to the LDAP server - i.e.: does it even get there?
3) Problem *sounds* (doesn't mean it is) to be within the PAM stack - review that.
- warron.french
- Posts: 616
- Joined: 2014/03/27 20:21:58
Re: SSH authentication with 389-ds fails now
aks, thanks for the walk-through, I am heading back over to that environment in about 1 hour.
Thanks,
Thanks,
Thanks,
War
War
- warron.french
- Posts: 616
- Joined: 2014/03/27 20:21:58
Re: SSH authentication with 389-ds fails now
aks, after removing the pam_faillock.so lines from the AUTH, ACCOUNT and SESSION sections of both the:
/etc/pam.d/system-auth, and the
/etc/pam.d/password-auth files.
My system went back to being usable with 389-ds again; these were the lines that I removed/hashed-out (to fix the problem):
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600
account required pam_faillock.so
If I can generate a copy of both files' content here; could/would you mind aiding me in correcting this weird 389DS/pam_faillock.so issue?
The task I am trying to complete is to get a given account that has been password-failed 3 times in a 15 minute period to lockout; and then 15 minutes later unlock again; unless the pam_tally2 command is used by the SA (that would be me as well) to unlock that account.
Thanks,
/etc/pam.d/system-auth, and the
/etc/pam.d/password-auth files.
My system went back to being usable with 389-ds again; these were the lines that I removed/hashed-out (to fix the problem):
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600
account required pam_faillock.so
If I can generate a copy of both files' content here; could/would you mind aiding me in correcting this weird 389DS/pam_faillock.so issue?
The task I am trying to complete is to get a given account that has been password-failed 3 times in a 15 minute period to lockout; and then 15 minutes later unlock again; unless the pam_tally2 command is used by the SA (that would be me as well) to unlock that account.
Thanks,
Thanks,
War
War
Re: SSH authentication with 389-ds fails now
So it might be something like PAM tries more than 3 times to get the right password combo for the LDAP thingy and thus PAM goes and locks it out. I seem to recall a try_first_pass arg being used by PAM (although the exact phrase may be different - I'm doing this from memory). Can't you just do it with the LDAP server (see http://directory.fedoraproject.org/docs ... esign.html)?
I know what password policy (LDAP side) is in FreeIPA (which I think uses 389) see https://docs.fedoraproject.org/en-US/Fe ... olicy.html and looking at the 389 link it looks a little incomplete, but didn't read it - perhaps it'll do what you want?
Really the "nice" way of doing it would be to have the LDAP server do all the authentication bits and then you have significantly less client side configuration plus a nice separation of concerns.
I know what password policy (LDAP side) is in FreeIPA (which I think uses 389) see https://docs.fedoraproject.org/en-US/Fe ... olicy.html and looking at the 389 link it looks a little incomplete, but didn't read it - perhaps it'll do what you want?
Really the "nice" way of doing it would be to have the LDAP server do all the authentication bits and then you have significantly less client side configuration plus a nice separation of concerns.
- warron.french
- Posts: 616
- Joined: 2014/03/27 20:21:58
Re: SSH authentication with 389-ds fails now
aks wrote:So it might be something like PAM tries more than 3 times to get the right password combo for the LDAP thingy and thus PAM goes and locks it out. I seem to recall a try_first_pass arg being used by PAM (although the exact phrase may be different - I'm doing this from memory). Can't you just do it with the LDAP server (see http://directory.fedoraproject.org/docs ... esign.html)?
I know what password policy (LDAP side) is in FreeIPA (which I think uses 389) see https://docs.fedoraproject.org/en-US/Fe ... olicy.html and looking at the 389 link it looks a little incomplete, but didn't read it - perhaps it'll do what you want?
Really the "nice" way of doing it would be to have the LDAP server do all the authentication bits and then you have significantly less client side configuration plus a nice separation of concerns.
Thanks aks, I can't alter this system to a newer software implementation now. I am sort of stuck with what is in place. I didn't know that 389ds offered the password policy on account lockouts after 3 failed attempts in a given period of time. I do know, however, that it offers the ability to establish password complexity requirements.
Thanks,
War
War
Re: SSH authentication with 389-ds fails now
Okay, can you post your PAM stack?
Can you post an example user object with it's attributes?
I'm just looking to confirm or deny the things I posted above.
Can you post an example user object with it's attributes?
I'm just looking to confirm or deny the things I posted above.
- warron.french
- Posts: 616
- Joined: 2014/03/27 20:21:58
Re: SSH authentication with 389-ds fails now
PAM Stack, I will have to go over to the other building and re-type into this screen; since the system is physically isolated onto a separate network.aks wrote:Okay, can you post your PAM stack?
Can you post an example user object with it's attributes?
I'm just looking to confirm or deny the things I posted above.
Example user with attributes... do you mean execute an ldapsearch of the user I was testing against and provide the dn: line and everything below it?
Thanks aks,
Thanks,
War
War
Re: SSH authentication with 389-ds fails now
I mean the class names and hierarchy (objectClass lines) and all attributes (uid, cn, dn, etc.)
- warron.french
- Posts: 616
- Joined: 2014/03/27 20:21:58
Re: SSH authentication with 389-ds fails now
aks, sorry that it took me so long; I have been out of the office sick for the past 1.5 weeks.aks wrote:Okay, can you post your PAM stack?
Can you post an example user object with it's attributes?
I'm just looking to confirm or deny the things I posted above.
Anyway, here is a copy of the content for the /etc/pam.d/system-auth file
Code: Select all
#%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 required pam_tally2.so deny=3 onerr=fail unlock_time=900 even_deny_root
###auth required pam_faillock.so preauth silent deny=3 unlock_time=604800 fail_interval=900
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so try_first_pass
###auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_past
auth required pam_deny.so
account required pam_unix.so broken_shadow
account required pam_tally2.so
account sufficient pam_localuser.so
###account required pam_faillock.so
account sufficient pam_succeed_if.so uid >= 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type= dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=8
password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session required pam_lastlog.so showfailed
session optional pam_oddjob_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
Below are the associated contents of the /etc/pam.d/password-auth file as well:
Code: Select all
#%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 required pam_tally2.so deny=3 onerr=fail unlock_time=900 even_deny_root
###auth required pam_faillock.so preauth silent deny=3 unlock_time=604800 fail_interval=900
###
auth sufficient pam_unix.so nullok try_first_pass
###auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_past
auth required pam_deny.so
account required pam_unix.so broken_shadow
account required pam_tally2.so
account sufficient pam_localuser.so
###account required pam_faillock.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
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 retry=3 type=
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
#
session optional pam_oddjob_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
Thanks for any helpful input aks,
Thanks,
War
War