directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: [Studio] ModifyPasword operation support
Date Sun, 15 Mar 2020 10:13:48 GMT
FTR, there's already a Jira:

@Emmanuel, did you already started implementing it?

On 3/5/20 11:02 PM, Emmanuel Lécharny wrote:
> 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:

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

View raw message