[RESOLVED] - SSH authentication with 389-ds fails now

[warron.french]

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,

[aks]

STIG security requirements

Don't know the details, but whatever...

389-ds accounts on this network

Okay so now I assume you have passwd/shadow objects in LDAP.

I made several changes to dt5; and only dt5

Who is dt5 and why should i care?

All of the other machines were deliberately isolated from the changes so that I would only ruin/have to repair a single system

Very good idea, I wish more people would have your risk aversion.

I can no longer login with my LDAP

Bugger is the most often received word for these kind of scenarios.

I didn't make a single change that directly affects the 389-ds software installed on my single server;

Are you sure? LDAP is a distributed system.

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?).

Big clue: LDAP is TCP/389 (thus the Fedora/iPlanet project name) and 636/tcp for LDAPS

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.

That's probably the source of error - PAM blows fish like barrels hold water....

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.

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.

<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>.

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.

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.

Well are you using a passwd length of more than 14?

Even after I changed my password to match the new password_complexity, the problem still did not go away.

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)?

My Local account does work fine, without any adjustment, not even for the new password complexity.

So the issue is with LDAP - but very probably with PAM.

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]

aks, thanks for the walk-through, I am heading back over to that environment in about 1 hour.

Thanks,

[warron.french]

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,

[aks]

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.

[warron.french]

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.

[aks]

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.

[warron.french]

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.

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.

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,

[aks]

I mean the class names and hierarchy (objectClass lines) and all attributes (uid, cn, dn, etc.)

[warron.french]

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.

aks, sorry that it took me so long; I have been out of the office sick for the past 1.5 weeks.

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

The lines that are "###" out are the ones that break my system immediately if they are uncommented. It looks like I also added in pam_tally2.so (in the auth and account sections) is it possible these are causing a conflict?


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

The files match precisely what I have on the workstation. I have deliberately not implemented the changes on another workstation (made from the same baseline); but there are 5 other workstations that are intended to be configured similarly when I get past this hurdle.

Thanks for any helpful input aks,