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

[aks]

Why do you have both pam_tally AND pam_faillock? I think choose one or the other.

Personally, I would've just put:
Auth required pam_tally2.so Deny=3 Unlock_time=604800 Even_deny_root Root_unlock_time=5
into /etc/pam.d/sshd, I think that would achieve what you seem to want (not sure about the root unlock time, I just made that up).

[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, I am posting as you requested the results of an entry for a useraccount in my 389-ds being used in this environment; the command I used was:
ldapsearch -x uid=wsf29221
The results are here:

Code: Select all

# extended LDIF
#
# LDAP v3
# base <dc=example1,dc=erit,dc=com>  (default) with scope subtree
# filter: uid=wsf29221
# requesting: ALL
#

# wsf29221, People, example1.erit.com
dn: uid=wsf29221,ou=People,dc=example1,dc=erit,dc=com
givenName: Warron
sn: French
loginShell: /bin/bash
uidNumber: 29221
gidNumber: 101
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
uid: wsf29221
gecos: Warron French
cn: Warron French
homeDirectory: /home/wsf29221

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

That's all there is.

[aks]

Okay, thanks for posting, what I wanted to know is what kind of LDAP you're doing. FYI, RFC2307 (aka yp over LDAP). Nice and neat way to do it.

[warron.french]

Okay, thanks for posting, what I wanted to know is what kind of LDAP you're doing. FYI, RFC2307 (aka yp over LDAP). Nice and neat way to do it.

Hey no problem at all aks. I am glad I could help you too.

[warron.french]

Why do you have both pam_tally AND pam_faillock? I think choose one or the other.

Personally, I would've just put:
Auth required pam_tally2.so Deny=3 Unlock_time=604800 Even_deny_root Root_unlock_time=5
into /etc/pam.d/sshd, I think that would achieve what you seem to want (not sure about the root unlock time, I just made that up).

aks, I think I tried the pam changes (removing the ### hashes) and commenting out the pam_tally2.so lines; and it was still broken.

Do you have any ideas? I will try again by commenting out the pam_tally2.so lines everywhere in both the /etc/pam.d/{system-auth, password-auth} files - hopefully that does work.

Please though, if you determine or know for sure that this is the conflict let me know specifically.
Thanks,

[aks]

Please though, if you determine or know for sure that this is the conflict let me know specifically.

I don't know that having both "lockers" in there is the source of your problems, or not. IMO, PAM has a history of doing weird things (aka unexpected behavior) when two (or more) modules are stacked and provide similar functionality. But that's an aside.

When you manipulate the passwd and the other pam config you're applying your changes to, all modules that call them (I think that's everything), that's why I suggested sshd (as that's your test).

Also you can pass the debug parameter to (most) pam modules to get extra info (might give a clue).

I didn't see pam_ldap (or equivalent) in your config also, but perhaps you're testing locally? If so, that rules out any policy object (i.e.: certainly ones that don't have objectClass posixAccount in them). Also I seem to recall needing shadowAccount LDAP object class for the password (posixAccount implements some attributes, shadowAccount implements the functionality of /etc/shadow), but perhaps that's a different issue.

Beyond PAM, there's also SSD (just to make this sh*t harder).

[warron.french]

Please though, if you determine or know for sure that this is the conflict let me know specifically.

I don't know that having both "lockers" in there is the source of your problems, or not. IMO, PAM has a history of doing weird things (aka unexpected behavior) when two (or more) modules are stacked and provide similar functionality. But that's an aside.

When you manipulate the passwd and the other pam config you're applying your changes to, all modules that call them (I think that's everything), that's why I suggested sshd (as that's your test).

Also you can pass the debug parameter to (most) pam modules to get extra info (might give a clue).

I didn't see pam_ldap (or equivalent) in your config also, but perhaps you're testing locally? If so, that rules out any policy object (i.e.: certainly ones that don't have objectClass posixAccount in them). Also I seem to recall needing shadowAccount LDAP object class for the password (posixAccount implements some attributes, shadowAccount implements the functionality of /etc/shadow), but perhaps that's a different issue.

Beyond PAM, there's also SSD (just to make this sh*t harder).

I will remove the pam_tally2.so and re-enable the other pam_faillock.so lines to see if it helps; I am pretty sure that I tried that already though. Now I have to double-check to make sure.

Thanks,

[warron.french]

This problem was resolved. In my environment the problem was making use of the pam_faillock.so module.

Don't use pam_faillock.so, but as an alternative you can use pam_tally2.so instead; just remember to properly implement it in the password-auth and the system-auth file.

pam_tally2.so accomplished the spirit of the 'law' from the DISA STIG required of me, even though the letter of the law directly indicated the use of pam_faillock.so was required.