Hi! On a MS Windows Server 2003 Standard with SP2 the following odd problem started to occur some time ago: all services which run as the "NT AUTHORITY\NetworkService" account cannot start. After the Windows is restarted everything works file for a day or two and then the problem shows up again. The server is a domain controller but does not have any of FSMO roles. Another domain controller in the domain does not have this problem. There are various errors and warnings logged in the Event Log regarding the issue, for example: Event Type: Warning Event Source: LSASRV Event Category: SPNEGO (Negotiator) Event ID: 40960 Date: 19.03.2012 Time: 03:07:45 User: N/A Description: The Security System detected an authentication error for the server DNS/foo.bar.local. The failure code from authentication protocol Kerberos was "A specified logon session does not exist. It may already have been terminated. (0xc000005f)". An attempt to restart the DNS Client results in the following: Event Type: Error Event Source: Service Control Manager Event Category: None Event ID: 7038 Date: 20.03.2012 Time: 17:38:29 User: N/A Description: The Dnscache service was unable to log on as NT AUTHORITY\NetworkService with the currently configured password due to the following error: Cannot start a new logon session with an ID that is already in use. Event Type: Error Event Source: Service Control Manager Event Category: None Event ID: 7000 Date: 20.03.2012 Time: 17:38:29 User: N/A Description: The DNS Client service failed to start due to the following error: The service did not start due to a logon failure. It seems as if there is a problem with the NetworkService account. Group Policy should be fine as in the Default Domain Policy, as well as Default Domain Controllers Policy, in the branch of Windows Settings/Security Settings/Local Policies/User Rights Assignment the "Log on as a service" policy includes the "NT AUTHORITY\NETWORK SERVICE" account. Is there a possibility that the NetworkService account gets locked? Has anyone seen this issue before? I'd really need to fix it as the server is in production (e.g. it runs WSUS 3.0 SP2). TIA -- rpr.

I remember the recommendation that no service on a Domain Controller should run with a local account. The main problem is that there is no local SAM account database on a DC, but I think the built in "network service" is also a security concern. It is essentially the computer object and has more permissions than necessary. The recommendation I recall (for SQL Server) was that you should configure a domain user account to run the service. The account should have only the permissions necessary for the service. The only documentation I could quickly find: http://msdn.microsoft.com/en-us/library/ms143504.aspx Was your dc recently promoted, and perhaps the problem started after that? Since the network service account is essentially the local system, maybe forcing a password change would help. One recommendation I remember for sure; Never run dcpromo (either to promote to a dc or to demote to a member server) on a computer with SQL Server installed. Richard Mueller - MVP Directory Services

Richard, the server was promoted to a DC long time ago (more than 5 years). The recommendations you mentioned seem reasonable BUT I wonder why Microsoft developers do not follow them. The server runs the following Microsoft services with the "NT AUTHORITY\NetworkService" account: aspnet_state (ASP.NET State Service) Dhcp (DHCP Client) MSDTC (Distributed Transaction Coordinator) Dnscache (DNS Client) LicenseService (License Logging) RpcSs (Remote Procedure Call (RPC)) MSSQLServerADHelper (SQL Server Active Directory Helper) WsusService (Update Services) MSSQL$MICROSOFT##SSEE (Windows Internal Database (MICROSOFT##SSEE)) WinRM (Windows Remote Management (WS-Management)) I'm sure the server was a DC when WSUS was installed. If Microsoft followed their own recommendations, then the services installed for WSUS 3.0 (WsusService, aspnet_state, MSSQL$MICROSOFT##SSEE, MSSQLServerADHelper) would not run as "NT AUTHORITY\NetworkService" account but as another domain user created by the installation. -- rpr.

After additional troubleshooting this issue I'd say I've found the root cause of the problem. The hardware clock frequency on this server (which is a DC) has an error and the clock drifts quite a lot. The Windows Time service cannot take the clock drift into account (it can only correct system time by discontinuous changes). So, the system time is corrected by a scheduled task that runs every 4 minutes and synchronizes the clock with another DC. It seems that despite of the synchronization the system time of the server occasionally differs too much and exceeds the maximum tolerance for computer clock synchronization of the Kerberos protocol. In the Default Domain Policy GPO I changed the following setting: Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Kerberos Policy -> Maximum tolerance for computer clock synchronization -> increased from 5 to 7 minutes After that change the services which run as the "NT AUTHORITY\NetworkService" account on the server have not experienced the problems mentioned in my initial post for last 3 weeks. I'd say the issue has been fixed. -- rpr.