Joining SBS2008 Domain fails with samba4

[Stephan Wolf]

On 29.12.2010 23:33, Andrew Bartlett wrote:
> On Wed, 2010-12-29 at 19:54 +0100, Stephan Wolf wrote:
>> Am 29.12.2010 13:57, schrieb Stephan Wolf:
>>> Am 29.12.2010 02:04, schrieb Kamen Mazdrashki:
>>>> Hi Stephan,
>>>>
>>>> I completely forgot about this during Christmas, sorry.
>>>>
>>>> Attached is a patch intended to solve the problem.
>>>> It applies on current master (4622812a) and compiles.
>>>> I haven't tested it with current master though.
>>>>
>>> Hi Kamen,
>>>
>>> I applied your patch to the master branch of samba.git and start of
>>> joining of the domain looks good but at the end on comming the
>>> replication I got an issue regarding transaction mismatch. The output
>>> looks like this...
>>>
>>> Committing SAM database
>>> partition end transaction mismatch
>>> ltdb:
>>> tdb(/usr/var/lib/samba/private/sam.ldb.d/CN=SCHEMA,CN=CONFIGURATION,DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_commit: no transaction
>>>
>>> ltdb:
>>> tdb(/usr/var/lib/samba/private/sam.ldb.d/CN=CONFIGURATION,DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_commit: no transaction
>>>
>>> ltdb:
>>> tdb(/usr/var/lib/samba/private/sam.ldb.d/DC=DOMAINDNSZONES,DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_commit: no transaction
>>>
>>> ltdb:
>>> tdb(/usr/var/lib/samba/private/sam.ldb.d/DC=FORESTDNSZONES,DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_commit: no transaction
>>>
>>> ltdb: tdb(/usr/var/lib/samba/private/sam.ldb.d/DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_commit: no transaction
>>>
>>> ltdb: tdb(/usr/var/lib/samba/private/sam.ldb): tdb_transaction_commit:
>>> no transaction
>>>
>>> ltdb:
>>> tdb(/usr/var/lib/samba/private/sam.ldb.d/CN=SCHEMA,CN=CONFIGURATION,DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_cancel: no transaction
>>>
>>> ltdb:
>>> tdb(/usr/var/lib/samba/private/sam.ldb.d/CN=CONFIGURATION,DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_cancel: no transaction
>>>
>>> ltdb:
>>> tdb(/usr/var/lib/samba/private/sam.ldb.d/DC=DOMAINDNSZONES,DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_cancel: no transaction
>>>
>>> ltdb:
>>> tdb(/usr/var/lib/samba/private/sam.ldb.d/DC=FORESTDNSZONES,DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_cancel: no transaction
>>>
>>> ltdb: tdb(/usr/var/lib/samba/private/sam.ldb.d/DC=G75,DC=LOCAL.ldb):
>>> tdb_transaction_cancel: no transaction
>>>
>>> partition del transaction mismatch
>>> Join failed - cleaning up
>>> checking samaccountname
>>> Deleted CN=PSW03,OU=Domain Controllers,DC=g75,DC=local
>>> Deleted CN=NTDS
>>> Settings,CN=PSW03,CN=Servers,CN=PSW,CN=Sites,CN=Configuration,DC=g75,DC=local
>>> Deleted
>>> CN=PSW03,CN=Servers,CN=PSW,CN=Sites,CN=Configuration,DC=g75,DC=local
>>> ERROR(ldb): uncaught exception - operations error at
>>> ../dsdb/samdb/ldb_modules/partition.c:847
>>>    File "bin/python/samba/netcmd/__init__.py", line 134, in _run
>>>      return self.run(*args, **kwargs)
>>>    File "bin/python/samba/netcmd/join.py", line 64, in run
>>>      site=site, netbios_name=netbios_name)
>>>    File "bin/python/samba/join.py", line 583, in join_DC
>>>      ctx.do_join()
>>>    File "bin/python/samba/join.py", line 517, in do_join
>>>      ctx.join_replicate()
>>>    File "bin/python/samba/join.py", line 488, in join_replicate
>>>      ctx.local_samdb.transaction_commit()
>>>
>>> The test was using the samba-tool join command not the vampire. using
>>> the vampire results in an issue with an exchange attribute and a
>>> "transaction still active" error
>>>
>>> mark ROOTDSE with isSynchronized=TRUE
>>> Failed to prepare_commit vampire transaction: Failed to add backlink
>>> from CN=Windows SBS Company Web Connector
>>> PSW01,CN=Connections,CN=Exchange Routing Group
>>> (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group
>>> (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=G75,CN=Microsoft
>>> Exchange,CN=Services,CN=Configuration,DC=g75,DC=local to
>>> CN=1,CN=SMTP,CN=Protocols,CN=PSW01,CN=Servers,CN=Exchange
>>> Administrative Group (FYDIBOHF23SPDLT),CN=Administrative
>>> Groups,CN=G75,CN=Microsoft
>>> Exchange,CN=Services,CN=Configuration,DC=g75,DC=local - SINGLE-VALUE
>>> attribute msExchBridgeheadedLocalConnectorsDNBL on
>>> CN=1,CN=SMTP,CN=Protocols,CN=PSW01,CN=Servers,CN=Exchange
>>> Administrative Group (FYDIBOHF23SPDLT),CN=Administrative
>>> Groups,CN=G75,CN=Microsoft
>>> Exchange,CN=Services,CN=Configuration,DC=g75,DC=local specified more
>>> than once
>>> A transaction is still active in ldb context [0x905c370] on
>>> /usr/var/lib/samba/private/sam.ldb
>>> ERROR(runtime): uncaught exception - NT_STATUS_INTERNAL_DB_ERROR
>>>    File "bin/python/samba/netcmd/__init__.py", line 134, in _run
>>>      return self.run(*args, **kwargs)
>>>    File "bin/python/samba/netcmd/vampire.py", line 55, in run
>>>      (domain_name, domain_sid) = net.vampire(domain=domain,
>>> target_dir=target_dir)
>>>
>>>
>>> Do you have any idea what's going wrong here?
>>>
>>> Thx a lot,
>>> Stephan
>> Hi All,
>>
>> I found the issue in the AD itself. There have been two attributes
>> marked as isSingleValued = TRUE but the values of these attributes habe
>> been filled with two items. Maybe there was a issue during the migration
>> from SBS 2003 to SBS 2008 including the migration of Exchange 2003 to
>> Exchange 2007 one year ago. I dont know realy waht was the problem -
>> one year is a long time. This two attributes are Exchange related.
>>
>> At the end samba4 is a DC in a SBS 2008 domain now.
>>
>> Thanks a lot for your support. Should I send the working patch to this
>> list or is there already activity to bring the patch to the samba-master
>> git?
> Are you able to tell us what record the problem was on, and the
> values/attributes etc?  Clearly we need to avoid doing the single-value
> check on DRS replication, or determine what AD does (it may discard a
> value for example).
>
> Andrew Bartlett
>
Hi Andrew

Sorry for the delay.
The attribute name is msExchBridgeheadedLocalConnectorsDNBL. The value 
of the attribute is linked to the outbound connector entry of MS 
exchange. I think it was a problem in the exchange mgmt console because 
the connector was not viewable (it was deleted by me 1 year ago) in the 
MMC anymore. I forgot to check the AD record itself so I can not tell 
you more about that.

But what I noticed on using the join and vampire command is the 
differences in the error messages. The results of the join command are 
completely unusable to fix the AD problem. Reading the vampire message 
is more helpful... Just a hint.

Thanks a lot,
Stephan