[Samba] one day AD use -> samba-tool dbcheck reports "Normalisation error for attribute 'objectClass'"

[Rowland Penny]

On 02/06/14 08:23, Andrew Bartlett wrote:
> On Fri, 2014-05-30 at 11:42 +0100, Rowland Penny wrote:
>> On 30/05/14 11:37, Andrew Bartlett wrote:
>>> On Fri, 2014-05-30 at 10:50 +0100, Rowland Penny wrote:
>>>> On 30/05/14 05:58, Andrew Bartlett wrote:
>>>>> On Sat, 2014-03-29 at 17:09 +0100, mourik jan heupink - merit wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Our migration is coming along nicely, everything seems to work like it
>>>>>> should... I thought...  Only samba-tool dbcheck reports five errors:
>>>>>>
>>>>>> root at dc1:~# samba-tool dbcheck
>>>>>> Checking 1143 objects
>>>>>> ERROR: Normalisation error for attribute 'objectClass' in
>>>>>> 'CN=phdseminar,CN=Users,DC=my,DC=samba,DC=domain'
>>>>>> Values/Order of values do/does not match: ['top', 'securityPrincipal',
>>>>>> 'posixAccount', 'person', 'organizationalPerson', 'user']/['top',
>>>>>> 'posixAccount', 'securityPrincipal', 'person', 'organizationalPerson',
>>>>>> 'user']!
>>>>>> Not fixing attribute 'objectClass'
>>>>>> ERROR: Normalisation error for attribute 'objectClass' in
>>>>>> 'CN=postmaster,CN=Users,DC=my,DC=samba,DC=domain'
>>>>>> Values/Order of values do/does not match: ['top', 'securityPrincipal',
>>>>>> 'posixAccount', 'person', 'organizationalPerson', 'user']/['top',
>>>>>> 'posixAccount', 'securityPrincipal', 'person', 'organizationalPerson',
>>>>>> 'user']!
>>>>>> Not fixing attribute 'objectClass'
>>>>>> ERROR: Normalisation error for attribute 'objectClass' in
>>>>>> 'CN=opac,CN=Users,DC=my,DC=samba,DC=domain'
>>>>>> Values/Order of values do/does not match: ['top', 'securityPrincipal',
>>>>>> 'posixAccount', 'person', 'organizationalPerson', 'user']/['top',
>>>>>> 'posixAccount', 'securityPrincipal', 'person', 'organizationalPerson',
>>>>>> 'user']!
>>>>>> Not fixing attribute 'objectClass'
>>>>>> ERROR: Normalisation error for attribute 'objectClass' in
>>>>>> 'CN=seminar,CN=Users,DC=my,DC=samba,DC=domain'
>>>>>> Values/Order of values do/does not match: ['top', 'securityPrincipal',
>>>>>> 'posixAccount', 'person', 'organizationalPerson', 'user']/['top',
>>>>>> 'posixAccount', 'securityPrincipal', 'person', 'organizationalPerson',
>>>>>> 'user']!
>>>>>> Not fixing attribute 'objectClass'
>>>>>> ERROR: Normalisation error for attribute 'objectClass' in
>>>>>> 'CN=heupink,CN=Users,DC=my,DC=samba,DC=domain'
>>>>>> Values/Order of values do/does not match: ['top', 'securityPrincipal',
>>>>>> 'posixAccount', 'person', 'organizationalPerson', 'user']/['top',
>>>>>> 'posixAccount', 'securityPrincipal', 'person', 'organizationalPerson',
>>>>>> 'user']!
>>>>>> Not fixing attribute 'objectClass'
>>>>>> Please use --fix to fix these errors
>>>>>> Checked 1143 objects (5 errors)
>>>>>> root at dc1:~#
>>>>>>
>>>>>> Are these errors something to worry about? This morning, right after the
>>>>>> classicupgrade, I also ran the dbcheck, and it reported 1 error, and
>>>>>> adding --fix did NOT cure anything.
>>>>>>
>>>>>> So, is my AD database corrupt, after it's first day of being alive??
>>>>>>
>>>>>> Errors are on both DC's, both are running btrfs, virtual machines, on
>>>>>> hardware raid, no errors in syslog etc.
>>>>> So, I've looked into this a little, and offline you mentioned you use
>>>>> LAM, which is adding securityPrincipal.  securityPrincipal is not
>>>>> require for samAccountName, but of course LAM is perfectly valid to
>>>>> specify it.  The issue is that posixAccount and securityPrincipal appear
>>>>> to be equal in weight, and so sort order is not deterministic.
>>>>>
>>>>> This appears to match MS-ADTS 3.1.1.2.4.6
>>>>> Auxiliary Class
>>>>> 1. Class top remains as the first value;
>>>>> 2. Then it is followed by the set of dynamic auxiliary classes and the
>>>>> classes in their superclass
>>>>> chains, excluding those already present in the superclass chain of the
>>>>> most specific structural
>>>>> class. There is no specific order among the classes in this set, and no
>>>>> class is listed more than
>>>>> once.
>>>>>
>>>>> So, what this leaves is that we need to make this deterministic, so our
>>>>> tests and dbcheck do not fail spuriously.
>>>>>
>>>>> I'll look into that.
>>>>>
>>>>> Andrew Bartlett
>>>> Hi Andrew, do you think that this could be fixed by not adding the
>>>> posixAccount objectClass when doing the classicupgrade ? After all the
>>>> objectClass in question is not actually needed and wouldn't be added by
>>>> windows.
>>> It was added by LAM.
>>>
>>> Andrew Bartlett
>>>
>> Are you sure ? the OP said this:
>>
>>    'This morning, right after the classicupgrade,'
>>
>> Anyway, I will alter my question slightly, do you think that this could
>> be fixed by not adding the posixAccount objectClass ?
> In any case it is irrelevant.  If this is a legitimate set of
> objectclasses (it is) then we need a canonical way to represent it, so
> we don't fall foul of our own database checker.  It doesn't matter what
> tool or combination of tools creates the issue.
>
> Andrew Bartlett
>
Hi Andrew, could you please explain your reasoning a bit better, why is 
it irrelevant ? surely if the auxiliary objectClass posixAccount wasn't 
there, the problem would go away, not trying to start a massive 
discussion here, just trying to understand the problem better ;-)

Rowland