On 28/11/2013 08:53, Michael Ströder wrote:
> Changing access to userPassword, whether by ACL or by modifying
> 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
> 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
> 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.
Liam Gretton liam.gretton(a)le.ac.uk
Systems Specialist http://www.le.ac.uk/its
IT Services Tel: +44 (0)116 2522254
University of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom