[Samba] Transfer of FSMO Roles

Rowland Penny rowlandpenny at googlemail.com
Sun Nov 30 02:55:58 MST 2014 

On 29/11/14 23:58, Donaldson Jeff wrote:
> Rowland, I think things went haywire from something I did, not from following your advice. Just want to make that clear.
>
> Regards,
> Jeff
>
>
>> On Nov 29, 2014, at 2:53 PM, "Rowland Penny" <rowlandpenny at googlemail.com> wrote:
>>
>>> On 29/11/14 19:15, Donaldson Jeff wrote:
>>> Rowland,
>>>
>>> I did as you suggested and things were fine up until the point I started to manually remove the old Primary. Things went haywire and I wound up having to shutdown samba services and restore the private directory from a backup.  The backup was from a couple of weeks prior, so I had to go back through the steps of transferring the fSMO roles. I was able to successfully seize all but the naming role. Whether I try to transfer or seize, I wind up with an iteration of the following error..
>>>
>>> ERROR(ldb): uncaught exception - Failed FSMO transfer: NT_STATUS_IO_TIMEOUT
>>>    File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/__init__.py", line 175, in _run
>>>      return self.run(*args, **kwargs)
>>>    File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/fsmo.py", line 160, in run
>>>      self.seize_role(role, samdb, force)
>>>    File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/fsmo.py", line 126, in seize_role
>>>      transfer_role(self.outf, role, samdb)
>>>    File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/fsmo.py", line 53, in transfer_role
>>>      samdb.modify(m)
>>>
>>> I thought the nature of seizing a role is to forcefully set a new master without the permission of the existing master. So why would this fail? Once I get the last role, I should be able to move forward again with the removal of the old server (obviously making a back up of private prior). Any help is appreciated.
>>>
>>> Regards,
>>> Jeff
>>>
>>> Jeff Donaldson
>>> Technology Director
>>> Newark Charter School
>>> jeff.donaldson at ncs.k12.de.us
>>> (302) 369-2001 ext: 425
>>>
>>> ________________________________________
>>> From: Rowland Penny <rowlandpenny at googlemail.com>
>>> Sent: Friday, November 21, 2014 8:34 AM
>>> To: Donaldson Jeff; samba at lists.samba.org
>>> Subject: Re: [Samba] Transfer of FSMO Roles
>>>
>>>> On 21/11/14 13:06, Donaldson Jeff wrote:
>>>> Rowland,
>>>>
>>>> I can't thank you enough. Your help has been invaluable. I plan on doing this over the weekend, but I had one more question. When you say remove the original and never bring it back, that had been my plan all along. So would you suggest not trying to demote it and just rip it out as if it were an orphan?
>>>>
>>>> Regards,
>>>> Jeff
>>>>
>>>> Jeff Donaldson
>>>> Technology Director
>>>> Newark Charter School
>>>> jeff.donaldson at ncs.k12.de.us
>>>> (302) 369-2001 ext: 425
>>>>
>>>> ________________________________________
>>>> From: Rowland Penny <rowlandpenny at googlemail.com>
>>>> Sent: Friday, November 21, 2014 5:27 AM
>>>> To: Donaldson Jeff; samba at lists.samba.org
>>>> Subject: Re: [Samba] Transfer of FSMO Roles
>>>>
>>>>> On 21/11/14 01:50, Donaldson Jeff wrote:
>>>>> Rowland,
>>>>>
>>>>> Should I be editing these in sam.ldb? I did a quick search on fSMORoleOwner and only found it three times in sam.ldb. Or should I be looking elsewhere? Thanks, once again, for your help.
>>>>>
>>>>> Regards,
>>>>> Jeff
>>>>>
>>>>> Jeff Donaldson
>>>>> Technology Director
>>>>> Newark Charter School
>>>>> jeff.donaldson at ncs.k12.de.us
>>>>> (302) 369-2001 ext: 425
>>>>>
>>>>> ________________________________________
>>>>> From: samba-bounces at lists.samba.org <samba-bounces at lists.samba.org> on behalf of Rowland Penny <rowlandpenny at googlemail.com>
>>>>> Sent: Thursday, November 20, 2014 2:17 PM
>>>>> To: samba at lists.samba.org
>>>>> Subject: Re: [Samba] Transfer of FSMO Roles
>>>>>
>>>>>> On 20/11/14 18:24, Donaldson Jeff wrote:
>>>>>> Good Afternoon,
>>>>>>
>>>>>>
>>>>>> I've been working towards decommissioning my current PDC and moving Primary Master to a newly built DC. I was able to successfully transfer each of the five FSMO roles (without seizing) to the new server. I can run samba-tool fsmo show on each of my servers and they all return the new DC with each of the five roles. My question is...shouldn't transferring of the DomainNamingMasterRole affect the (SOA) and (NS) settings in DNS automatically?  They are still set to the old server, and if I look in the DomainDnsZones and ForestDnsZones in DNS Manager, they both still show records for the old server. Furthermore, trying to run samba-tool domain demote -Uadministrator on the old server returned that it still owned two roles. It is my understanding that this is a bug and that the old PDC should be pulled out of the domain as if it were an orphan. If that is the case, than how do I go about correcting DNS before I do that? Any help is appreciated. Thanks!
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>> Jeff Donaldson
>>>>>> Technology Director
>>>>>> Newark Charter School
>>>>>> jeff.donaldson at ncs.k12.de.us
>>>>>> (302) 369-2001 ext: 425
>>>>> The problem here is that there are 7 FSMO roles on a Samba4 AD DC, but
>>>>> samba-tool only seems to know about 5 of them. As you have found out,
>>>>> the 2 missing ones are:
>>>>>
>>>>> CN=Infrastructure,DC=ForestDnsZones,rootdse
>>>>>
>>>>> CN=Infrastructure,DC=DomainDnsZones,rootdse
>>>>>
>>>>> If you inspect the 'fSMORoleOwner' attribute on these two objects, I am
>>>>> fairly sure that will you find that they are pointing at the old DC, I
>>>>> presume if you change this to your new DC, your problem will go away.
>>>>>
>>>>> Rowland
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list go to the following URL and read the
>>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>> OK, you need to add a couple of options to ldbsearch to see all the FSMO
>>>> roles:
>>>>
>>>>     root at dc02:~# ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs
>>>> --show-binary -b dc=example,dc=com fSMORoleOwner | grep 'fSMORoleOwner'
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>>
>>>> There they are, all SEVEN of them!
>>>>
>>>> The ones that samba-tool knows nothing about are: ForestDnsZones &
>>>> DomainDnsZones
>>>>
>>>> To view these:
>>>>
>>>> root at dc02:~# ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs
>>>> --show-binary -b "CN=Infrastructure,DC=ForestDnsZones,DC=example,DC=com"
>>>> fSMORoleOwner
>>>>
>>>> NOTE: The above is all one line.
>>>>
>>>> # record 1
>>>> dn: CN=Infrastructure,DC=ForestDnsZones,DC=example,DC=com
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>>
>>>> root at dc02:~# ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs
>>>> --show-binary -b "CN=Infrastructure,DC=DomainDnsZones,DC=example,DC=com"
>>>> fSMORoleOwner
>>>>
>>>> # record 1
>>>> dn: CN=Infrastructure,DC=DomainDnsZones,DC=example,DC=com
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>>
>>>> Opening one of the above in ldbedit, produces this:
>>>>
>>>> ldbedit -e nano -H /var/lib/samba/private/sam.ldb --cross-ncs
>>>> --show-binary -b "CN=Infrastructure,DC=DomainDnsZones,DC=example,DC=com"
>>>>
>>>> # editing 1 records
>>>> # record 1
>>>> dn: CN=Infrastructure,DC=DomainDnsZones,DC=example,DC=com
>>>> objectClass: top
>>>> objectClass: infrastructureUpdate
>>>> cn: Infrastructure
>>>> instanceType: 4
>>>> whenCreated: 20140812094114.0Z
>>>> whenChanged: 20140812094116.0Z
>>>> uSNCreated: 3459
>>>> uSNChanged: 3459
>>>> showInAdvancedViewOnly: TRUE
>>>> name: Infrastructure
>>>> objectGUID: 825b707d-e4c7-4201-9fab-e00135189910
>>>> fSMORoleOwner: CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>> systemFlags: -1946157056
>>>> objectCategory:
>>>> CN=Infrastructure-Update,CN=Schema,CN=Configuration,DC=example,DC=com
>>>> isCriticalSystemObject: TRUE
>>>> distinguishedName: CN=Infrastructure,DC=DomainDnsZones,DC=example,DC=com
>>>>
>>>> I presume if you alter the fSMORoleOwner line to match the new DC, this
>>>> will sieze the role, you can get a list of possible role owners with:
>>>>
>>>> root at dc02:~# ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs
>>>> "(objectClass=nTDSDSA)" dn | grep 'dn:' | sed 's|dn: ||'
>>>>
>>>> CN=NTDS
>>>> Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>> CN=NTDS
>>>> Settings,CN=DC02,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=example,DC=com
>>>>
>>>> I have never tried this, so don't blame me if it messes up your AD, but
>>>> I have no reason to believe it will. You may have to remove the original
>>>> DC and never bring it back.
>>>>
>>>> Rowland
>>> OK, I looked into this some time ago and wrote a bash script to sieze
>>> the two dns roles, this script was based on a vbs script I found on the net.
>>> Until today, I had never tried the script, but I remembered that I had a
>>> test domain in a couple of VM's, one was a DC, the other a client, I set
>>> the client up as another DC and joined it to the other. I then ran my
>>> script on the second machine and the two dns roles were changed to the
>>> second machine, unfortunately they still showed (on the first machine)
>>> as being held by the first DC. I then attempted to transfer the other 5
>>> roles to the second DC, this didn't work, maybe I got the syntax wrong,
>>> but 'samba-tool fsmo transfer --help' shows this:
>>>
>>> Usage: samba-tool fsmo transfer [options]
>>>
>>> Transfer the role.
>>>
>>>
>>> Options:
>>>     -h, --help            show this help message and exit
>>>     -H URL, --URL=URL     LDB URL for database or target server
>>>     --role=ROLE           The FSMO role to seize or transfer.
>>>                           rid=RidAllocationMasterRole schema=SchemaMasterRole
>>>                           pdc=PdcEmulationMasterRole
>>>                           naming=DomainNamingMasterRole
>>>                           infrastructure=InfrastructureMasterRole all=all of
>>>                           the above
>>>
>>> It is not clear just what the option for '-H URL, --URL=URL     LDB URL
>>> for database or target server' means, I tried several variants, but it
>>> just wouldn't work.
>>>
>>> I then siezed the 5 roles on the second DC and shut down the first.
>>>
>>> Before I started:
>>>
>>> root at debdc2:~# ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs
>>> --show-binary -b dc=internal,dc=example,dc=com fSMORoleOwner | grep
>>> 'fSMORoleOwner'
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>>
>>> After I siezed the roles:
>>>
>>> root at debdc2:~# ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs
>>> --show-binary -b dc=internal,dc=example,dc=com fSMORoleOwner | grep
>>> 'fSMORoleOwner'
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>> fSMORoleOwner: CN=NTDS
>>> Settings,CN=DEBDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=internal,DC=example,DC=com
>>>
>>> As far as I am concerned, transferring the roles is broken, so I
>>> suggest  shutting down the first DC, then sieze ALL the roles on the
>>> second, never bring the first DC again.
>>>
>>> The only problem that I can see is that AD will still be peppered with
>>> the first DC, but I think that I have a script for this as well.
>>>
>>> Rowland
>> Hi, I did say that I have only done this in a test domain, and I seized all the roles at once, not one by one, there may be a set order in which to seize them, but if there is, I do not know it ;-)
>>
>> I shut the first DC down, siezed the 5 known fsmo roles, siezed the 2 unknown roles and then removed anything to do with the first DC from AD. I can only say that it seemed to work for me, but again I only did it in a test domain.
>>
>> Rowland
>>
>>
I understand that, I just wanted to point out that I have, at this 
point, never done it for 'real' :-)

Rowland

More information about the samba mailing list