Adds possibility to change another user password

[ein]

On 06/01/2018 09:43 AM, Rowland Penny via samba-technical wrote:
> On Fri, 1 Jun 2018 09:22:41 +0200
> ein <ein.net at gmail.com> wrote:
>
>> On 05/31/2018 02:20 PM, Rowland Penny via samba-technical wrote:
>>> On Thu, 31 May 2018 12:08:09 +0000
>>> Github bot account via samba-technical
>>> <samba-technical at lists.samba.org> wrote:
>>>
>>>> New comment by bjacke on Samba Github repository
>>>>
>>>> https://github.com/samba-team/samba/pull/42#issuecomment-393509394
>>>> Comment:
>>>> you're right, that samba-tool is not yet very useful for Samba
>>>> servers in "classic" mode and your request to have that feature in
>>>> smbpasswd is quite valid. But the feature is already implementen as
>>>> far as I can see: as root you can run "smbpasswd foo" to set
>>>> someone's password and as a user you can set someone else's
>>>> password with "smbpasswd -U foo", can't you?
>>>>
>>>> https://bugzilla.samba.org/ is the right way to report bugs and
>>>> feature requests for Samba, please use that in the future.
>>>
>>> I don't think samba-tool will ever be useful in a classic domain
>>> and, if I were you, I would be putting my efforts into upgrading
>>> from a classic domain, before Microsoft makes it impossible to
>>> connect to one from Windows (and if recent reports are correct,
>>> they may already have done so with the latest win10).
>>
>> They did cripple end node domain enrollment in Windows 10 v1803.
>> 1. No SMB1 client in v1709 installed by default.
>> 2. Wrong computer browser service dependences in v1803, disabling
>> smb2/3 breaks it.
>>
>> Those two are reversible.
>
> They very well may be, but it still doesn't change the fact that
> Microsoft couldn't care less about NT4-style domains, they EOL'ed NT4
> over 10 years ago. Whether they break them by design or accident,
> eventually they will break them permanently. Stop trying to find
> workarounds and start planning upgrading to AD.

It's already on it's way, boss. Renaming domain and domain workstation reenrollment take time.
Thanks to you in some sense, because you did describe it here (the rename) quite well.

> If I was the big boss and came to work one morning and the domain
> didn't work, because Windows wouldn't work with the NT4-style domain
> any more. I would be asking 'why not' and 'did we have any warning
> of this'. I think you can see the outcome of that discussion.

Maybe because Samba AD did never received working trust relationship with Samba NT domain?
Or maybe because migration process eats most of the LDAP tree data?


-- 
PGP Public Key (RSA/4096b):
ID: 0xF2C6EA10
SHA-1: 51DA 40EE 832A 0572 5AD8 B3C0 7AFF 69E1 F2C6 EA10