[Samba] Bad DSA objectGUID ed8970e5-84cc-43dd-89f1-4af8d6ab675a for sid S-1-5-21-570971082-1333357699-3675202899-1375

Andrew Bartlett abartlet at samba.org
Thu Feb 8 22:51:40 UTC 2018


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