directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [Studio] ModifyPasword operation support
Date Thu, 05 Mar 2020 22:02:52 GMT

On 05/03/2020 18:17, Stefan Seelmann wrote:
> On 3/5/20 9:02 AM, Emmanuel Lécharny wrote:
>> On 05/03/2020 07:48, Stefan Seelmann wrote:
>>> On 3/4/20 10:48 PM, Emmanuel Lécharny wrote:
>>>> we can't send a PasswordModify extended operation in Studio, and that is
>>>> a bit of a bother for servers that deal with support such operations.
>>>> The only way to get a password injected is to first hash it on the
>>>> client side, then send a Modify operation. This is unefficient,
>>>> especially if the server uses a specific Hash function that is not
>>>> common.
>>>> What would it take to add such a feature in Studio (more from the
>>>> functional PoV, because technically this is pretty trivial). Typically,
>>>> shouldd we have a popup where we ask which user we have to change the
>>>> password for, or is t better to right click on a user and hhave a meny
>>>> entry 'Password modification' ?
>>> A menu entry (maybe within an "Extended Operations" sub-menu) in the
>>> context makes most sense to me.
>> Yes, sounds legit. It might also be worthful to have a popup where you
>> can pick the user then modify its password.
> Hm, I thought if it's just in the context menu of the entry you select
> in the left-hand tree then we already know the user (it's DN). Studio
> also has sufficient search capabilities to find an entry, so also the
> context menu of search result entries can containt the new menu.

I think both options are valid. Either you have the entry in the 
browser, you right click on it, and get the option to change its 
password, or you don't want to bother finding the entry (something that 
might be good if there are thousands of entries...), so having the 
possibility to have a global menu entry that offers the possibility to 
find an entry is good to have.

Note that we can send the PasswordModify operation with no DN, in this 
case the logged in user will see its password modified.

> When clicking we have of course a popup where to enter the new password,
> and showing the DN. We can reuse the existing password widget in case it
> should be posssible to select different hashing methods, but I don't
> know what the extended op supports.

The idea is to not select any hash value : the server will do that. All 
in all, we just enter the previous password, the new one, and send all 
that to the server using the PasswordModify extended operation. 
Optionally, we may even not provide a password, the server will then 
generate one and return it.

>> Implementation wise, the tricky part is to check that the server
>> supports the extended operation (I think most of them do).
> Shouldn't that be exposed in RootDSE?

Yes, the PasswdModifyOID ( value should be 
returned in the RootDSE supportedExtension attribute.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message