The Samba-Bugzilla – Bug 5611
Feature request: Implement EXOP LDAP password updating/changing
Last modified: 2014-10-14 14:11:16 UTC
Implement Exop LDAP password updating, used by clients such as ldappasswd and samba.
Add a user to the directory and use ldappasswd to update the password, Also administrators should be able to update normal users passwords(in the event that passwords need to be reset).
Marking as "Feature request"
We need to support "Extended operation: 188.8.131.52.4.1.4184.108.40.206"
This feature doesn't seem to be present in real AD. So it's really just an enhancement.
Would you still like to have this feature? We are implementing at the moment the user password change mechanism syntax available in the real AD. You might want to look at this one.
Yes, we still want this additional feature. It's a useful, industry standard exop that won't conflict with AD behaviours.
anyone working on this or planing to work on this?
Especially in mixed envoronments with non-AD LDAP clients like plain LDAP Unix workstations this is a must-have. Sounds funny that Samba 4 does not allow *Unix* LDAP clients to change their passwords. (Kind of) funny though ...
(In reply to Björn Jacke from comment #6)
I'd prefer to fix the clients to work against any AD DC
instead of only working against a Samba DC.
okay, for clarification: Windows AD controllers also don't support RFC 3062 password modify extended operation. nss_ldap/sssd man change passwords with using the AD method. So offering more features than native AD controllers seems not feasible.
For people who need password modify extended operation this could be made an optional feature, which is being turned off by default thought, to be feature compatible with native AD DCs. Resolving this bug as LATER for now as this is not really needed or wanted currently.
I remember that I have started implementing it long time ago: https://git.samba.org/samba.git/?p=mdw/samba.git;a=shortlog;h=refs/heads/exop
Then I stopped to continue since the big issue was that pyldb does not permit to execute these extended operations. And also the implementation of them would have been very challenging. Jelmer, am I correct?