[RESOLVED] - SSH authentication with 389-ds fails now
Posted: 2016/05/16 17:00:12
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,