Adds possibility to change another user password

[ein]

On 06/01/2018 10:28 AM, Rowland Penny via samba-technical wrote:
> On Fri, 1 Jun 2018 10:10:59 +0200
> ein <ein.net at gmail.com> wrote:
> 
>> 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? 
> 
> There never really was any impetus to get them working, but there has
> been quite some work done on AD trusts.

Sure, I concur the Samba team did good work on AD trusts, but no inbound
trust from NT Domain basically prevents graceful domain migration - building
it from scratch in production - the good way proposed by you and what I wanted
to do in the first place sometime after 4.2 arrived. Any other way means bumpy
road which is almost not possible in production. Let me explain. The need of
having LDAP tree in the environment is to:
- standardize authorization database in one place.
- use that database in multiple services (SMTP/IMAP, VPN, WiFi (radius), FTP,
Apache's DAV and of course the end Windows node added to the domain)
- many other organization related apps/services.

As I pointed sometime around 4.2 I renamed my NT domain from foo.bar to
foobar.local and created new DC with bind backend for foo.bar while waiting
for trusts.  Few years later around 4.5 I lost confidence whether there
ever will be working trust (which by the way was on the todo list since
beginning (well, not any more :-). Around 4.7 I started preparations to
classic NT conversation by renaming NT Domain again to foo.bar. I'm currently
finishing workstation reenrollment (~20% to go). I keep only two workstations
with Windows 10 because of it, thus the need for backward compatibility to
finish reenrollment and migration.

Why building it from scratch is almost impossible?
The cost generated by the need of Windows profile conversion from old domain
to new is putting simply massive.
The time requited to switch above services from NT Domain to AD exceeds one
free weekend in my case.
Rebuilding complex folders ACLs and user to group mappings is not an option.

That's why at least for me not having trusts is a design flaw.

>> Or maybe because migration process eats most of the LDAP tree data?
> 
> I personally wouldn't recommend the 'classicupgrade', mainly because
> Samba used to allow such low IDs and it is probably easier to set up
> a new AD domain. Having said that, the 'classicupgrade' shouldn't eat
> data, can you elaborate on what data it eats ?

I think nothing which is needed in Samba's AD environment, but may be needed in [1]

>From the tings I've discovered so far:
- personal user information (phone, e-mail, description, certificate, mail aliases)
and probably other not standard attributes. Bug reported from few years ago
not touched from at least 3, which means not 2-way authorization and no password
recovery,
- group descriptions,
- computer descriptions.

Some of the people keeps DHCP and DNS there, lucky me.

Can you please define what the low ID is for you and why do you think so.


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