Adds possibility to change another user password

L.P.H. van Belle belle at bazuin.nl
Fri Jun 1 14:03:25 UTC 2018


> 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 

> foo.bar to foobar.local  
And you did not see any reports about to not use .local or .lan? 
:-( see:  https://tools.ietf.org/html/rfc6762#appendix-G 


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

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. 

There is only one catch here, dont allow users to change the passwords and the username + password must be exact the samba on both servers. 
This stays untill you have moved all your users from old to new.
Do note, the file server is often the last or the first to migrate, thats my last one. 
And ... I started 2 years ago with my migration preparation.
The old file server is still running and used and primary file 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 ;-) .. 

To help my old domain a bit, i've upgrade my Debian wheezy samba 3.6 to the backported 4.1 version. 
This helps in avoiding the SMB1 problems. ( win10 1709 and up ) 

And now slowly move everything from old to new and rely on the "pass through authentication" of windows.

For my old fileserver, i prepaired that as followed. 
What i am going todo here to make a quick move.
I've setup a new file server, all user homes and profiles are already there so i known this server runs ok. 
This is a Virtual. 
I'll perform these steps to migrate this one. From NEW to OLD. .. Yes correct from new to old. 
( That save me about 250-400GB data move over lan.) 

I using this order,
>>  Only one rule now, you computer are all gone of the old NT4 domain.  << 

I've prepaired script to convert my old data ACL to my AD data ACL.s 
Data is sync daily, acls, for now dont care about it. ( the user and profile data )
Steps

-Old (phisical) server wheezy, stop samba AND disable samba for startup. 
-New (VM) server stretch, move data to old server. ( the profils and personal data. About 10-20 GB ) 
- Upgrade debian to jessie then upgrade to stretch. 
- Rename hostname of old server to the new server new ! The same name. 
- Setup the ip of the new for the old AS primary ip, and setup the old ip as alias ip. 
- Correct hostnames where needed. 
- Down the new vm, we dont need that anymore. 
- Reboot the old so the new names and ips are active and why caching is flush als now. 
( we are now at .. Server is stretch data is there, now samba todo. ) 

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. 

Start samba, and now im on my old phisical hardware but with my new samba config and profile/user data. 
Im adding back now the company data shares in smb.conf, correct shares rights and file/folder rights. 
And done, samba bad up and running on the old server with the new settings. 

And now change the GPO drive mapping to the new server. 

This looks a lot, but this isnt, ok maybe it is, but if you prepair this good and test a bit, it saves you a lot of problems.

Im expecting for the above process about 1 hour max down time but the preparation time is more than a month. 
My user get 15 min extra lunchtime. 
My users home is setup also for offline use, only profile data gets lost if a user shuts down its pc when i make my move. 
But just inform you users to NOT logoff untill your samba is up again. 

To give an idee here. do note, i am the only one here that maintain the all IT related hardware, incl phones.
So yes that month is long but i do a lot of things here. :-/ 

I hope this helps you in giving any ideas howto move up to AD, without almost no downtime. 
Untill now, my total downtime was max 3-4 hours and about 4 hours overwork in the evening, 
8 hours in the weekend in a 1.5 year migration traject. 

I went from 3-4 server in 2005 to 20 servers in the migration proces and now slowly bit less. 
The server increasment was needed to move services from old to new, just to ease the this process. 
For example, before my file server (nt4) was also print server, in the new domain i have a dedicated print server. 

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


Greetz, 

Louis









More information about the samba-technical mailing list