Liam Gretton wrote: > On 27/11/2013 20:51, Michael Ströder wrote: >> Viviano, Brad wrote: >>> I can't foresee a time I would want a user to just disappear entirely from >>> a system because their password is locked. I don't want locked users to be >>> invisible, I want them to be locked so they can't login. >> >> Gee, can't you read about ACLs *before* responding like that. >> >> You don't have to make them invisible like I do. You can also just lock auth >> access to 'userPassword'. > > Changing access to userPassword, whether by ACL or by modifying the attribute > value itself, doesn't have any effect when the user has a SSH key because LDAP > is not involved in authentication.
Uuuhuuhh. You can even have two different ACLs for 'userPassword' and 'sshPublicKey' to solely make 'sshPublicKey' invisible. ;-) You can then let your SSH key sync script remove the key from the system's authorized keys directory. Or any other appropriate solution. > There's no clean way to deal with this in my opinion. In the past I've > modified accounts' shell attribute to prevent logins at the point they're > determined to be disabled, and put back when the account is deemed unlocked. > > Modifying the shell is useless for non-Unix systems though (web applications > for example). Yes, that's why mucking with 'loginShell' is not appropriate. Especially since you have to set it to the right old attribute value. > Now I use a custom 'lock' attribute on all accounts and use a LDAP filter at > the client end. This is fine for our purposes but could be a problem for > appliances that don't provide much in the way of LDAP configuration options. But then you could simply use this filter in an ACLs. Read slapdaccess(5) before you claim that there's no clean way. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
