Difference between revisions of "Transferring and Seizing FSMO Roles"

(Splitted content from the general FSMO page)
 
m (/* Grammar)
Line 1: Line 1:
 
= Difference of transferring and seizing FSMO roles =
 
= Difference of transferring and seizing FSMO roles =
  
Whenever it's possible, you should transfer FSMO roles and do not seize them! Transfering is the recommended and cleaner way. But it requires that the DC, which is currently owning the role you want to transfer, is still working and connected to the network. Transfering makes the old DC know, that he's not owning the role(s) any more.
+
Whenever it's possible, you should transfer FSMO roles and do not seize them! Transferring is the recommended and cleaner way. But it requires that the DC, which currently owns the role you want to transfer, is still working and connected to the network. Transferring makes the old DC know that it does not own the role(s) any more.
  
If the DC is broken (e. g. hardware defect) and surely will never come back, then you seize the role on a remaining DC. But it's very important, that the old DC will really never be connected to the network again, as it may cause conflicts and lead into an inconsitent AD, because the old DC did not notice the change and still feels responsible for tasks related to the role.
+
If the DC is broken (e. g. hardware defect) and will never come back again, then you can seize the role on a remaining DC. It is very important that the old DC will never be connected to the network again, if it is connected again, this will cause conflicts and lead to an inconsistent AD. This is because the old DC will not notice the change and still feel responsible for tasks related to the role.
  
  
Line 13: Line 13:
 
There are three situations to distinguish:
 
There are three situations to distinguish:
  
1. The downtime is planed and the DC comes back soon (reboot, hardware replacement, etc.):
+
1. The downtime is planned and the DC will come back soon (reboot, hardware replacement, etc.):
  
: In this case, you have to decited, if you temporary transfer the roles to a different DC or avouch that you know the effects during the downtime. See [[#The_seven_FSMO_roles|The seven FSMO roles]].
+
: In this case, you have to decide, to temporarily transfer the roles to a different DC or be aware of the effects during the downtime. See [[#The_seven_FSMO_roles|The seven FSMO roles]].
  
 
2. The DC should be demoted:
 
2. The DC should be demoted:
Line 21: Line 21:
 
: Transfer the roles to a different DC, before you demote.
 
: Transfer the roles to a different DC, before you demote.
  
3. The DC is offline caused by a problem:
+
3. The DC is offline because of a problem:
  
 
: 1. Don't panic!
 
: 1. Don't panic!
  
: 2. Depending on the kind of role(s) that was/were on the DC, the consequences may be different. Make sure, that you find out which roles are affected and what it means for your forest. See [[#The_seven_FSMO_roles|The seven FSMO roles]].
+
: 2. Depending on the kind of role(s) that were on the DC, the consequences may be different. Make sure that you find out which roles are affected and what it means for your forest. See [[#The_seven_FSMO_roles|The seven FSMO roles]].
  
 
: 3. Try repairing the broken DC and connect it to the network again. But never restore it from a backup, if at least one DC in the domain is still working. The replication could mix up your directory!
 
: 3. Try repairing the broken DC and connect it to the network again. But never restore it from a backup, if at least one DC in the domain is still working. The replication could mix up your directory!
Line 52: Line 52:
 
Before 4.3.0, to see all the fsmo roleowners, you will need to do something like this:
 
Before 4.3.0, to see all the fsmo roleowners, you will need to do something like this:
  
  ldbsearch --cross-ncs -H /var/lib/samba/private/sam.ldb '(fsmoroleowner=*)' | grep 'dn:' | sed 's|dn: ||'
+
  ldbsearch --cross-ncs -H /usr/local/samba/private/sam.ldb '(fsmoroleowner=*)' |\
 +
  grep 'dn:' | sed 's|dn: ||'
  
 
This should produce a list of where the role owners are stored:
 
This should produce a list of where the role owners are stored:
Line 88: Line 89:
  
  
== Transfering a FSMO role ==
+
== Transferring a FSMO role ==
  
 
* Log on to the DC, that should be the new owner of the role you want to transfer.
 
* Log on to the DC, that should be the new owner of the role you want to transfer.
Line 97: Line 98:
 
  FSMO transfer of '...' role successful
 
  FSMO transfer of '...' role successful
  
* Ensure that the role was transfered ('samba-tool fsmo show').
+
* Ensure that the role was transferred ('samba-tool fsmo show').
  
'''Note: samba-tool has a bug, that prevents a successful transfer of roles, even if „samba-tool fsmo show“ prints that the roles are transfered to the new host. See [https://bugzilla.samba.org/show_bug.cgi?id=10734 Bug #10734], to see if it is fixed in the version you're running.'''
+
'''Note: samba-tool has a bug, that prevents a successful transfer of roles, even if „samba-tool fsmo show“ prints that the roles are transferred to the new host. See [https://bugzilla.samba.org/show_bug.cgi?id=10734 Bug #10734], to see if it is fixed in the version you're running.'''
  
  
Line 107: Line 108:
 
* Log on to the DC, that should be the new owner of the role you want to transfer.
 
* Log on to the DC, that should be the new owner of the role you want to transfer.
  
* Seize the role to the current DC, by executing the folloging command:
+
* Seize the role to the current DC, by executing the following command:
  
 
  # samba-tool fsmo seize --role=...
 
  # samba-tool fsmo seize --role=...
Line 114: Line 115:
 
  FSMO seize of '...' role successful
 
  FSMO seize of '...' role successful
  
* Ensure that the role was transfered ('samba-tool fsmo show').
+
* Ensure that the role was transferred ('samba-tool fsmo show').
  
* Make sure, that the old DC will never be connected to the network again!
+
* Make sure, that the old DC is never connected to the network again!
  
 
'''Note: samba-tool has a bug, that prevents the seizure of the Domain Naming Master role. See [https://bugzilla.samba.org/show_bug.cgi?id=10924 Bug #10924]. If you encounter this problem in your version, consider adding the „--force“ parameter, to workaround this issue.'''
 
'''Note: samba-tool has a bug, that prevents the seizure of the Domain Naming Master role. See [https://bugzilla.samba.org/show_bug.cgi?id=10924 Bug #10924]. If you encounter this problem in your version, consider adding the „--force“ parameter, to workaround this issue.'''

Revision as of 11:37, 7 January 2016

Difference of transferring and seizing FSMO roles

Whenever it's possible, you should transfer FSMO roles and do not seize them! Transferring is the recommended and cleaner way. But it requires that the DC, which currently owns the role you want to transfer, is still working and connected to the network. Transferring makes the old DC know that it does not own the role(s) any more.

If the DC is broken (e. g. hardware defect) and will never come back again, then you can seize the role on a remaining DC. It is very important that the old DC will never be connected to the network again, if it is connected again, this will cause conflicts and lead to an inconsistent AD. This is because the old DC will not notice the change and still feel responsible for tasks related to the role.



How to handle situations where a DC with FSMO roles is offline

There are three situations to distinguish:

1. The downtime is planned and the DC will come back soon (reboot, hardware replacement, etc.):

In this case, you have to decide, to temporarily transfer the roles to a different DC or be aware of the effects during the downtime. See The seven FSMO roles.

2. The DC should be demoted:

Transfer the roles to a different DC, before you demote.

3. The DC is offline because of a problem:

1. Don't panic!
2. Depending on the kind of role(s) that were on the DC, the consequences may be different. Make sure that you find out which roles are affected and what it means for your forest. See The seven FSMO roles.
3. Try repairing the broken DC and connect it to the network again. But never restore it from a backup, if at least one DC in the domain is still working. The replication could mix up your directory!
4. If there is no chance to get the DC back again, seize the roles on a remaining DC and demote the broken one.



FSMO role management using samba-tool

Show current FSMO role owners

On a Domain Controller of your choice, run the following command, to print the owner of the different FSMO roles:

# samba-tool fsmo show
InfrastructureMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
RidAllocationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
DomainNamingMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com

Unfortunately before samba 4.3.0, samba-tool only shows five of the fsmo roles and that these five roles are owned by DC1 at the moment.

Before 4.3.0, to see all the fsmo roleowners, you will need to do something like this:

ldbsearch --cross-ncs -H /usr/local/samba/private/sam.ldb '(fsmoroleowner=*)' |\
 grep 'dn:' | sed 's|dn: ||'

This should produce a list of where the role owners are stored:

CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
CN=Partitions,CN=Configuration,DC=samdom,DC=example,DC=com
CN=Infrastructure,DC=DomainDnsZones,DC=samdom,DC=example,DC=com
CN=Infrastructure,DC=ForestDnsZones,DC=samdom,DC=example,DC=com
DC=samdom,DC=example,DC=com
CN=RID Manager$,CN=System,DC=samdom,DC=example,DC=com
CN=Infrastructure,DC=samdom,DC=example,DC=com

To find out the fsmo role owner for a specific dn, you will need to do something like this:

ldbsearch --cross-ncs -H /var/lib/samba/private/sam.ldb -b "CN=Infrastructure,DC=DomainDnsZones,DC=samdom,DC=example,DC=com" \
-s base fsmoroleowner

Which should produce something similar to this:

# record 1
dn: CN=Infrastructure,DC=DomainDnsZones,DC=samdom,DC=example,DC=com
fSMORoleOwner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com

From Samba 4.3.0, running the 'samba-tool fsmo show' command will now show all 7 FSMO roles:

# samba-tool fsmo show
InfrastructureMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
RidAllocationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
DomainNamingMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com


Transferring a FSMO role

  • Log on to the DC, that should be the new owner of the role you want to transfer.
  • Transfer the role to the DC, by executing the following command:
# samba-tool fsmo transfer --role=...
FSMO transfer of '...' role successful
  • Ensure that the role was transferred ('samba-tool fsmo show').

Note: samba-tool has a bug, that prevents a successful transfer of roles, even if „samba-tool fsmo show“ prints that the roles are transferred to the new host. See Bug #10734, to see if it is fixed in the version you're running.


Seizing a FSMO role

  • Log on to the DC, that should be the new owner of the role you want to transfer.
  • Seize the role to the current DC, by executing the following command:
# samba-tool fsmo seize --role=...
Attempting transfer...
Transfer unsuccessful, seizing...
FSMO seize of '...' role successful
  • Ensure that the role was transferred ('samba-tool fsmo show').
  • Make sure, that the old DC is never connected to the network again!

Note: samba-tool has a bug, that prevents the seizure of the Domain Naming Master role. See Bug #10924. If you encounter this problem in your version, consider adding the „--force“ parameter, to workaround this issue.



FSMO role management using the Windows GUI

See https://support.microsoft.com/en-us/kb/324801