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

[Rowland Penny]

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 ?

Rowland