On 28/11/2013 08:53, Michael Ströder wrote:
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. ;-)
That assumes you have central management of SSH keys. We don't and it would be a huge job to do so.
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.
It's moot, but that particular problem is trivial to solve, you set it to '/bin/false /old/shell' to lock and restore it to '/old/shell' to unlock.
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.
Sorry, I can't see how I can prevent non-LDAP authentication methods with a LDAP ACL and not make the user disappear from the system.