· 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.
David John
| Share this post : |
|
|
|
|
|
|
|
|
<br/>