Adds possibility to change another user password

[Rowland Penny]

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.
 
>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 ?

Rowland