[PATCH] make samba-tool aware of all 7 fsmo roles
repenny241155 at gmail.com
Fri May 22 04:25:01 MDT 2015
On 22/05/15 11:13, Stefan (metze) Metzmacher wrote:
> Hi Rowland,
>> From what I have read, What seems to happen (simplistically), you run
>> 'samba-tool fsmo transfer schema' on the DC that you want to have the
>> schema fsmo role, this then causes the DC to set the attribute
>> 'becomeSchemaMaster' to '1' (not entirely sure where this is set), this
>> then causes the role owner to be changed on the DC that holds the role
>> at the moment, replication then kicks in and the new role owner is
>> replicated to any other DCs.
>> Is the above correct ?
> Yes, on the high level.
> In detail this happens:
> - becomeSchemaMaster: 1 triggers
> rootdse_become_master() in source4/dsdb/samdb/ldb_modules/rootdse.c
> - rootdse_become_master() sends a dcerpc_drepl_takeFSMORole message
> to our dreplsrv task
> - The dreplsrv task handles the incoming replication using
> against other (source dsa) domain controllers.
> drsuapi_DsGetNCChanges() asks for
> changed objects.
> - In the dcerpc_drepl_takeFSMORole case it triggers a
> request with a special drsuapi_DsExtendedOperation (see
> against the current role owner.
> - The current role owner executes the extended operation before
> collection the
> changed objects the destination dsa (the new role owner is this cases)
> for. See source4/rpc_server/drsuapi/getncchanges.c where
> calls getncchanges_change_master(). That way the owner change is a
> more or less atomic operation.
> - When the new owner receives the drsuapi_DsGetNCChanges() response and
> the changes to its database the role transfer is finished.
>> If so, would something like this work:
>> Create something that simulates 'becomeDomainDnsZoneMaster', this would
>> have to get the original role owner, connect to that DC and change the
>> role owner there, then kickstart the replication with sendDsReplicaSync
> What we need to do is the following:
> - first check if we have for the role_object in our local database,
> role_object="CN=Infrastructure,DC=DomainDnsZones," + domain_dn
> role_object="CN=Infrastructure,DC=ForestDnsZones," + forest_dn (not
> not domain_dn here!).
> You have that mostly complete, but please only catch LdbError expections
> not all.
> Instead of just getting the DN value as string, you should
> use controls=["extended_dn:1:1"], see get_naming_master() in
> That way we can construct a dns name for the current owner by using:
> master_guid = str(misc.GUID(ldb.Dn(ctx.samdb,
> master_dns_name = '%s._msdcs.%s' % (master_guid, samdb.forest_dns_name())
> - We should check if we are already the current owner and give an error.
> Instead of using fro = "CN=NTDS
> Settings,CN=%s,CN=Servers,CN=%s,CN=Sites,CN=Configuration,%s" %
> (newowner, site_name, domain_dn)
> I guess it's easier to use the "dsServiceName" attribute.
> You can use samdb.get_dsServiceName() to get it
> - We need to create a master_samdb using SamDB(url="ldap://%s" %
> (master_dns_name), ...)
> - We need to update the role onwer using master_samdb connection
> Please use FLAG_MOD_DEL with the old value and FLAG_MOD_ADD with the
> new value instead of FLAG_MOD_REPLACE, that way the change would be
> be atomic and fail if the value already changed in between.
> - Then you call drs_utils.drsuapi_connect() against the
> - Then we finally need to call
> drs_utils.sendDsReplicaSync(drsuapi_connection, drsuapi_handle,
> master_guid, NC, req_options)
> I'm not quire sure regarding the values for NC and req_options.
> We need to experiment with them.
> First I'd try NC=role_object and req_options=drsuapi.DRSUAPI_DRS_WRIT_REP
> I hope that helps:-)
> I think it would be good if you would prepare a patch without this,
> so that we can bring the important working parts of your patch upstream.
> Then you can do the 2nd part on top of it.
> BTW: do you mind if we continue the discussion on samba-technical?
> This information seems to be useful others too.
No problem with discussing this here on samba-technical
I will prepare a patch without the transfer part, but I would like to
point out that I have now found this:
Which seems to say that the two dns zones in question are not critical.
I have also found this:
The script it provides seems to work in the same way that I proposed.
I have now found
More information about the samba-technical