Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
· Hi all,
A few years ago, when Windows Server 2008 released, we blogged about some changes made in the operating system to reduce the overall attack surface of installed services on the Server. This was taking changes made in Windows Server Service Pack 1 to the next level.
These changes were called Service Hardening which included changes in the Service Account User and changes to the permissions granted to the user at the registry, file, and network levels. This was done with the intent that these Service account would not be changed from their new users.
Unfortunately over the years, support personnel have at times recommended changing the account that a particular service runs under back to a “more privileged” account to resolve issues caused by other changes. Sometimes a security template will get applied to a system that was not designed for that operating system. Applying a security template designed for Windows 2000 will not take into account the changes made in the operating system in Windows Server 2003 Service Pack 1.
We fielded many cases with customers upgrading to Service Pack 1 or Service Pack 2 from RTM in Windows Server 2003 where it was necessary to reset the file permissions back to defaults defined by the setup process (see KB 873148 and KB 313222).
Unfortunately this has continued over the years, and even continues into Windows Server 2008 R2.
From a support perspective it may seem easy to change the Service account for a system service and feel that “Since the account I am changing it to has more privileges, it must be better overall.”
However there are a few possible problems that can crop up. One problem comes from the fact that the change in service account was a conscious decision by the Windows Product Group. This means that there are likely to be other internal changes which have been made. In some cases the “more privileged” account may actually be specifically denied access to a file, registry, or network resource.
A case which recently came up pinpointed this fallacy and took quite some time to troubleshoot and diagnose since the changes made to the service account were not expected.
The customer had installed the Windows Server 2008 Remote Desktop Session Host role service on his server. After doing his entire configuration he had attempted to connect to the server, only to find that he was getting an “Access Denied” error message. This was unexpected because he was connecting with a Domain Administrator account. Hours were spent by the customer and Microsoft support investigating and troubleshooting the “Access Denied” error message. It was a very intriguing case from the standpoint that all of the services were installed and running. There were no Security event log entries speaking to the “Access Denied” error message. Conventional troubleshooting for this error yielded no discernable cause. Most interesting was that we actually saw the session getting connected, so Remote Desktop Services were up and running. But we were getting the “Access is Denied” message on the logon screen, like so:
Process Monitor did not show any Access Denied error messages on Registry, file, or network.
Nonetheless we were unable to log onto the server via Remote Desktop. Access to the console session was not restricted.
Ultimately a registry comparison of the Services registry key revealed the difference from a clean fresh install was that the Logon Account for the Remote Desktop Services had been changed. When questioned, the customer noted that “He had read about using LocalSystem being better” from an unremembered Internet posting. Here is what his TermService registry key looked like:
And this is what this same key looks like on a clean install:
Once the account entry was changed to the default and the system rebooted, Remote Desktop connection was immediately made and logon was successful. One thing of note in this case was that reinstalling the services did not make a change back to the default service account, nor did running the Secedit SecSetup.inf command to reset system permissions(KB 313222).
Ultimately we need to ensure that we are running the operating system as it has been designed and engineered. What appear to be small changes such as a service account, can have far reaching and possibly devastating consequences. I’ve worked cases where on Windows server 2008 the Service account for the RPC Service (RpcSs) was changed to LocalSystem to account for some build document that was originally written for Windows 2000. The problems caused by the registry and file system changes were widespread on the server. However, in this case, they were resolved by changing the service account back to the Windows Server 2008 default of NT Authority\NetworkService and restoring the other default security settings using Secedit.exe.
I hope that this information helps you troubleshoot any strange and seemingly unresolvable issues. Until next time, have a good weekend.
Thanks ever so much for this post. I've spent the past 2 days searching post after post for this fix in a simple straight forward manner and had not found one that made sense to me, a novice for the most part with MS Server products and services.
I do not get it. What was the reason that Local System had an access danied error? I thought Local System account has more permissions that Local Service and Network Service accounts..
Thanks for your help!!
But, What permissions that we have to restore?! (What folders?!)
Ok, but I never changed any logon account for remote desktop services and I'm getting the same access denied message.
David's solution worked for us. The server that displayed these symptoms had had an instance of Remote Desktop services installed and then un-installed. RDC had worked before the Remote Desktop services were installed but not after that installation and un-installation. Others (like us!) not guilty of regedit's but still experiencing this symptom may care to check RDS installations...
HAs anyone seen this when trying to end the a Process in task manager and when using taskkill in an elevated CMD?
MY REGISTRY LOOKS LIKE THE LATTER ONE (FRESH INSTALL SCREEN SHOT)
BUT I STILL GET THIS ERROR
CAN U PLS HELP ME?
Can someone tell me the exact registry path to these keys?
I encountered this same issue on Win7 Pro devices and spent a couple of days chasing my tail. The Service startups were all correct. I ended up running ProcessMonitor and found that access to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon was being blocked. Compared permissions on this hive against a known good working device and found that the Users = Read right was not present. Added this right and now working great.
Hope this helps someone. I had everything set correctly as already mentioned. Issue for me was the domain controller server which our TS server relies on, the 'server' service on the domain controller had become stuck and non-responsive. I couldn't even reboot the service. Once I rebooted the domain controller, confirmed that people could log onto the TS server again with no issues and no longer seeing the Access is Denied error message.
Paste the entire registry key info.. not everyone will magically know where to find this.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService
What was the registry path? HKLM\Software\Micro...\Term Services...?
I had the scenario; members of Administrators could logon but members of only Remote Desktop Users couldn't. It turned out the server had been moved from another domain. It's a TS licenseserver itself but someone had forgotten to add it Domain\Terminal
Server License Servers group.
I'm getting the same problem with my Server2012R2. However I checked the registry entry and it is set to network service. Everything is installed correctly on the server RDS components and licenses. All I get is an "Access is Denied" message when I try
to remote desktop to that server.
Thanks yar after changing the registry you have restart the server, then only it will works.
Change the Objectname to NT Authority\NetworkService
Once again thanks.