On 16/10/2017 18:18, Rowland Penny wrote:> > 'workgroup' is not the netbios name, it is the NetBIOS domain name. > The workgroup should also not have a dot in it, 'DOMAIN.LAN' looks > suspiciously like a dns and realm name. >Indeed i lacked of precision, purpose of the post was more "change NetBIOS domain name during clasicupgrade". DOMAIN.LAN is the previous NetBIOS domain name (I know about the dots, but it was not set by me at the time), and that's precisely what i try to change during the classic upgrade, for a new name (without dot), like "NEWDOMAIN"> > > [global] > > > > netbios name = SRV-AD > > Would 'srv-ad' be the hostname of the computer ?Yes It would> > Lets start with you posting the [global] part of the smb.conf before > you did anything.Here's what looks like the smb.conf before I do anything (more complete this time): [global] netbios name = AD workgroup = DOMAIN.LAN server string = Samba server domain.lan security = user passdb backend = ldapsam:"ldap://192.168.1.20/ ldap://192.168.1.21/" domain master = yes domain logons = yes admin users = "@Admin" ldap suffix = dc=domain.lan, dc=local ldap machine suffix = ou=hosts ldap user suffix = ou=users ldap group suffix = ou=groups ldap admin dn = "uid=sysadmin,ou=sysuers,dc=domain.lan,dc=local" obey pam restrictions = yes encrypt passwords = yes ldap password sync = yes logon path ldapsam:trusted = yes wins support = yes dns proxy = no> > > >If it can help, I noticed that winbind was not > > installed on the server; > > > > #systemctl status winbind > > winbind.service > > Loaded: error (Reason: No such file or directory) > > Active: inactive (dead) > > > > Looks like you have fallen for the 'Debian nolonger installs winbind > when you install samba' feature. You need to install winbind manually. > > Rowland >winbind was not installed on the old Samba 3 server (running OpenSUSE), and i just wonder if it matters to install it for the classicupgrade purpose, otherwise I'll just reinstall it on the new Samba 4 server Also I was pointing out that it was certainly SID related because each time I change workgroup, it just renew the domain SID; Before I change anything: # net getdomainsid SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 SID for domain DOMAIN.LAN is: S-1-5-21-1905493267-1041818301-753029000 After I change the workgroup: # net getdomainsid SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 SID for domain NEWDOMAIN is: S-1-5-21-574297740-925364648-4230334621
On Tue, 17 Oct 2017 10:00:51 +0200 Sami Chibani via samba <samba at lists.samba.org> wrote:> > > On 16/10/2017 18:18, Rowland Penny wrote: > > > > 'workgroup' is not the netbios name, it is the NetBIOS domain name. > > The workgroup should also not have a dot in it, 'DOMAIN.LAN' looks > > suspiciously like a dns and realm name. > > > Indeed i lacked of precision, purpose of the post was more "change > NetBIOS domain name during clasicupgrade". > DOMAIN.LAN is the previous NetBIOS domain name (I know about the > dots, but it was not set by me at the time), and that's precisely > what i try to change during the classic upgrade, for a new name > (without dot), like "NEWDOMAIN" > > > > > > [global] > > > > > > netbios name = SRV-AD > > > > Would 'srv-ad' be the hostname of the computer ? > Yes It would > > > > Lets start with you posting the [global] part of the smb.conf before > > you did anything. > Here's what looks like the smb.conf before I do anything (more > complete this time): > > [global] > > netbios name = AD > > workgroup = DOMAIN.LAN > > server string = Samba server domain.lan > > security = user > > passdb backend = ldapsam:"ldap://192.168.1.20/ > ldap://192.168.1.21/" > > domain master = yes > domain logons = yes > admin users = "@Admin" > ldap suffix = dc=domain.lan, dc=local > ldap machine suffix = ou=hosts > ldap user suffix = ou=users > ldap group suffix = ou=groups > ldap admin dn = "uid=sysadmin,ou=sysuers,dc=domain.lan,dc=local" > obey pam restrictions = yes > encrypt passwords = yes > ldap password sync = yes > > logon path > > ldapsam:trusted = yes > > wins support = yes > dns proxy = no > > > > > > > > >If it can help, I noticed that winbind was not > > > installed on the server; > > > > > > #systemctl status winbind > > > winbind.service > > > Loaded: error (Reason: No such file or directory) > > > Active: inactive (dead) > > > > > > > Looks like you have fallen for the 'Debian nolonger installs winbind > > when you install samba' feature. You need to install winbind > > manually. > > > > Rowland > > > winbind was not installed on the old Samba 3 server (running > OpenSUSE), and i just wonder if it matters to install it for the > classicupgrade purpose, otherwise I'll just reinstall it on the new > Samba 4 server > > Also I was pointing out that it was certainly SID related because > each time I change workgroup, it just renew the domain SID; > > Before I change anything: > # net getdomainsid > SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 > SID for domain DOMAIN.LAN is: S-1-5-21-1905493267-1041818301-753029000 > > After I change the workgroup: > # net getdomainsid > SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 > SID for domain NEWDOMAIN is: S-1-5-21-574297740-925364648-4230334621 >Why, oh why, would anybody use 'dc=domain.lan, dc=local' instead of 'dc=domain, dc=lan' ??? This isn't really the problem though, the 'workgroup' didn't need to be 'DOMAIN.LAN' in the first place and if you change it, it becomes a new domain and hence a new SID. I 'think' you need to do the changes before doing the 'classicupgrade'. I would do it step by step (in a test environment), first dump LDAP to an ldif, change 'dc=domain.lan, dc=local' to something reasonable and import the ldif into a new LDAP setup, make the required changes to smb.conf without changing the workgroup and see what happens. If this works, get the local and Domain SIDs with 'net getlocalsid' & 'net getdomainsid', change the workgroup in smb.conf, start Samba and try resetting the SIDs with 'net setlocalsid LOCALSID' and 'net setdomainsid DOMAINSID' I have no idea if the above will work, I have never tried it ;-) It does seem logical though and may be the only way you can do what you require. If you only have a few clients, it might be easier to set up the AD domain from new. Rowland
Well, let's try to be more precise about my issue and give some updates: I try to make a classicupgrade and meanwhile, change the Domain name during the process, which includes realm and NetBIOS domain name. I precisely meet difficulties with changing the NetBIOS domain name. What i've tried so far: 1) Change the NetBIOS domain name "workgroup" attribute on the old Samba 3 server before migration; Each time this operation will also change the domain SID and I lose all my members. I tried to put back the old domain sid with #net setdomainsid [original SID] But this never worked 2) As all my attempts to reset the domain SID to its initial value after workgroup change failed on the old Samba 3 server before classicupgrade, i just tried to do it after. I ran classicupgrade, and let workgroup attribute to old value. Just after migration, here's how looks like the domain: #samba-tool domain info 192.168.1.60 Forest : newdomain.lan Domain : newdomain.lan. Netbios domain : OLDDOMAIN.LAN ## The old name DC name : srv-ad.newdomain.lan DC netbios name : SRV-AD Server site : Default-First-Site-Name Client site : Default-First-Site-Name Everythings works fine, i got all my users, and machines find back the DC. And winbindd maps all users under this name: #wbinfo -u OLDDOMAIN.LAN\user my logs show no error, and here what looks like my smb.conf: [global] netbios name = SRV-AD realm = NEWDOMAIN.LAN workgroup = OLDDOMAIN.LAN server role = active directory domain controller idmap_ldb:use rfc2307 = yes tls enabled = yes tls keyfile = tls/myKey.pem tls certfile = tls/myCert.pem tls cafile dns forwarder = 192.168.200.3 #external DNS Then when i change the value "workgroup" of smb.conf in order to change the NetBIOS domain name and reload, this time i notice that my domain SID remains the same before and after the change. This time also the command pdbedit -L catches all users like before the change. However, there seems to be an issue with winbindd. Any wbinfo-u fails, and wbinfo -p doesnt ping anymore: #wbinfo -p Ping to winbindd failed could not ping winbindd! Here's the logs: oct. 17 14:08:37 srv-ad.newdomain.lan systemd[1]: Started Samba AD Daemon. oct. 17 14:08:37 srv-ad.newdomain.lan samba[489]: [2017/10/17 14:08:37.274937, 0] ../lib/util/become_daemon.c:124(daemon_ready) oct. 17 14:08:37 srv-ad.newdomain.lan samba[489]: STATUS=daemon 'samba' finished starting up and ready to serve connections oct. 17 14:08:37 srv-ad.newdomain.lan samba[509]: [2017/10/17 14:08:37.317594, 0] ../source4/lib/tls/tlscert.c:57(tls_cert_generate) oct. 17 14:08:37 srv-ad.newdomain.lan samba[509]: TLS autogeneration skipped - some TLS files already exist oct. 17 14:08:38 srv-ad.newdomain.lan samba[519]: [2017/10/17 14:08:38.671074, 0] ../source4/smbd/service_task.c:35(task_server_terminate) oct. 17 14:08:38 srv-ad.newdomain.lan samba[519]: task_server_terminate: [Failed to obtain server credentials, perhaps a standalone server?: NT_STATUS_CANT_ACCESS_DOMAIN_INFO oct. 17 14:08:38 srv-ad.newdomain.lan samba[519]: ] oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: [2017/10/17 14:08:39.371865, 0] ../source4/smbd/server.c:211(samba_terminate) oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: samba_terminate of 519: Failed to obtain server credentials, perhaps a standalone server?: NT_STATUS_CANT_ACCESS_DOMAIN_INFO oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: oct. 17 14:08:40 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 14:08:40.117399, 0] ../source3/winbindd/winbindd_cache.c:3244(initialize_winbindd_cache) oct. 17 14:08:40 srv-ad.newdomain.lan winbindd[517]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 14:08:42.421031, 0] ../source3/winbindd/winbindd_util.c:772(migrate_secrets_tdb_to_ldb) oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: Failed to fetch our own, local AD domain join password for winbindd's internal use, both from secrets.tdb and secrets.ldb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 14:08:42.423250, 0] ../source3/winbindd/winbindd_util.c:872(init_domain_list) oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: Failed to migrate our own, local AD domain join password for winbindd's internal use into secrets.tdb oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 14:08:42.423828, 0] ../source3/winbindd/winbindd.c:1401(winbindd_register_handlers) oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: unable to initialize domain list oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: [2017/10/17 14:08:42.473613, 0] ../source4/winbind/winbindd.c:47(winbindd_done) oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: winbindd daemon died with exit status 1 oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: [2017/10/17 14:08:42.473754, 0] ../source4/smbd/service_task.c:35(task_server_terminate) oct. 17 14:08:42 srvads.ensfea.fr samba[514]: task_server_terminate: [winbindd child process exited] oct. 17 14:08:44 srvads.ensfea.fr smbd[512]: [2017/10/17 14:08:44.734297, 0] ../lib/util/become_daemon.c:124(daemon_ready) oct. 17 14:08:44 srvads.ensfea.fr smbd[512]: STATUS=daemon 'smbd' finished starting up and ready to serve connections oct. 17 14:08:58 srvads.ensfea.fr samba[518]: [2017/10/17 14:08:58.529754, 0] ../source4/dsdb/dns/dns_update.c:290(dnsupdate_nameupdate_done) oct. 17 14:08:58 srvads.ensfea.fr samba[518]: ../source4/dsdb/dns/dns_update.c:290: Failed DNS update - with error code 110 I feel i'm quite close from the goal but definitely stuck at some obvious point... Any way i definitely don't want to give up otherwise would mean rebuild a domain of 300 machines and 3000 accounts... Your help is greatly appreciated... Thanks by advance Sam On 17/10/2017 10:00, Sami Chibani wrote:> > > Here's what looks like the smb.conf before I do anything (more > complete this time): > > [global] > > netbios name = AD > > workgroup = DOMAIN.LAN > > server string = Samba server domain.lan > > security = user > > passdb backend = ldapsam:"ldap://192.168.1.20/ ldap://192.168.1.21/" > > domain master = yes > domain logons = yes > admin users = "@Admin" > ldap suffix = dc=domain.lan, dc=local > ldap machine suffix = ou=hosts > ldap user suffix = ou=users > ldap group suffix = ou=groups > ldap admin dn = "uid=sysadmin,ou=sysuers,dc=domain.lan,dc=local" > obey pam restrictions = yes > encrypt passwords = yes > ldap password sync = yes > > logon path > > ldapsam:trusted = yes > > wins support = yes > dns proxy = no > > Also I was pointing out that it was certainly SID related because each > time I change workgroup, it just renew the domain SID; > > Before I change anything: > # net getdomainsid > SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 > SID for domain DOMAIN.LAN is: S-1-5-21-1905493267-1041818301-753029000 > > After I change the workgroup: > # net getdomainsid > SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 > SID for domain NEWDOMAIN is: S-1-5-21-574297740-925364648-4230334621 > > > > >
On Tue, 17 Oct 2017 14:56:27 +0200 Sami Chibani via samba <samba at lists.samba.org> wrote:> Well, let's try to be more precise about my issue and give some > updates: > > I try to make a classicupgrade and meanwhile, change the Domain name > during the process, which includes realm and NetBIOS domain name. I > precisely meet difficulties with changing the NetBIOS domain name. > > What i've tried so far: > > 1) > > Change the NetBIOS domain name "workgroup" attribute on the old Samba > 3 server before migration; Each time this operation will also change > the domain SID and I lose all my members. I tried to put back the old > domain sid with > > #net setdomainsid [original SID] > > But this never worked > > 2) > As all my attempts to reset the domain SID to its initial value after > workgroup change failed on the old Samba 3 server before > classicupgrade, i just tried to do it after. > > I ran classicupgrade, and let workgroup attribute to old value. > Just after migration, here's how looks like the domain: > > #samba-tool domain info 192.168.1.60 > Forest : newdomain.lan > Domain : newdomain.lan. > Netbios domain : OLDDOMAIN.LAN ## The old name > DC name : srv-ad.newdomain.lan > DC netbios name : SRV-AD > Server site : Default-First-Site-Name > Client site : Default-First-Site-Name > > Everythings works fine, i got all my users, and machines find back > the DC. And winbindd maps all users under this name: > > #wbinfo -u > > OLDDOMAIN.LAN\user > > my logs show no error, and here what looks like my smb.conf: > > [global] > netbios name = SRV-AD > realm = NEWDOMAIN.LAN > workgroup = OLDDOMAIN.LAN > server role = active directory domain controller > idmap_ldb:use rfc2307 = yes > tls enabled = yes > tls keyfile = tls/myKey.pem > tls certfile = tls/myCert.pem > tls cafile > dns forwarder = 192.168.200.3 #external DNS > > Then when i change the value "workgroup" of smb.conf in order to > change the NetBIOS domain name and reload, this time i notice that my > domain SID remains the same before and after the change. > > This time also the command pdbedit -L catches all users like before > the change. > > However, there seems to be an issue with winbindd. > > Any wbinfo-u fails, and wbinfo -p doesnt ping anymore: > > #wbinfo -p > Ping to winbindd failed > could not ping winbindd! > > > Here's the logs: > > oct. 17 14:08:37 srv-ad.newdomain.lan systemd[1]: Started Samba AD > Daemon. oct. 17 14:08:37 srv-ad.newdomain.lan samba[489]: [2017/10/17 > 14:08:37.274937, 0] ../lib/util/become_daemon.c:124(daemon_ready) > oct. 17 14:08:37 srv-ad.newdomain.lan samba[489]: STATUS=daemon > 'samba' finished starting up and ready to serve connections > oct. 17 14:08:37 srv-ad.newdomain.lan samba[509]: [2017/10/17 > 14:08:37.317594, > 0] ../source4/lib/tls/tlscert.c:57(tls_cert_generate) oct. 17 > 14:08:37 srv-ad.newdomain.lan samba[509]: TLS autogeneration > skipped - some TLS files already exist oct. 17 14:08:38 > srv-ad.newdomain.lan samba[519]: [2017/10/17 14:08:38.671074, 0] > ../source4/smbd/service_task.c:35(task_server_terminate) > oct. 17 14:08:38 srv-ad.newdomain.lan samba[519]: > task_server_terminate: [Failed to obtain server credentials, perhaps > a standalone server?: NT_STATUS_CANT_ACCESS_DOMAIN_INFO > oct. 17 14:08:38 srv-ad.newdomain.lan samba[519]: ] > oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: [2017/10/17 > 14:08:39.371865, 0] ../source4/smbd/server.c:211(samba_terminate) > oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: samba_terminate of > 519: Failed to obtain server credentials, perhaps a standalone > server?: NT_STATUS_CANT_ACCESS_DOMAIN_INFO > oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: > oct. 17 14:08:40 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 > 14:08:40.117399, 0] > ../source3/winbindd/winbindd_cache.c:3244(initialize_winbindd_cache) > oct. 17 14:08:40 srv-ad.newdomain.lan winbindd[517]: > initialize_winbindd_cache: clearing cache and re-creating with > version number 2 > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 > 14:08:42.421031, 0] > ../source3/winbindd/winbindd_util.c:772(migrate_secrets_tdb_to_ldb) > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: Failed to > fetch our own, local AD domain join password for winbindd's internal > use, both from secrets.tdb and secrets.ldb: > NT_STATUS_CANT_ACCESS_DOMAIN_INFO oct. 17 14:08:42 > srv-ad.newdomain.lan winbindd[517]: [2017/10/17 14:08:42.423250, 0] > ../source3/winbindd/winbindd_util.c:872(init_domain_list) > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: Failed to > migrate our own, local AD domain join password for winbindd's > internal use into secrets.tdb > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 > 14:08:42.423828, 0] > ../source3/winbindd/winbindd.c:1401(winbindd_register_handlers) > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: unable to > initialize domain list > oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: [2017/10/17 > 14:08:42.473613, 0] ../source4/winbind/winbindd.c:47(winbindd_done) > oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: winbindd daemon > died with exit status 1 > oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: [2017/10/17 > 14:08:42.473754, 0] > ../source4/smbd/service_task.c:35(task_server_terminate) > oct. 17 14:08:42 srvads.ensfea.fr samba[514]: task_server_terminate: > [winbindd child process exited] > oct. 17 14:08:44 srvads.ensfea.fr smbd[512]: [2017/10/17 > 14:08:44.734297, 0] ../lib/util/become_daemon.c:124(daemon_ready) > oct. 17 14:08:44 srvads.ensfea.fr smbd[512]: STATUS=daemon 'smbd' > finished starting up and ready to serve connections > oct. 17 14:08:58 srvads.ensfea.fr samba[518]: [2017/10/17 > 14:08:58.529754, 0] > ../source4/dsdb/dns/dns_update.c:290(dnsupdate_nameupdate_done) > oct. 17 14:08:58 srvads.ensfea.fr samba[518]: > ../source4/dsdb/dns/dns_update.c:290: Failed DNS update - with error > code 110 > > > I feel i'm quite close from the goal but definitely stuck at some > obvious point... > > Any way i definitely don't want to give up otherwise would mean > rebuild a domain of 300 machines and 3000 accounts... > > Your help is greatly appreciated... Thanks by advance > >OK, I can confirm that you can change the workgroup name, but you need to do it before the classicupgrade. Stop smbd, nmbd and winbind, change the workgroup in smb.conf, restart smbd, nmbd and winbind. You should now find that the SIDs haven't changed, but if you search in ldap for 'sambaDomainName', you will probably find two, one for the old workgroup and one for the new one. You will also probably find that the object for the new domain doesn't have a 'sambaNextRid' attribute, so you will need to add it with the value obtain from the old workgroup object. Now delete the old workgroup object. At this point, I stopped smbd, nmbd and winbind, left the ldap server and copied the required files to the what would become the new DC. After trying to carry out the classicupgrade, I found that if you have 'passdb backend = ldapsam' in the old smb.conf the upgrade uses, you need to change this to: passdb backend = ldapsam:"ldap://192.168.0.235" Where '192.168.0.235' is the ipaddress of the old PDC After doing all this, running 'samba-tool domain classicupgrade --dbdir=/var/lib/samba/dbdir/ --realm=test.tld /var/lib/samba/dbdir/smb.PDC.conf' Lead to an AD DC, with the REALM 'TEST.TLD' and the workgroup 'EXAMPLE'. Rowland
Hi Sami,> Well, let's try to be more precise about my issue and give some updates: > > I try to make a classicupgrade and meanwhile, change the Domain name > during the process, which includes realm and NetBIOS domain name. I > precisely meet difficulties with changing the NetBIOS domain name. > > What i've tried so far: > > 1) > > Change the NetBIOS domain name "workgroup" attribute on the old Samba 3 > server before migration; Each time this operation will also change the > domain SID and I lose all my members. I tried to put back the old domain > sid withI(d say it is better to change your netbios domain name before upgrading to Samba-AD. It is much easier since you just have to change it in smb.conf and a few entries in the ldap tree (see rowland post for more detail, it does work). But your workstation will still be looking for the old domain name, so you'll have to do a netdom move to switch to the new domain name (it should be able to re-authenticate in the new domain with its own machine account). Changing the domain name after migration in Samba-AD is possible too, but it involves recreating the domain and pipe in all the objects, so it need much more work.> #net setdomainsid [original SID] > > But this never worked > > 2) > As all my attempts to reset the domain SID to its initial value after > workgroup change failed on the old Samba 3 server before classicupgrade, > i just tried to do it after. > > I ran classicupgrade, and let workgroup attribute to old value. > Just after migration, here's how looks like the domain: > > #samba-tool domain info 192.168.1.60 > Forest : newdomain.lan > Domain : newdomain.lan. > Netbios domain : OLDDOMAIN.LAN ## The old nameyou should really get rid your Netbios domain name if it contains a DOT character. When you switch to Active Directory, you'll get into big trouble. Cheers, Denis> DC name : srv-ad.newdomain.lan > DC netbios name : SRV-AD > Server site : Default-First-Site-Name > Client site : Default-First-Site-Name > > Everythings works fine, i got all my users, and machines find back the > DC. And winbindd maps all users under this name: > > #wbinfo -u > > OLDDOMAIN.LAN\user > > my logs show no error, and here what looks like my smb.conf: > > [global] > netbios name = SRV-AD > realm = NEWDOMAIN.LAN > workgroup = OLDDOMAIN.LAN > server role = active directory domain controller > idmap_ldb:use rfc2307 = yes > tls enabled = yes > tls keyfile = tls/myKey.pem > tls certfile = tls/myCert.pem > tls cafile > dns forwarder = 192.168.200.3 #external DNS > > Then when i change the value "workgroup" of smb.conf in order to change > the NetBIOS domain name and reload, this time i notice that my domain > SID remains the same before and after the change. > > This time also the command pdbedit -L catches all users like before the > change. > > However, there seems to be an issue with winbindd. > > Any wbinfo-u fails, and wbinfo -p doesnt ping anymore: > > #wbinfo -p > Ping to winbindd failed > could not ping winbindd! > > > Here's the logs: > > oct. 17 14:08:37 srv-ad.newdomain.lan systemd[1]: Started Samba AD Daemon. > oct. 17 14:08:37 srv-ad.newdomain.lan samba[489]: [2017/10/17 > 14:08:37.274937, 0] ../lib/util/become_daemon.c:124(daemon_ready) > oct. 17 14:08:37 srv-ad.newdomain.lan samba[489]: STATUS=daemon > 'samba' finished starting up and ready to serve connections > oct. 17 14:08:37 srv-ad.newdomain.lan samba[509]: [2017/10/17 > 14:08:37.317594, 0] ../source4/lib/tls/tlscert.c:57(tls_cert_generate) > oct. 17 14:08:37 srv-ad.newdomain.lan samba[509]: TLS autogeneration > skipped - some TLS files already exist > oct. 17 14:08:38 srv-ad.newdomain.lan samba[519]: [2017/10/17 > 14:08:38.671074, 0] > ../source4/smbd/service_task.c:35(task_server_terminate) > oct. 17 14:08:38 srv-ad.newdomain.lan samba[519]: task_server_terminate: > [Failed to obtain server credentials, perhaps a standalone server?: > NT_STATUS_CANT_ACCESS_DOMAIN_INFO > oct. 17 14:08:38 srv-ad.newdomain.lan samba[519]: ] > oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: [2017/10/17 > 14:08:39.371865, 0] ../source4/smbd/server.c:211(samba_terminate) > oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: samba_terminate of > 519: Failed to obtain server credentials, perhaps a standalone server?: > NT_STATUS_CANT_ACCESS_DOMAIN_INFO > oct. 17 14:08:39 srv-ad.newdomain.lan samba[519]: > oct. 17 14:08:40 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 > 14:08:40.117399, 0] > ../source3/winbindd/winbindd_cache.c:3244(initialize_winbindd_cache) > oct. 17 14:08:40 srv-ad.newdomain.lan winbindd[517]: > initialize_winbindd_cache: clearing cache and re-creating with version > number 2 > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 > 14:08:42.421031, 0] > ../source3/winbindd/winbindd_util.c:772(migrate_secrets_tdb_to_ldb) > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: Failed to fetch > our own, local AD domain join password for winbindd's internal use, both > from secrets.tdb and secrets.ldb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 > 14:08:42.423250, 0] > ../source3/winbindd/winbindd_util.c:872(init_domain_list) > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: Failed to migrate > our own, local AD domain join password for winbindd's internal use into > secrets.tdb > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: [2017/10/17 > 14:08:42.423828, 0] > ../source3/winbindd/winbindd.c:1401(winbindd_register_handlers) > oct. 17 14:08:42 srv-ad.newdomain.lan winbindd[517]: unable to > initialize domain list > oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: [2017/10/17 > 14:08:42.473613, 0] ../source4/winbind/winbindd.c:47(winbindd_done) > oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: winbindd daemon died > with exit status 1 > oct. 17 14:08:42 srv-ad.newdomain.lan samba[514]: [2017/10/17 > 14:08:42.473754, 0] > ../source4/smbd/service_task.c:35(task_server_terminate) > oct. 17 14:08:42 srvads.ensfea.fr samba[514]: task_server_terminate: > [winbindd child process exited] > oct. 17 14:08:44 srvads.ensfea.fr smbd[512]: [2017/10/17 > 14:08:44.734297, 0] ../lib/util/become_daemon.c:124(daemon_ready) > oct. 17 14:08:44 srvads.ensfea.fr smbd[512]: STATUS=daemon 'smbd' > finished starting up and ready to serve connections > oct. 17 14:08:58 srvads.ensfea.fr samba[518]: [2017/10/17 > 14:08:58.529754, 0] > ../source4/dsdb/dns/dns_update.c:290(dnsupdate_nameupdate_done) > oct. 17 14:08:58 srvads.ensfea.fr samba[518]: > ../source4/dsdb/dns/dns_update.c:290: Failed DNS update - with error > code 110 > > > I feel i'm quite close from the goal but definitely stuck at some > obvious point... > > Any way i definitely don't want to give up otherwise would mean rebuild > a domain of 300 machines and 3000 accounts... > > Your help is greatly appreciated... Thanks by advance > > > Sam > > > On 17/10/2017 10:00, Sami Chibani wrote: >> >> >> Here's what looks like the smb.conf before I do anything (more >> complete this time): >> >> [global] >> >> netbios name = AD >> >> workgroup = DOMAIN.LAN >> >> server string = Samba server domain.lan >> >> security = user >> >> passdb backend = ldapsam:"ldap://192.168.1.20/ ldap://192.168.1.21/" >> >> domain master = yes >> domain logons = yes >> admin users = "@Admin" >> ldap suffix = dc=domain.lan, dc=local >> ldap machine suffix = ou=hosts >> ldap user suffix = ou=users >> ldap group suffix = ou=groups >> ldap admin dn = "uid=sysadmin,ou=sysuers,dc=domain.lan,dc=local" >> obey pam restrictions = yes >> encrypt passwords = yes >> ldap password sync = yes >> >> logon path >> >> ldapsam:trusted = yes >> >> wins support = yes >> dns proxy = no >> >> Also I was pointing out that it was certainly SID related because each >> time I change workgroup, it just renew the domain SID; >> >> Before I change anything: >> # net getdomainsid >> SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 >> SID for domain DOMAIN.LAN is: S-1-5-21-1905493267-1041818301-753029000 >> >> After I change the workgroup: >> # net getdomainsid >> SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 >> SID for domain NEWDOMAIN is: S-1-5-21-574297740-925364648-4230334621 >> >> >> >> >> >-- Denis Cardon Tranquil IT Systems Les Espaces Jules Verne, bâtiment A 12 avenue Jules Verne 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.55 http://www.tranquil-it-systems.fr
Hi Rowland, Denis Thank you very much for your answers, It helped really a lot. And sorry for the delay of answer, was busy on other stuff. You advices don't lead me straight to the solution, but i get improvements, thanks to it. For now, whatever i can do to change the workgroup, It changes the Domain SID. Actually it's more subtle; Before change workgroup: #net getdomainsid SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 SID for domain OLDDOMAIN.LAN is: S-1-5-21-1905493267-1041818301-753029000 After change workgroup: #net getdomainsid SID for local machine AD is: S-1-5-21-673913221-4242741474-1014044216 SID for domain NEWDOMAIN is: S-1-5-21-673913221-4242741474-1014044216 It sets domainsid to the same than localsid (And again it doesnt retrieve domain accounts) I tried also to change first localsid (net setlocalsid) to the same than the domain then change the domain sid, but it switches me again on another [new] SID... And net setdomainid never worked to reset to the original SID. I tried to manually edit secrets.tdb with tdbtools (to make it reflect the changes) and even erase it, but without success. I even tried kind of general change (new OpenLDAP with totally modified ldif with new values, modified secrets.tdb). no success. Actually i found the workaround of changing all SID user accounts with a pdbedit script (which got the advantage to write automatically the changes in the ldap), to make them corresponding the new domain SID. ex account: Before: S-1-5-21-1905493267-1041818301-753029000-17036 After: S-1-5-21-673913221-4242741474-1014044216-17036 This way, the PDC finds back all accounts in the domain. Then i run the classicupgrade. For now it seems a kind of mitigation compared to the "hard" solution of starting back from scratch and rebuild the domain. I will certainly have to rejoin all machines to the domain (hadn't time yet to test it), but if I can at least find back all users profile, i'll would be up to this path... I'll give you more details monday after further tests and troubleshoots. Still open to any advices! (about NetBIOS domain name, or about tips for rejoining machines to the domain) Thanks again, your help is unvaluable Cheers Sam On 18/10/2017 18:57, Rowland Penny wrote:> On Tue, 17 Oct 2017 14:56:27 +0200 > Sami Chibani via samba <samba at lists.samba.org > <mailto:samba at lists.samba.org>> wrote: > > > Well, let's try to be more precise about my issue and give some > > updates: > > > > I try to make a classicupgrade and meanwhile, change the Domain name > > during the process, which includes realm and NetBIOS domain name. I > > precisely meet difficulties with changing the NetBIOS domain name. > > > > What i've tried so far: > > > > 1) > > > > Change the NetBIOS domain name "workgroup" attribute on the old Samba > > 3 server before migration; Each time this operation will also change > > the domain SID and I lose all my members. I tried to put back the old > > domain sid with > > > > #net setdomainsid [original SID] > > > > But this never worked > > > > 2) > > As all my attempts to reset the domain SID to its initial value after > > workgroup change failed on the old Samba 3 server before > > classicupgrade, i just tried to do it after. > > > > I ran classicupgrade, and let workgroup attribute to old value. > > Just after migration, here's how looks like the domain: > > > > #samba-tool domain info 192.168.1.60 > > Forest : newdomain.lan > > Domain : newdomain.lan. > > Netbios domain : OLDDOMAIN.LAN ## The old name > > DC name : srv-ad.newdomain.lan > > DC netbios name : SRV-AD > > Server site : Default-First-Site-Name > > Client site : Default-First-Site-Name > > > > Everythings works fine, i got all my users, and machines find back > > the DC. And winbindd maps all users under this name: > > > > #wbinfo -u > > > > OLDDOMAIN.LAN\user > > > > my logs show no error, and here what looks like my smb.conf: > > > > [global] > > netbios name = SRV-AD > > realm = NEWDOMAIN.LAN > > workgroup = OLDDOMAIN.LAN > > server role = active directory domain controller > > idmap_ldb:use rfc2307 = yes > > tls enabled = yes > > tls keyfile = tls/myKey.pem > > tls certfile = tls/myCert.pem > > tls cafile > > dns forwarder = 192.168.200.3 #external DNS > > > > Then when i change the value "workgroup" of smb.conf in order to > > change the NetBIOS domain name and reload, this time i notice that my > > domain SID remains the same before and after the change. > > > > This time also the command pdbedit -L catches all users like before > > the change. > > > > However, there seems to be an issue with winbindd. > > > > Any wbinfo-u fails, and wbinfo -p doesnt ping anymore: > > > > #wbinfo -p > > Ping to winbindd failed > > could not ping winbindd! > > > > > > Here's the logs: > > > > oct. 17 14:08:37 srv-ad.newdomain.lan systemd[1]: Started Samba AD > > Daemon. oct. 17 14:08:37 srv-ad.newdomain.lan samba[489]: [2017/10/17 > > 14:08:37.274937, 0] ../lib/util/become_daemon.c:124(daemon_ready) > > oct. 17 14:08:37 srv-ad.newdomain.lan samba[489]: STATUS=daemon > > 'samba' finished starting up and ready to serve connections > > oct. 17 14:08:37 srv-ad.newdomain.lan samba[509]: [2017/10/17 > > OK, I can confirm that you can change the workgroup name, but you need > to do it before the classicupgrade. > > Stop smbd, nmbd and winbind, change the workgroup in smb.conf, restart > smbd, nmbd and winbind. > You should now find that the SIDs haven't changed, but if you search in > ldap for 'sambaDomainName', you will probably find two, one for the old > workgroup and one for the new one. You will also probably find that the > object for the new domain doesn't have a 'sambaNextRid' attribute, so > you will need to add it with the value obtain from the old workgroup > object. Now delete the old workgroup object. > At this point, I stopped smbd, nmbd and winbind, left the ldap server > and copied the required files to the what would become the new DC. > After trying to carry out the classicupgrade, I found that if you have > 'passdb backend = ldapsam' in the old smb.conf the upgrade uses, you > need to change this to: passdb backend = ldapsam:"ldap://192.168.0.235" > > Where '192.168.0.235' is the ipaddress of the old PDC > > After doing all this, running 'samba-tool domain classicupgrade > --dbdir=/var/lib/samba/dbdir/ > --realm=test.tld /var/lib/samba/dbdir/smb.PDC.conf' > > Lead to an AD DC, with the REALM 'TEST.TLD' and the workgroup 'EXAMPLE'. > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba