Adds possibility to change another user password

[ein]

On 06/01/2018 04:03 PM, L.P.H. van Belle wrote:
> 
>> 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. 
> 
> I had exact the same problem, what you wanted todo at 4.2, was what i did at 4.1 
> I moved from this setup. (debian sarge upgraded to wheezy in the years )
> https://lists.samba.org/archive/samba/2005-December/114817.html 
> To AD on samba 4.1.x sernet samba on debian wheezy. 
> 
>> 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.
>
> Almost same for me.. 
> 
>> 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 
>
> And you did not see any reports about to not use .local or .lan? 
> :-( see:  https://tools.ietf.org/html/rfc6762#appendix-G 

Of course I knew it, the reason was to free the foo.bar prefix (compatible with
global DNS) for new domain. But you are right, I could do it better.

>> 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.
>>
> 
> What i did at this point, i've setup a new clean AD domain. 
> All my servers/pc are in the NT4 domain. 
> 
> Even problem pc, is pulled out the old NT4 and added in the new AD domain. 
> And server that needs replacing are setup agains the new AD. 
> Any new pc is added to the AD domain. 
> 
>>
>> 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.

> Not if you setup your GPOs to match your old settings.
> All my users in the new domain login by AD domain, and get a new clean profile. 
> But with the same settings als the old NT4 domain all done by GPOs. 
> 
> This left me with only one thing todo, type the users email password. 
> ( my users dont know there own email password, thats restricted )
> 
>> 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.
> Note : There are commands to collect these to file, then transform these to setfacl command. 

I know that either, let me show you the scale:
LDAP's backup ldif file weights: ~ 5 MiB (160k lines),
Permissions backup file ~ 6 GiB. (6'520'856'330 lines),
3k users, 700 groups, 500 computers in the LDAP directory.

[root at fileserver srv]# time find "/srv/" -type f | wc -l
12'714'321

real    120m56.428s
user    0m2.722s
sys     0m11.367s

[root at fileserver srv]# time find "/srv/" -type d | wc -l
1'317'572

real    60m27.124s
user    0m1.533s
sys     0m7.913s

[root at server srv]# time du -sh ./
20.3T    ./

real    0m20.815s
user    0m0.750s
sys     0m2.051s

The permissions, users and password db are modified in real time manner few
people including company management and IT staff. People come and go from one
project to another, leave, retire whatever. The thing luckily happens only in
Europe so I can't call it global. Disabling the system for weekend/holidays is
pain but doable. Permission mistake is probably financial disaster, it has
happened already (human error), but hopefully no one noticed.

> Correct, so what you do here is every pc what logged in the AD domain, just create a drive map to the old domain. 
> ! Use format OLDDOM\%username% in the GPO settings to connect to the old server. 

[...]

> And, you are now mainting users and group in 2 domains, until everything is transfert to the AD domain. 
> Or speed up now, or relax and maintain the 2 domains a bit.
> 
> This all, resulted in, im slowly flushing my NT4 domain and migrating to the AD domain. 
> But without any rush, worries etc. just relaxing here ;-) .. 

[...]

> Move the old samba data away, the means every samba thing. NOT the company data. 
> TDB file /var/lib/samba etc cache everything, and now get the set from the new server and place that back. 
> ! Check the file and folder rights of this. 
[...]

It may be a way for some situations, but unfortunately we can't use mapped drives,
but UNC paths only, which must be compatible with few other data sharing protocols
and apps.

> Just to give people some ideas howto migrate without domain/database conversions etc. 
> Preparation time is soooo important. 

Thank you anyway for the time, even if it's not a way for me.

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