[Samba] Bad DSA objectGUID ed8970e5-84cc-43dd-89f1-4af8d6ab675a for sid S-1-5-21-570971082-1333357699-3675202899-1375
adam_xu at adagene.com.cn
adam_xu at adagene.com.cn
Fri Feb 9 06:57:30 UTC 2018
Andrew Bartlett, samba
Think you for your reply.
I know the process to resovle the problem now. first ,I need transferring and Seizing FSMO Roles to DC2 and then demoting DC1. After that ,I join the DC1 from DC2 with the fsmo role to the domain again. Right?
Is there any other method that I can edit the sam.ldb file directly and add the dsServiceName entry of the DC1?
yours Adam
From: Andrew Bartlett
Date: 2018-02-09 06:51
To: adam_xu at adagene.com.cn; samba
Subject: Re: [Samba] Bad DSA objectGUID ed8970e5-84cc-43dd-89f1-4af8d6ab675a for sid S-1-5-21-570971082-1333357699-3675202899-1375
On Fri, 2018-02-09 at 01:01 +0800, adam_xu--- via samba wrote:
> Hello，I'm using samba ad dc about a year. I have 2 DCs, One is DC1 with FSMO role. And another is DC2.
> there's a error in DC1 when i use dbcheck tool. And samba-tool dbcheck --cross-ncs--fix can't fix that. And I made a big mistake !
> In DC2 I use "tdbbackup -s .bak /var/lib/samba/private/sam.ldb" create a bak file. and using that bak file replace the sam.ldb file in DC1 without any backup.
> Now , I saw the errors in DC1：
>
> Feb 08 22:06:04 dc1.adagene.cn samba[32137]: UpdateRefs failed with WERR_DS_DRA_ACCESS_DENIED/NT code 0xc0002105 for ed8970e5-84cc-43dd-89f1-4af8d6ab675a._msdcs.adagene.cn DC=adagene,DC=cn
> Feb 08 22:06:04 dc1.adagene.cn samba[32129]: [2018/02/08 22:06:04.078274, 0] ../source4/dsdb/common/util.c:4825(dsdb_validate_dsa_guid)
> Feb 08 22:06:04 dc1.adagene.cn samba[32129]: ../source4/dsdb/common/util.c:4825: Bad DSA objectGUID ed8970e5-84cc-43dd-89f1-4af8d6ab675a for sid S-1-5-21-570971082-1333357699-3675202899-1375 - expected sid S-1-5-21-570971082-1333357699-3675202899-1689
> Feb 08 22:06:04 dc1.adagene.cn samba[32129]: [2018/02/08 22:06:04.078367, 0] ../source4/rpc_server/drsuapi/updaterefs.c:374(dcesrv_drsuapi_DsReplicaUpdateRefs)
> Feb 08 22:06:04 dc1.adagene.cn samba[32129]: ../source4/rpc_server/drsuapi/updaterefs.c:374: Refusing DsReplicaUpdateRefs for sid S-1-5-21-570971082-1333357699-3675202899-1375 with GUID ed8970e5-84cc-43dd-89f1-4af8d6ab675a
> Feb 08 22:06:04 dc1.adagene.cn samba[32137]: [2018/02/08 22:06:04.078521, 0] ../source4/dsdb/repl/drepl_out_helpers.c:1087(dreplsrv_update_refs_done)
> Feb 08 22:06:04 dc1.adagene.cn samba[32137]: UpdateRefs failed with WERR_DS_DRA_ACCESS_DENIED/NT code 0xc0002105 for ed8970e5-84cc-43dd-89f1-4af8d6ab675a._msdcs.adagene.cn CN=Configuration,DC=adagene,DC=cn
> Feb 08 22:07:00 dc1.adagene.cn samba[32129]: [2018/02/08 22:07:00.803258, 0] ../source4/rpc_server/drsuapi/writespn.c:238(dcesrv_drsuapi_DsWriteAccountSpn)
>
> the sid S-1-5-21-570971082-1333357699-3675202899-1375 should be DC1 and sid S-1-5-21-570971082-1333357699-3675202899-1689 should be DC2.
> The Directory Replication failed and when I ping dc1.adagene.cn or dc2.adagene.cn in the DC1 host, the same IP address of the DC1 is retruned.
>
> when I run the command below in DC1:
> # ldbsearch -H sam.ldb '(invocationId=*)' --cross-ncs objectguid
>
> it returns:
> # record 1
> dn: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=adagene,DC=cn
> objectGUID: 99804022-ab9e-4c0a-921b-f6f13b6da4c8
>
> # record 2
> dn: CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=adagene,DC=cn
> objectGUID: ed8970e5-84cc-43dd-89f1-4af8d6ab675a
>
> the result is the same in DC2.
>
> How can I fix these errors.
> Thank you.
Is there any reason you can't just rejoin DC1 from DC2? You may wish
to steal the FSMO roles across first.
The background is that along with metadata that is generally
consistent, the sam.ldb file contains this record:
dn: @ROOTDSE
configurationNamingContext:
CN=Configuration,DC=addom,DC=samba,DC=example,DC=c
om
defaultNamingContext: DC=addom,DC=samba,DC=example,DC=com
rootDomainNamingContext: DC=addom,DC=samba,DC=example,DC=com
schemaNamingContext:
CN=Schema,CN=Configuration,DC=addom,DC=samba,DC=example,D
C=com
subschemaSubentry:
CN=Aggregate,CN=Schema,CN=Configuration,DC=addom,DC=samba,D
C=example,DC=com
supportedCapabilities: 1.2.840.113556.1.4.800
supportedCapabilities: 1.2.840.113556.1.4.1670
supportedCapabilities: 1.2.840.113556.1.4.1791
supportedCapabilities: 1.2.840.113556.1.4.1935
supportedCapabilities: 1.2.840.113556.1.4.2080
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: Samba Team (https://www.samba.org)
isSynchronized: TRUE
dsServiceName: <GUID=3ea98d77-60b4-4405-b11d-26ccb1c798c4>
The last value dsServiceName contains the GUID of the DC's own record,
and the mixup is why things are not happy.
I hope this clarifies things,
Andrew Bartlett
--
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
https://catalyst.net.nz/services/samba
More information about the samba
mailing list