[PATCH] make samba-tool aware of all 7 fsmo roles

[Rowland Penny]

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
> drsuapi_DsGetNCChanges()
>    against other (source dsa) domain controllers.
> drsuapi_DsGetNCChanges() asks for
>    changed objects.
>
> - In the dcerpc_drepl_takeFSMORole case it triggers a
> drsuapi_DsGetNCChanges()
>    request with a special drsuapi_DsExtendedOperation (see
> drepl_take_FSMO_role())
>    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)
> asked
>    for. See source4/rpc_server/drsuapi/getncchanges.c where
> dcesrv_drsuapi_DsGetNCChanges()
>    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
> applies
>    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,
>    with
>    role_object="CN=Infrastructure,DC=DomainDnsZones," + domain_dn
>    or
>    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
>    python/samba/join.py
>
>    That way we can construct a dns name for the current owner by using:
>    master_guid = str(misc.GUID(ldb.Dn(ctx.samdb,
> res[0]['fSMORoleOwner'][0]).get_extended_component('GUID')))
>    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
> samdb.host_dns_name()
>
> - 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.
>
> Thanks!
> metze
>

Hi Stefan,

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:

http://blogs.msmvps.com/ulfbsimonweidner/2008/07/31/how-many-infrastructure-masters-do-you-have/

Which seems to say that the two dns zones in question are not critical.

I have also found this:

https://support.microsoft.com/en-us/kb/949257

The script it provides seems to work in the same way that I proposed.

Rowland
I have now found