samba - Jul 2019 - `samba-tool dbcheck --cross-ncs --fix` fails: governsID already exists as an attributeId or governsId

On 03.07.19 18:04, Rowland penny via samba wrote:
>>>> How do I get rid of these bogus Schema entries, and how do I
fix the
>>>> user account?
>>> I do not think you can remove anything from the schema, but I
believe
>>> you can deactivate schema objects, try reading this:
>>>
>>>
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc773309(v=ws.10)
>>>
>> They already are disabled.
> 
> Have you extended the schema to use 'taouser' ?
Yes.
> I ask this because (from what you posted) it uses the same X500 OID as
> 'ucsUser', another name for X500 OID is 'governsID', so
this may be your
> problem, try deleting 'taouser' from your AD object (this is
allowed)
> and see if your problem goes away.
That fixed the dbcheck crashes on the other three servers, they now
complete successfully.

Still left are the three governsId collisions, which are now identical
across all DCs:
> Checking 3861 objects
> Error: governsID CN=ucsUser,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at
on 1.3.6.1.4.1.19414.3.2.2 already exists as an attributeId or governsId
> Error: governsID
CN=taoSharedFolder,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on
1.3.6.1.4.1.19414.3.2.4 already exists as an attributeId or governsId
> Error: governsID
CN=taoMailingList,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on
1.3.6.1.4.1.19414.3.2.3 already exists as an attributeId or governsId
> Checked 3861 objects (3 errors)
How do I fix those? Can I just edit the old, defunct classes and change
their governsId without breaking something?


-- 
Mit freundlichen Gr??en, / Best Regards,
Sven Schwedas, Systemadministrator
? sven.schwedas at tao.at | ? +43 680 301 7167
TAO Digital   | Teil der TAO Beratungs- & Management GmbH
Lendplatz 45  | FN 213999f/Klagenfurt, FB-Gericht Villach
A8020 Graz    | https://www.tao-digital.at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20190704/f923ef7f/signature.sig>

On 04/07/2019 14:45, Sven Schwedas via samba wrote:
> On 03.07.19 18:04, Rowland penny via samba wrote:
>>>>> How do I get rid of these bogus Schema entries, and how do
I fix the
>>>>> user account?
>>>> I do not think you can remove anything from the schema, but I
believe
>>>> you can deactivate schema objects, try reading this:
>>>>
>>>>
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc773309(v=ws.10)
>>>>
>>> They already are disabled.
>> Have you extended the schema to use 'taouser' ?
> Yes.
>
>> I ask this because (from what you posted) it uses the same X500 OID as
>> 'ucsUser', another name for X500 OID is 'governsID', so
this may be your
>> problem, try deleting 'taouser' from your AD object (this is
allowed)
>> and see if your problem goes away.
> That fixed the dbcheck crashes on the other three servers, they now
> complete successfully.
>
> Still left are the three governsId collisions, which are now identical
> across all DCs:
>
>> Checking 3861 objects
>> Error: governsID
CN=ucsUser,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on
1.3.6.1.4.1.19414.3.2.2 already exists as an attributeId or governsId
>> Error: governsID
CN=taoSharedFolder,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on
1.3.6.1.4.1.19414.3.2.4 already exists as an attributeId or governsId
>> Error: governsID
CN=taoMailingList,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on
1.3.6.1.4.1.19414.3.2.3 already exists as an attributeId or governsId
>> Checked 3861 objects (3 errors)
> How do I fix those? Can I just edit the old, defunct classes and change
> their governsId without breaking something?
I do not know, mainly because I have never tried to do something like 
this on a production server.

Rowland

On 04.07.19 15:54, Rowland penny via samba wrote:>> Still left are the
three governsId collisions, which are now identical
>> across all DCs:
>>
>>> Checking 3861 objects
>>> Error: governsID
>>> CN=ucsUser,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on
>>> 1.3.6.1.4.1.19414.3.2.2 already exists as an attributeId or
governsId
>>> Error: governsID
>>> CN=taoSharedFolder,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on
>>> 1.3.6.1.4.1.19414.3.2.4 already exists as an attributeId or
governsId
>>> Error: governsID
>>> CN=taoMailingList,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on
>>> 1.3.6.1.4.1.19414.3.2.3 already exists as an attributeId or
governsId
>>> Checked 3861 objects (3 errors)
>> How do I fix those? Can I just edit the old, defunct classes and change
>> their governsId without breaking something?
> 
> I do not know, mainly because I have never tried to do something like
> this on a production server.
Unsurprisingly, remote ldbedit fails with
LDAP_INSUFFICIENT_ACCESS_RIGHTS when trying to modify an object's
governsId.

Is it safe to just leave the defunct objects as they are, or should I
attempt to directly modify the ldb files on the FSMO role holder?

-- 
Mit freundlichen Gr??en, / Best Regards,
Sven Schwedas, Systemadministrator
? sven.schwedas at tao.at | ? +43 680 301 7167
TAO Digital   | Teil der TAO Beratungs- & Management GmbH
Lendplatz 45  | FN 213999f/Klagenfurt, FB-Gericht Villach
A8020 Graz    | https://www.tao-digital.at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20190704/6aad7fa7/signature.sig>