blog.iabsolute.com

ometimes when you create new DC you will get this error inside event log. It means that WINRM service can not create SPN in Active directory with its credentials. You can create SPNs manually, but WINRM service will try to create it every time you start domain controller. To solve this you need to give certain permissions to Network Service account in Active Directory.

For this to work you need to give Network Service next permissions on DC computer object using ADSI edit console (ADSIEDIT.msc).

According to Microsoft :
Cause
This event is logged when the Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons, or the KDC certificate could not be verified.
Resolution
Request a new domain controller certificate
Kerberos uses a domain controller certificate to ensure that the authentication information sent over the network is encrypted. If the certificate is missing or is no longer valid, you must delete the domain controller certificate and then request a new one.
To resolve this issue:
Delete the domain controller certificate that is no longer valid.
Request a new certificate.
To perform these procedures, you must be a member of the Domain Admins group, or you must have been delegated the appropriate authority.
Delete the domain controller certificate that is no longer valid
To delete the domain controller certificate that is no longer valid:
1.On the domain controller in which the issue is occurring, click Start, and then click Run.
2.Type mmc.exe, and then press ENTER.
3.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
4.Click File, and then click Add/Remove Snap-in.
5.Click Certificates, and then click Add.
6.Click Computer account, click Next, and then click Finish.
7.Click OK to open the Certificates snap-in.
8.Expand Certificates (Local computer), expand Personal, and then click Certificates.
9.Right-click the old domain controller certificate, and then click Delete.
10.Click Yes, confirming that you want to delete the certificate.
11.After the certificate is deleted, follow the procedure in the “Request a new certificate” section.
Request a new certificate
To request a new certificate:
1.Expand Certificates (Local computer), right-click Personal, and then click Request New Certificate.
2.Complete the appropriate information in the Certificate Enrollment Wizard for a domain controller certificate.
3.Close the Certificates snap-in.
Verify
To perform this procedure, you must be a member of the Domain Admins group, or you must have been delegated the appropriate authority.
To verify that the Kerberos Key Distribution Center (KDC) certificate is available and working properly:
1.Log on to a computer within your domain.
2.Click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
3.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
4.At the command prompt, type certutil -dcinfo verify, and then press ENTER.
5.If you receive a successful verification, the Kerberos KDC certificate is installed and operating correctly.

The Ugly

A routine check of the system log advised warnings related to the NETLOGON service. As this service is related to all remote network accesses to the DC servers, such an event must be carefully investigated.

There is a long explanation about this error and it requires careful reading. I highlighted the two most important pieces of information. Here is the whole description of this event:

During the past 4.16 hours there have been 107 connections to this Domain Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client's site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites.

The names and IP addresses of the clients in question have been logged on this computer in the following log file ‘%SystemRoot%\debug\netlogon.log’ and, potentially, in the log file ‘%SystemRoot%\debug\netlogon.bak’ created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text ‘NO_CLIENT_SITE:’. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize’; the default is 20000000 bytes.

The current maximum size is 20000000 bytes.

To set a different maximum size, create the above registry value and set the desired maximum size in bytes.

There is the log file named netlogon.log. This file is located in the folder %SystemRoot%\debug. In most cases, this is C:\Windows\debug. This log is now your best friend.

The Bad

The second piece is that those computers can’t be associated with any know site. I opened the named log file and found that all those machines added to the domain with the IPs from test network have this label NO_CLIENT_SITE.

The Good

I opened the Active Directory Sites and Services console and expanded the Subnets tree.

I found that this highlighted network doesn’t exists. Adding it into the subnets list and associating it with the HQ LAN site solved this issue. No more NETLOGON related events in the System log.