If you’re doing a Cross Forest migration project then you most likely have had a big experience but the more you do those kind of projects the more you’ll see different types of errors and issues rising up.
One of the issues I had in one of the cross forest projects that I have done before was the following error
To start troubleshooting, we’ll start by ruling out the following main causes.
- Checked DNS.
- Checked relative services (Netbios, RPC, Computer browser ..etc)
- Checked firewall (Kaspersky and windows) and closed them both.
- Checked connected DC and changed it to a different one.
- Checking DCs / Frs (File repliation service) replication and health.
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server smart0188$. The target name used was RPCSS/Smart0248.smartmoss.local. 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 (SMARTMOSS.LOCAL) is different from the client domain (SMARTMOSS.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
Suppose you have a domain member named DOMAINMEMBER. You can reset the member secure channel by using the following command:
NETDOM MEMBER \\DOMAINMEMBER /JOINDOMAIN
You can run the command above on the member DOMAINMEMBER or on any other member or domain controller of the domain, provided that you are logged on with an account that has administrator access to DOMAINMEMBER.
The output received from the command should be similar to the following:
Searching PDC for domain DOMAIN …
Found PDC \\DOMAINPDC
Querying domain information on PDC \\DOMAINPDC …
Querying domain information on computer \\DOMAINMEMBER …
Computer \\DOMAINMEMBER is already a member of domain DOMAIN.
Verifying secure channel on \\DOMAINMEMBER …
Verifying the computer account on the PDC \\DOMAINPDC …
Resetting secure channel …
Changing computer account on PDC \\DOMAINPDC …
Stopping service NETLOGON on \\DOMAINMEMBER …. stopped.
Starting service NETLOGON on \\DOMAINMEMBER …. started.
Querying user groups of \\DOMAINMEMBER …
Adding DOMAIN domain groups on \\DOMAINMEMBER …
The computer \\DOMAINMEMBER joined the domain DOMAIN successfully.
Logoff/Logon \\DOMAINMEMBER to take modifications into effect.
nltest.exe can be used to check the channel and attempt to reset it.
If that does not do it, you can restart the netlogon service (I mainly use PowerShell, so I’ll give an example of that).
Get-Service netlogon | restart-service
I ran the nltest command after restarting the service to validate that the secure channel was back in operation.
If you’ve made some network changes (IP Addresses, changing hardware, virtualizing, etc..) you might want to flush your dns cache and clear your arp table before running the above commands.
arp -d *
Get-Service netlogon | restart-service
Let’s try to find out which DC the client is connected to
nltest /dsgetdc: Dc.local
Point the client to a different DC
nltest /Server:client0 /SC_RESET: DC.Local\DC02
Checked the following tool
Checked the services RPC, computer browser,
There is a bug in MS after 400 days of uptime that they don’t tear down their time_wait connections so the server runs out of sockets and can’t make connections to the DC – a reboot should fix this issue temporarily.
net stats srv