Bug 11842 - Replication and creation failing with extended schema where custom attribute is also RDN
Replication and creation failing with extended schema where custom attribute ...
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.4.0
All All
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-15 14:49 UTC by Jonathan Hunter
Modified: 2016-07-30 01:43 UTC (History)
3 users (show)

See Also:


Attachments
patch for git master to remove incorrect check (1.34 KB, patch)
2016-05-15 09:33 UTC, Andrew Bartlett
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Hunter 2016-04-15 14:49:20 UTC
(This has been initially discussed on the samba@lists.samba.org mailing list - subject 'Previously extended schema not working in 4.4.0'. For me it is a blocker in my live environment, although I appreciate not many other people may currently be affected by this)

Summary from Andrew:

"Because the custom schema attribute myobj was also the RDN, it hit a
case we haven't tested yet. We probably need to fix further our test scripts."

Bug details:

I have extended my schema by defining some custom attributes and classes. I have created a number of objects where the RDN is also the custom object, e.g.

myattr=myvalue,ou=somegroup,dc=mydomain,dc=org,dc=uk

These objects were created over a period of time, from 2013 until a few weeks ago, using each Samba version I was running at the time (4.1.x, 4.2.x, 4.3.x), with no user-visible problems.

I recently updated to 4.4.0, at which point I was no longer able to create more of these objects (either using ADSIEdit, or Apache Directory Studio) - I received errors such as this, from all of my DCs:

Error while creating entry
 - [LDAP: error code 19 - 0000202F: replmd_add: error during direct ADD: No rDN found in replPropertyMetaData for mytype=abc123,OU=myou,DC=mydomain,DC=org,DC=uk


All four of my DCs are in a consistent state, according to ldapcmp:
# samba-tool ldapcmp ldap://dc1 ldap://dc2 schema --filter=whenChanged,usnChanged,usnCreated ; samba-tool ldapcmp ldap://dc1 ldap://dc2 domain --filter=whenChanged,usnChanged,usnCreated ; samba-tool ldapcmp ldap://dc1 ldap://dc2 configuration --filter=whenChanged,usnChanged,usnCreated
* Comparing [SCHEMA] context...
* Objects to be compared: 1557
* Result for [SCHEMA]: SUCCESS
* Comparing [DOMAIN] context...
* Objects to be compared: 613
* Result for [DOMAIN]: SUCCESS
* Comparing [CONFIGURATION] context...
* Objects to be compared: 1654
* Result for [CONFIGURATION]: SUCCESS

I did try to run 'samba-tool dbcheck --cross-ncs --fix'; but whilst the number of errors has gone down from 110 as a result, there are still 69 errors remaining, of types such as

ERROR: duplicate attributeID values for myattrib in replPropertyMetaData on MYOBJ=object1,OU=myou,DC=mydomain,DC=org,DC=uk

Fix replPropertyMetaData on MYOBJ=object1,OU=myou,DC=mydomain,DC=org,DC=uk by removing the duplicate value 0x00290003 for myattrib (keeping 0xbd27f44d5)? [YES]
[...]
ERROR: incorrect attributeID values in replPropertyMetaData on MYOBJ=object1,OU=myou,DC=mydomain,DC=org,DC=uk

Fix replPropertyMetaData on MYOBJ=object1,OU=myou,DC=mydomain,DC=org,DC=uk by replacing incorrect value 0x00290001 for et (new 0x00290001)? [YES]
No rDN found in replPropertyMetaData for MYOBJ=object1,OU=myou,DC=mydomain,DC=org,DC=uk!

Failed to fix attribute replPropertyMetaData : (19, 'replmd_update_rpmd: No rDN found in replPropertyMetaData for MYOBJ=object1,OU=myou,DC=mydomain,DC=org,DC=uk [YES]



I've been asked if I can provide the content of the replPropertyMetaData attribute; I haven't been able to actually extract it yet (sorry - I'm not so familiar with the tools) but will share once I can get hold of it..
Comment 1 Jonathan Hunter 2016-04-27 00:41:35 UTC
I have now fetched the replPropertyMetaData for one of these objects; hopefully I have done it correctly.

The only things redacted below are the object name/path, and the originating_invocation_id, which has the same value on all the entries I've (randomly) fetched so far.

I noticed that some of these return ARRAY(8), some return ARRAY(13), but all seem to contain UNKNOWN_ENUM_VALUE amongst other things - e.g. "UNKNOWN_ENUM_VALUE (0xBD27F4D8)"

If there's anything else I can check, please do let me know!



# ldbsearch -s sub -H /usr/local/samba/private/sam.ldb -b "myobj=myname,OU=myou,DC=mydomain,DC=org,DC=uk" --reveal --relax replPropertyMetaData --show-binary                     
# record 1
dn: myobj=myname,OU=myou,DC=mydomain,DC=org,DC=uk
replPropertyMetaData:     NDR: struct replPropertyMetaDataBlob
        version                  : 0x00000001 (1)
        reserved                 : 0x00000000 (0)
        ctr                      : union replPropertyMetaDataCtr(case 1)
        ctr1: struct replPropertyMetaDataCtr1
            count                    : 0x00000008 (8)
            reserved                 : 0x00000000 (0)
            array: ARRAY(8)
                array: struct replPropertyMetaData1
                    attid                    : DRSUAPI_ATTID_objectClass (0x0)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed May 20 17:05:02 2015 BST
                    originating_invocation_id: ********-****-****-****-************
                    originating_usn          : 0x0000000000003110 (12560)
                    local_usn                : 0x0000000000003110 (12560)
                array: struct replPropertyMetaData1
                    attid                    : DRSUAPI_ATTID_instanceType (0x20001)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed May 20 17:05:02 2015 BST
                    originating_invocation_id: ********-****-****-****-************
                    originating_usn          : 0x0000000000003110 (12560)
                    local_usn                : 0x0000000000003110 (12560)
                array: struct replPropertyMetaData1   
                    attid                    : DRSUAPI_ATTID_whenCreated (0x20002)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed May 20 17:05:02 2015 BST
                    originating_invocation_id: ********-****-****-****-************
                    originating_usn          : 0x0000000000003110 (12560)
                    local_usn                : 0x0000000000003110 (12560)
                array: struct replPropertyMetaData1   
                    attid                    : DRSUAPI_ATTID_ntSecurityDescriptor (0x20119)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed May 20 17:05:02 2015 BST
                    originating_invocation_id: ********-****-****-****-************
                    originating_usn          : 0x0000000000003110 (12560)
                    local_usn                : 0x0000000000003110 (12560)
                array: struct replPropertyMetaData1   
                    attid                    : DRSUAPI_ATTID_name (0x90001)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed May 20 17:05:02 2015 BST
                    originating_invocation_id: ********-****-****-****-************
                    originating_usn          : 0x0000000000003110 (12560)
                    local_usn                : 0x0000000000003110 (12560)
                array: struct replPropertyMetaData1   
                    attid                    : DRSUAPI_ATTID_objectCategory (0x9030E)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed May 20 17:05:02 2015 BST
                    originating_invocation_id: ********-****-****-****-************
                    originating_usn          : 0x0000000000003110 (12560)
                    local_usn                : 0x0000000000003110 (12560)
                array: struct replPropertyMetaData1   
                    attid                    : UNKNOWN_ENUM_VALUE (0x29000A)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed May 20 17:05:02 2015 BST
                    originating_invocation_id: ********-****-****-****-************
                    originating_usn          : 0x0000000000003110 (12560)
                    local_usn                : 0x0000000000003110 (12560)
                array: struct replPropertyMetaData1   
                    attid                    : UNKNOWN_ENUM_VALUE (0x290001)
                    version                  : 0x00000001 (1)
                    originating_change_time  : Wed May 20 17:05:02 2015 BST
                    originating_invocation_id: ********-****-****-****-************
                    originating_usn          : 0x0000000000003110 (12560)
                    local_usn                : 0x0000000000003110 (12560)


# returned 1 records
# 1 entries
# 0 referrals
Comment 2 Andrew Bartlett 2016-05-14 10:08:42 UTC
It turns out our RDN handling in replPropertyMetaData is quite unlike Windows, so I've been adding tests.  No promises, but if I can catch your case while cleaning the rest up here, I will.

Otherwise this may take a while (sorry), as it is a truly complex area of code, even before we add the complexity of schema extensions.
Comment 3 Andrew Bartlett 2016-05-15 09:33:29 UTC
Created attachment 12102 [details]
patch for git master to remove incorrect check

Thinking over this again, this patch should resolve the issue. 

Let me know if it resolves your issue, as I would like to get it into git master soon, as it is required for other work I'm already doing.
Comment 4 Jonathan Hunter 2016-05-15 14:14:43 UTC
Many thanks Andrew for this patch, it seems to resolve this issue.

I can confirm I have now tested as follows:

(No patch applied)
- Attempt to create object with custom attribute as RDN
  - Receive 'No rDN found in replPropertyMetaData' error message

(Patch applied)
- Attempt to create same object as above
  - Object created successfully
- Attempt to edit an existing object of same type
  - Edit succeeds (I am sure this failed previously; however I forgot to test this specific case again before patching)

Works here - thank you.


(FWIW, I also noticed that the trailing "\n" of this error message leaks through to the ADSIEdit screen and shows as a single black <?> character. Not a major issue and I don't know what the MS behaviour is here, however this initially did throw me off when trying to work out what was wrong, as I wondered if a string was being corrupted somewhere within samba. Turns out that it is simply the trailing '\n' and nothing is being corrupted!)
Comment 5 Andrew Bartlett 2016-07-30 01:43:38 UTC
Fixed in patches up to 374a01119dac8d1b04f8d43caf6e119be654e2dc in Samba 4.5.0rc1