On 07/20/2010 11:32 AM, Gerrard Geldenhuis wrote:
Good point... I define disabled as setting the user as disabled in
in
the console or the user having typed his password wrong to many times
and then getting locked out.
I don't see "disable" in the console. I do see "inactivate".
This adds
the ldap entry to an "inactive" role. As far as I know, any form of
inactivation or lockout in LDAP is merely going to prevent binding to
that ldap entry. The trick is, that doesn't happen with ssh keys. If
you're logging in to a system over ssh, basically the only checks that
matter are: 1) does the user exist and 2) is the key valid? Since the
password is never given, there's no attempt to bind to LDAP.
There are a number of pam_... options available in /etc/ldap.conf, but
I'm not sure if those are used when doing ssh logins with keys. That's
probably worth checking out if you use nss_ldap. There are probably
similar options for nss_sss, but I haven't looked at that yet either. :)
I still don't understand pam as well as I should but it would
make
sense to me for PAM to "check" LDAP before checking ssh... It does so
when you don't have ssh keys and would deny a user if he/she is
disabled. Maybe I should change a password sufficient to password
required. I guess I need to play around a bit more.
It won't affect sshd. I wouldn't modify the PAM configuration unless
you really know what you're doing. You're more likely to lock yourself
out completely than anything else. If you want sshd to require
passwords, change sshd's configuration so that it doesn't allow key logins.
> I believe you can use pam_access(5) to grant login access only
to
> members of a group in your directory, and remove users from that
> group when you disable their login access.
That was my plan but it is not perfect...
What's not suitable about that plan?