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? -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
