Le 04/10/2017 à 17:04, Radovan Semancik a écrit : > On 10/04/2017 01:57 PM, Shawn McKinney wrote: >> >>> On Oct 4, 2017, at 2:25 AM, Radovan Semancik >>> <[email protected]> wrote: >>> >>> The problem is that there is no standard way how to disable a user >>> in LDAP. Some LDAP servers have proprietary attributes for this. And >>> some servers (such as OpenLDAP) have no good way to do this at all. >>> Therefore there the studio has to support many algorithms and it may >>> even need custom extensions to support this properly. >> I wouldn’t characterize adherence to an expired IETF draft — >> proprietary. The main problem is LDAPv3 doesn’t include pw policies >> and the communities (us) have never bothered to ratify an extension >> as standard. > > Password expiration/disable is quite different from account disable. This was just an example. On AD, a filter like (userAccountControl:1.2.840.113556.1.4.803:=2) will match disabled users (note that we currently don't support extensible match in the API, so it would require some work on the API). The real problem would be for LDAP server that uses a group to mark a user as disabled (ie, the user is disabled if it belongs to teh Disabled group).
> E.g. even if password is expired/disabled then the user can still log > in using non-password authentication scheme, such as SSH keys on a > UNIX system. Which is a big problem. Password might not be used at all > for some usecases (e.g. X.509-based auth or federation) so there is no > password policy that could be used. But account disable is usually > still needed. Account disable should prohibit any authentication, > regardless of the authentication method. And that is something that > OpenLDAP does not have. Most other servers have it, although the > mechanism is proprietary. This is getting really important with all > that multi-factor, adaptive and token-based authentication schemes. > But as far as I know there is no good solution for this in LDAP. There > is no standard for LDAP account disable. Not even an expired one. (But > please correct me if I'm wrong. I looked for that, but I might have > overlooked something.) You are plain correct, I'm not disputing that :-) > > Therefore this means that in practice the disable mechanism is > implemented (read: worked around) by using various creative ways > (read: hacks). There is no single unified way that works for > everybody. Not even for majority of cases. It is different for every > deployment. Agreed. But we can cover many simple use cases, at least, and leave the more complex ones crumbling under their weight in the near/far future... A la Darwin. -- Emmanuel Lecharny Symas.com directory.apache.org
