[Samba] domain join failure - error during DRS repl ADD: No objectClass found

[Luke Bigum]

Hello,

I am trying to join a third domain controller to an existing Samba 4 domain (sernet samba 4.2.1-17.el6.x86_64) and we're hitting a problem that looks like some bad replication data on certain objects. We get part way through replicating the tree and then it dies on a Sudo Rule object:

[root at dc03 ~]# /usr/bin/samba-tool domain join EXAMPLE.COM DC -U Administrator --password=xxxxxxxxxxxx  --dns-backend=BIND9_DLZ
...
Failed to apply records: replmd_replicated_apply_add: error during DRS repl ADD: No objectClass found in replPropertyMetaData for CN=rule,OU=SUDOers,DC=example,DC=com!
: Object class violation
Failed to commit objects: WERR_GENERAL_FAILURE
Join failed - cleaning up
checking sAMAccountName
...
ERROR(<type 'exceptions.TypeError'>): uncaught exception - Failed to process chunk: NT_STATUS_UNSUCCESSFUL
  File "/usr/lib64/python2.6/site-packages/samba/netcmd/__init__.py", line 175, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/samba/netcmd/domain.py", line 613, in run
    machinepass=machinepass, use_ntvfs=use_ntvfs, dns_backend=dns_backend)
  File "/usr/lib64/python2.6/site-packages/samba/join.py", line 1183, in join_DC
    ctx.do_join()
  File "/usr/lib64/python2.6/site-packages/samba/join.py", line 1088, in do_join
    ctx.join_replicate()
  File "/usr/lib64/python2.6/site-packages/samba/join.py", line 828, in join_replicate
    replica_flags=ctx.domain_replica_flags)
  File "/usr/lib64/python2.6/site-packages/samba/drs_utils.py", line 256, in replicate
    schema=schema, req_level=req_level, req=req)



However, when I check the data that the domain join is complaining about on the two existing domain controllers, it appears to be present and ok, so I don't think we are talking about https://bugzilla.samba.org/show_bug.cgi?id=10398 (plus we are > 4.1 here):

[root at dc01 ~]# ldbsearch -H /var/lib/samba/private/sam.ldb -b "CN=rule,OU=SUDOers,DC=example,DC=com" -s base objectClass
...
# record 1
dn: CN=rule,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole



If I run a dbcheck I see a number of these for various objects:

Values/Order of values do/does not match: ...
ERROR: Normalisation error for attribute 'objectClass' in ...



But none of the out of objects affected are what blows up the domain join. If I look at the meta data in binary of the Sudo Rule it does mentions objectClass, however there is a lot of other UNKNOWN_ENUM_VALUE entries in that array for this entry. When I compare it to other standard AD objects in the LDAP tree, there are no unknown values.

[root at dc01 ~]# ldbsearch -H /var/lib/samba/private/sam.ldb -b "CN=rule,OU=SUDOers,DC=example,DC=com" -s base replPropertyMetaData --show-binary
...
# record 1
dn: CN=rule,OU=SUDOers,DC=example,DC=com
replPropertyMetaData:     NDR: struct replPropertyMetaDataBlob
        version                  : 0x00000001 (1)
        reserved                 : 0x00000000 (0)
        ctr                      : union replPropertyMetaDataCtr(case 1)
        ctr1: struct replPropertyMetaDataCtr1
            count                    : 0x0000000d (13)
            reserved                 : 0x00000000 (0)
            array: ARRAY(13)
                array: struct replPropertyMetaData1
                    attid                    : UNKNOWN_ENUM_VALUE (0x882CB1CF)
                    version                  : 0x00000007 (7)
                    originating_change_time  : Wed Jun  4 12:24:20 2014 UTC
                    originating_invocation_id: f712c17f-95ec-47db-b814-cb62f463bd7c
                    originating_usn          : 0x0000000000001b6d (7021)
                    local_usn                : 0x0000000000001b6e (7022)
                array: struct replPropertyMetaData1
                    attid                    : DRSUAPI_ATTID_objectClass (0x0)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed Feb 19 12:30:04 2014 UTC
                    originating_invocation_id: f712c17f-95ec-47db-b814-cb62f463bd7c
                    originating_usn          : 0x0000000000000f3a (3898)
                    local_usn                : 0x0000000000000f3a (3898)
...



Does anyone have any ideas about what is interfering with the domain join, or where to debug further?

Thanks,

--
Luke Bigum
Senior Systems Engineer

Information Systems
---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

#1 Fastest Growing Tech Company in the UK - Sunday Times Tech Track 100 (2014) 

2015 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2015 Best FX Trading Venue - ECN/MTF - WSL Institutional Trading Awards
2014 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2014 Best FX Trading Venue - ECN/MTF - WSL Institutional Trading Awards
2014 Best Infrastructure/Technology Initiative - WSL Institutional Trading Awards
2013 #15 Fastest Growing Tech Company in the UK - Sunday Times Tech Track 100
2013 Best Overall Testing Project - The European Software Testing Awards
2013 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2013 Best FX Trading Platform - ECN/MTF - WSL Institutional Trading Awards
2013 Best Executing Venue - Forex Magnates Awards

---

FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved.

This message and its attachments are confidential, may not be disclosed or used by any person other than the addressee and are intended only for the named recipient(s). This message is not intended for any recipient(s) who based on their nationality, place of business, domicile or for any other reason, is/are subject to local laws or regulations which prohibit the provision of such products and services. This message is subject to the following terms (http://lmax.com/pdf/general-disclaimers.pdf), if you cannot access these, please notify us by replying to this email and we will send you the terms. If you are not the intended recipient, please notify the sender immediately and delete any copies of this message.

LMAX Exchange is the trading name of LMAX Limited. LMAX Limited operates a multilateral trading facility. LMAX Limited is authorised and regulated by the Financial Conduct Authority (firm registration number 509778) and is a company registered in England and Wales (number 6505809).

LMAX Hong Kong Limited is a wholly-owned subsidiary of LMAX Limited. LMAX Hong Kong is licensed by the Securities and Futures Commission in Hong Kong to conduct Type 3 (leveraged foreign exchange trading) regulated activity with CE Number BDV088.