HELP ! Replication issue

[fiza]

When I run DCDIAG I get this error (I anonymised the domain name)

 

An error event occurred. EventID: 0x40000004 Time Generated: 05/15/2023 15:14:56 Event String: The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc2$. The target name used was LDAP/DC2.domain.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN.com) is different from the client domain (DOMAIN.com), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server. An error event occurred. EventID: 0x40000004 Time Generated: 05/15/2023 15:21:23 Event String: The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc2$. The target name used was cifs/DC2.domain.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN.com) is different from the client domain (DOMAIN.com), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server. ......................... DC1 failed test SystemLog

 

 

I tried resetting the computer password by doing ;

 

 

1. Deactivate the service “Key Distribution Center”
   
2. Restart Domain Controller
   
3. Start a command-box as administrator and enter the following command:
   
4. netdom resetpwd /Server:Servername /userd:Domain Administrator /passwordd:Password
   

 

1. Restart Domain Controller
   
2. Reset the service “Key Distribution Center” to automatic start and start
   

Where Servername is the DC with PDC role.

 

[fiza]

Since running that last command to reset the password the 2 DCs are now replicating but DC Diag is still showing the same error as above.

[robintech]

this looks relevant , could be DNS still though and I'm guessing not speaking from experience.

 

https://social.technet.microsoft.com/Forums/en-US/1bbb1769-3323-47a6-8614-e39e3c76f220/replication-errors-the-target-principal-name-is-incorrect-?forum=winserverDS

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server sa-dc1$. this is error I am seeing on all servers.

krbtgt account password out of sync... Disable and stop the kdc service on all DCs but the PDC emulator. Then reboot them one at a time. This will force all to obtain their TGT from the PDC and will enable them to start replication. After that, enable and start the kdc service

[Oaktech]

Since running that last command to reset the password the 2 DCs are now replicating but DC Diag is still showing the same error as above.

 

Sometimes DC Diag needs 24hrs without an error to decide it's fine.

[djm968]

How are things today, any update @fiza?

[fiza]

How are things today, any update @fiza?

 

Thankfully everything seems to be working as expected. @Oaktech was correct about 24hrs as DCDiag is now reporting all good.

I am not 100% sure where the issue arose from but I still suspect the DC that I demoted as the other 2 are playing nicely now.

 

Thanks for all the advice everyone.

[Koldov]

So from what i can decipher I have one DC that seems to be having issues and I may have demoted the wrong one thinking originally that the issue was there.

 

DC1 can run netdom query fsmo successfully and knows what roles it has and what roles the other DC has.

DC2 can run netdom query fsmo and shows itself as an operations master for Schema and Domain naming but shows the other roles as belonging to the demoted server.

 

On DC1 when I view operations masters in User and Computers it shows itself as the master.

 

When I view operations masters in Domains and Trusts it shows DC2 as the operations master but the 'change' option is greyed out and it shows "The current operations master is offline. The role cannot be transferred."

 

On DC1 when I view operations masters in Users and Computers it shows "ERROR" where the master should be.

 

On DC2 Domains and Trusts does not load at all showing "The configuration information describing this enterprise is not available. The target principle name is incorrect"

 

Glad you're sorted, but (if I'm reading all that correctly), interested to know what the thinking is behind splitting all the roles between various different DCs...? All the PDC roles are on one DC here and I get the fact that's a single point of failure, but I think if something goes wrong it's easier to work out and seize/transfer everything. Any benefit/best practise/gotchas doing it one way or the other? Also thinking for whatever reason it was done, it didn't seem to help? Obviously forget it if I've misunderstood your set-up....

 

check the settings on of DNS on each server and check that it is pointing to itself secondary (ip address) and then to the other DC's address (ip address) as the primary (in the network configuration). Hope that makes sense....

 

Check the IP config on NICs of both servers.

 

Primary DNS of DC1 should be set to the IP of DC1. Secondary DNS should be IP of DC2

 

Primary DNS of DC2 should be set to the IP of DC2. Secondary DNS should be IP of DC1

 

I've always had mine the other way round (pointing to the other DC 'Preferred' and then to itself 'Alternate'). Is the thinking behind the way you do it best practise, as if it loses network connectivity it can still DNS (although it would anyway if it points to itself as 'Alternate'...?

[fiza]

@Koldov

 

I was always told that the PDC and RID Master should be on the same DC. In a single domain the Infrastructure Master has no work so can go on any DC.

 

https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/fsmo-placement-and-optimization-on-ad-dcs

 

• Place the RID master on the domain PDC in the same domain.
  RID master overhead is light, especially in mature domains that have already created the bulk of their users, computers, and groups. The domain PDC typically receives the most attention from administrators. Co-locating this role on the PDC helps ensure reliable availability. Make sure that existing domain controllers and newly promoted domain controllers have network connectivity to obtain active and standby RID pools from the RID master, especially the domain controllers promoted in remote or staging sites.
   
  
• Legacy guidance suggests placing the infrastructure master on a non-global catalog server. There are two rules to consider:
   
  
  • Single domain forest:
    In a forest that contains a single Active Directory domain, there are no phantoms. So, the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, whether that domain controller hosts the global catalog or not.
    

[TwistedHelixis]

Primary DNS of DC1 should be set to the IP of DC1. Secondary DNS should be IP of DC2Primary DNS of DC2 should be set to the IP of DC2. Secondary DNS should be IP of DC1

 

I was told by Microsoft not to do this as it can cause some kind if island issue with the data.

 

I have

 

Primary DNS of DC1 set to the IP of DC2. Secondary DNS set to IP 127.0.0.1

Primary DNS of DC2 set to the IP of DC1. Secondary DNS set to IP 127.0.0.1

[Mako]

@TwistedHelixis what you're referring to is in this (rather old, now) MS Blog: https://learn.microsoft.com/en-gb/archive/blogs/askds/friday-mail-sack-saturday-edition#dnsbest

 

If at all possible on a DC, client DNS should point to another DNS server as primary and itself as secondary or tertiary. It should not point to self as primary due to various DNS islanding and performance issues that can occur. (This is where the arguments usually start)

[fiza]

@TwistedHelixis what you're referring to is in this (rather old, now) MS Blog: https://learn.microsoft.com/en-gb/archive/blogs/askds/friday-mail-sack-saturday-edition#dnsbest

 

Has the guidance been updated to say not to do this?

[Mako]

These articles still exist and are still valid, so they still stand. I think, arguably, it does depend on your situation. It causes discussion/disagreement because it may not matter at all, or it might potentially be a problem.

 

There is a page for the problem caused by this, here: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-server-becomes-island

 

Personally I have them pointing at each other for the primary DNS, and themselves as the secondary.

[HPlum78]

Sorry my wording is not the best, but what I am saying is primary should be a another DC and secondary should be itself.

 

The idea is that if its its own address first then there is a risk thar replication will be isolated if there is a problem with DNS. In a nutshell...

 

Glad you are back up and running, nice work.

[jmak]

Seems to be a replication issue in the Android app!

[HPlum78]

Ha clearly this issue is escalating, quick switch the internet off!

[Koldov]

How apt...

 

[ITB0SS]

Sorry did best practice get decided? in regards to primary and secondary DNS settings on domain controllers.