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

clip_image001

To start troubleshooting, we’ll start by ruling out the following main causes.

  1. Checked DNS.
  2. Checked relative services (Netbios, RPC, Computer browser ..etc)
  3. Checked firewall (Kaspersky and windows) and closed them both.
  4. Checked connected DC and changed it to a different one.
  5. 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

From <https://support.microsoft.com/en-us/kb/175024/>

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.

From <https://support.microsoft.com/en-us/kb/175024/>

Solution 1-

nltest.exe can be used to check the channel and attempt to reset it.

nltest.exe /sc_verify:smartmoss.local

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
nltest.exe /sc_verify:<fully.qualified.domain.name.here>

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.

ipconfig /flushdns
arp -d *
Get-Service netlogon | restart-service
nltest.exe /sc_verify:<fully.qualified.domain.name.here>

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

Testing tool

Checked the following tool

http://www.lansweeper.com/kb/2/The-RPC-server-is-unavailable.html

Checked the services RPC, computer browser,

Solution 2-

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.

From <http://community.spiceworks.com/topic/218426-there-are-currently-no-logon-servers-available-to-service-the-logon-request>

net stats srv

clip_image002

clip_image003

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.