2

I recently added a new Server 2012 DC and took the previous 2003 DC offline. The Server 2012 DC is now the only DC on the network. I also added an alias (CNAME) so that the new server can be accessed with the old server's DNS name.

I am now seeing an error and several warnings in the event log which I suspect are related to some "leftovers" or otherwise configuration that attempts to sync to the old server. One of these events are: [Error] Kerberos Event ID 4 - The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server new-srvr$. The target name used was cifs/old-srvr.

I was hoping someone could shed some more light on this with a possible resolution.

UPDATE: Adding some more detail I did demote the 2003 DC using dcpromo before taking it offline. I did have to use the force option though because I was getting an error related to DomainDnsZones and fSMORoleOwner. Not sure why because I did verify all 5 of these roles have transferred ownership to the new server: Schema Master Domain naming master Infrastructure Master Relative ID (RID) Master PDC Emulator I followed the guide here.

Second, the reason I added the CNAME is for SMB and not domain-related. I wanted clients to be able to continue to use \old-server and so I followed the instructions here.

I wonder if perhaps this is a "dangerous" practice for DCs and cannot / should not be done.

Community
  • 1
Dandan
  • 123
  • 1
  • 4
  • The proper way to do this would have been to demote the 2003 DC. – joeqwerty Aug 07 '15 at 16:01
  • Sorry, I should have specified this - I did demote the DC, though I had to use the /force option since there was some error with DomainDnsZones. – Dandan Aug 07 '15 at 16:39

1 Answers1

2

"I also added an alias (CNAME) so that the new server can be accessed with the old server's DNS name."

Nice try, but the KRB_AP_ERR_MODIFIED error is Kerberos's way of telling you to $#@! off because the names don't match. All host names, DNS A records, and SPNs must match. CNAME/alias records cannot be used in this situation.

(To be more specific, clients construct SPNs for Kerberos using the DNS name of the computer that is hosting the service that the client wishes to connect to. If that SPN is not registered on the computer object in AD, which it won't be, because the new DC has a different name than the old DC, Kerberos won't work.)

You need to perform metadata cleanup of the old DC.

https://technet.microsoft.com/en-us/library/Cc816907(v=WS.10).aspx

Scroll down toward the bottom of the article where it explains how to use ntdsutil to perform metadata cleanup.

Delete that CNAME. Delete extant DNS records that refer to the old server. That includes A records, SRV records, PTR records, etc.

Check each and every domain member and ensure that they are using the IP address of the new domain controller as their only DNS resolver.

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • Please see my update, the old DC was demoted before taking offline. Is there any way to fix this without bringing it back online? I would have to restore it from backup since it's already been deleted. – Dandan Aug 07 '15 at 16:46
  • Best interpretation of Kerberos-speak ever, it has to be said. – ErikE Aug 07 '15 at 16:51
  • @Dandan The most important thing is never, ever, bring the old server back online or restore a backup of it. Second, just use `netdom query fsmo` and verify that all the FSMOs are located on the correct DC. Thirdly, that Kerberos error is expected if you're using a CNAME record. SMB is CIFS, and that service registers a Service Principal Name on the computer account. It attempts to use Kerberos first when you browse to a file share. But it fails because I browsed to `\\oldserver\share` which is an alias to `\\newserver\share`, and newserver does not have a CIFS SPN registered for oldserver. – Ryan Ries Aug 10 '15 at 17:16
  • So is there a way to fix that while keeping the cname? – Dandan Aug 11 '15 at 06:12
  • I came across question this due to an SSRS API Kerberos error and in my case the KRB5KRB_AP_ERR_MODIFIED error was because the `http/server.domain.local` SPN was missing from the service account. Same basic problem: the SPN for the account didn't match up with the request but worth noting the possible alternate source of issue for that error. – duct_tape_coder Oct 27 '20 at 23:32