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

[mourik jan heupink - merit]

Hi Andrew, Roland, list,

So nice to see that this issue has not been forgotten. As I hadn't heard 
back from you Andrew, I thought it had slipped off the radar.

I'm cc-ing Roland Gruber here, the LAM author, as I think your findings 
are interesting for him as well.

Thanks!

Just for your info: We have are still using LAM (plus ADUC as well) and 
meanwhile we have developped 37 of these errors. However: our AD is 
running nicely.

MJ

On 05/30/2014 06:58 AM, 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
>