Resolve Domain Controller Trust Relationship Failure After Time Change

draft · accounts-and-access domain-controller

Generated by docuprocessor (prompt article/v3) · 2026-04-22 13:09

Source thread

thread_id: spaces/AAAA05BdS6s/threads/636fq4bviIg · 35 msgs · first 2024-06-10 · participants: Tech ATech BTech CTech D

Tech A 2024-06-10 15:33

@all Bright Smile wanted to enter some info and backdate it. THis requires server time to be changed. I told them it might cause issue. They insisted me doing that. Now I am facing an issue when the workstations cannot authenticate with the server using the hostname but work with the IP. The only othe rmachine that authenticate with the server by the hostname is the TS server which is also secondary DC. I've tried restarting the DNS services, pointing to both DCs, adding the entry into the hosts file, rejoining the domain but its not working still. I am out of ideas. Need help.

Tech A 2024-06-10 15:35

obviously, I reverted the time changes

Tech A 2024-06-10 15:41

@Albert Khaydatov @Alex Kaplun plz help

Tech B 2024-06-10 15:50

Sounds like trust relationship is now broken, Did you try unjoin rejoin

Tech A 2024-06-10 15:52

wks, yes. no help. yrs, it seems to be the trust is broken as Im getting the "target account name is incorrect" but I can authenticate with the other DC

Tech A 2024-06-10 15:52

try to fix the domain trust between 2 server? or migrate roles to the other server?

Tech B 2024-06-10 15:59

if workstations can talk to the other server, maybe yeah better to move roles and then redo the other server

Tech B 2024-06-10 15:59

that is if its not broken enough to allow role migration

Tech A 2024-06-10 16:04

@Alex Kaplun yeah, its broken

image/png image.png

**Active Directory Operations Masters – RID Role Transfer Failure** The "Operations Masters" dialog (RID tab) shows the current operations master field displaying **"ERROR"** with the message: *"The current operations master is offline. The role cannot be transferred."* A secondary **Active Directory Domain Services** error dialog states: *"The transfer of the operations master role cannot be performed because: The requested FSMO operation failed. The current FSMO holder could not be contacted."* The target server listed is **SVR-TS.bsd.local**.

Tech A 2024-06-10 16:06

what else can we try?

Tech B 2024-06-10 16:10

how did you change time? did you W32TM /unregister then register/resync after?

Tech A 2024-06-10 16:11

no, i stopped the service

Tech C 2024-06-10 16:12

can we check what is the health of DC and see what solutions we can find online?

Tech A 2024-06-10 16:13

@Albert Khaydatov feel free to take over as I am out of ideas

Tech A 2024-06-10 16:13

its in Open

Tech A 2024-06-10 17:53

@Alex Kaplun Albert also tried looking into it but he needs to leave on an emergency visit. Are you able to take a look at this issue for us?

Tech B 2024-06-10 17:56

and what has been done to it?

Tech A 2024-06-10 17:57

I listed all my steps above, but I am not sure what @Albert Khaydatov did

Tech C 2024-06-10 17:59

I did the replication command it says success. Health of dns says all is fine.

Tech C 2024-06-10 17:59

I couldn’t move fsmo roles to other server. Got errors.

Tech C 2024-06-10 18:00

Main server opens all tools of DC so it sees it locally but other PCs don’t.

Tech B 2024-06-10 19:20

It’s not looking good Svr22 being the fsmo and pdc has replicated with secondary dc while date was set to 2022 and automatically was marked as tombstone. Typically if it’s a domain member server the lingering object liquidation is the recommended fix, but since it’s the pdc and we cannot transfer fsmo this would not work. At this point the option is to either redo domain or redo domain

Tech A 2024-06-10 19:23

@Max Grossman @Ross Hendrickson i warned the doctor about the possible issue but he insisted on me doing it. So, its all on them. Can u plz contact the office and schedule domain rebuild?

Tech A 2024-06-10 19:23

(no text)

image/png Image_20240610_152354.png

This image is not a technical equipment image. It shows a Gmail inbox email on a mobile device (15:23, 65% battery) from Iryna Antonovska dated June 6, addressed to "Sergey," requesting that sync be disabled and acknowledging associated risks. This is not relevant to equipment diagnostics or technical reference documentation.

Tech D 2024-06-10 19:24

thats a big labor ticket max just like setting up a server from scratch minus the practice management

Tech D 2024-06-10 19:24

WOAH

Tech D 2024-06-10 19:24

thats ignorant

Tech B 2024-06-10 19:25

yeah domain controllers really don't like time traveling

Tech D 2024-06-10 19:25

i guess i wasnt following the ticket but how in gods name did the time server get so botched?

Tech A 2024-06-10 19:26

(no text)

image/png Image_20240610_152613.png

This image is not a technical equipment photograph — it shows a smartphone screenshot of an iMessage conversation between two individuals discussing domain controller time synchronization settings. The messages reference disabling NTP/world time sync on a domain controller and a request for written approval acknowledging associated risks. No equipment panels, error codes, indicator lights, part numbers, or physical hardware are visible.

Tech C 2024-06-10 19:26

I remember one time I was able to find commands that would force the other domain controller to be become primary even if the primary is down by seizing rights from it. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/transfer-or-seize-operation-master-roles-in-ad-ds

Tech B 2024-06-10 19:31

before seizing lingering objects needs to be cleaned up, and one of the lingering objects is the SVR22 on TS

Tech B 2024-06-10 19:32

this might not work because of this

Tech A 2024-06-11 13:10

@Alex Kaplun how did you determine that? Not even sure where to lok for this type of information

Tech B 2024-06-11 13:31

all the symptoms are there, and Event IDs 2042, 1388 or 1988 tell the details

---
title: "Resolve Domain Controller Trust Relationship Failure After Time Change"
category: accounts-and-access
tags: ["domain-controller"]
source_thread_id: "spaces/AAAA05BdS6s/threads/636fq4bviIg"
source_space: "spaces/AAAA05BdS6s"
generated_at: "2026-04-22T13:09:15"
participants: ["Tech A", "Tech B", "Tech C", "Tech D"]
---

# Resolve Domain Controller Trust Relationship Failure After Time Change

## Problem

After changing the server time on a primary domain controller (PDC) to allow backdating entries in practice management software, workstations lost the ability to authenticate with the server using hostname but could still authenticate using IP address. The only machine that could authenticate by hostname was the terminal server, which also served as a secondary domain controller. Authentication attempts returned "target account name is incorrect" errors.

The PDC had replicated with the secondary DC while the date was set to 2022, causing the primary server to be automatically marked as tombstone. FSMO role transfer attempts failed with errors stating "The current operations master is offline" and "The requested FSMO operation failed. The current FSMO holder could not be contacted."

## Resolution

1. **Verify the extent of the damage** by checking Event IDs 2042, 1388, or 1988 in Event Viewer to confirm lingering object issues
2. **Attempt standard troubleshooting steps** (these typically will not work in this scenario):
   - Restart DNS services on both domain controllers
   - Point workstations to both DCs in network settings
   - Add entries to hosts files
   - Unjoin and rejoin workstations to the domain
3. **Check replication status** using replication commands - replication may report success even when trust is broken
4. **Attempt FSMO role seizure** using Microsoft's documented procedures, though this may fail due to lingering objects including the primary server being marked as tombstone on the secondary DC
5. **If role seizure fails**, the domain must be rebuilt from scratch

The time change caused the PDC to replicate with future timestamps, breaking Active Directory's trust relationships beyond repair through standard recovery methods. Domain controllers cannot reliably handle time travel scenarios.

## References

- Source discussion: `spaces/AAAA05BdS6s/threads/636fq4bviIg`
- Attachments:
  - ![image.png](../attachments/636fq4bviIg.16mjJoJg61U/image.png) — **Active Directory Operations Masters – RID Role Transfer Failure**
  - ![Image_20240610_152354.png](../attachments/636fq4bviIg.KT12enS1EFg/Image_20240610_152354.png) — This image is not a technical equipment image. It shows a Gmail inbox email on a mobile device (15:23, 65% battery) from Iryna Antonovska dated June 6, addressed to "Sergey," requesting that sync be disabled and acknowledging associated risks. This is not relevant to equipment diagnostics or technical reference documentation.
  - ![Image_20240610_152613.png](../attachments/636fq4bviIg.ofDPRae5Eg0/Image_20240610_152613.png) — This image is not a technical equipment photograph — it shows a smartphone screenshot of an iMessage conversation between two individuals discussing domain controller time synchronization settings. The messages reference disabling NTP/world time sync on a domain controller and a request for written approval acknowledging associated risks. No equipment panels, error codes, indicator lights, part numbers, or physical hardware are visible.

Generated article

draft