Curing of a server system is an omnipresent topic. We all tend to provide the most secure environment (hopefully) to reduce the amount of possible attacks on the system. One measure is applicable to the limitation of user access to the system. There are several ways to restrict user access, but in most environments I've seen, Active Directory group policies were used to achieve this. In addition to prohibiting access to prompt and control of Windows registry, there are thousands of other parameters that could be applied because of safety requirements or user.
As probably known all policy settings configured under "User Configuration Policies Administrative Templates" are applied in the registry hive of the user under "HKEY_CURRENT_USER Software Policies" and "HKEY_CURRENT_USER Software Microsoft Policies ". Unlike other paths of the user registry, the user has full control generally, these registry trees are configured with read-only permission for the user. This fact ensures that the user can not modify the settings applied.
But there is a simple function (actually two) that can be used to easily avoid all of your user group policies configured and use all the applications the user has access to unless the appropriate NTFS permission was deleted
runAs and Run as different user
with the command "runas / user :. domain user application " or the use of" Run as different user "from the context menu of applications (shift + right click) can be started with different user credentials. So far so good, but you're wondering what these functions actually do?
RunAs and "Run as different user" allows a user to launch an application with different user credentials. When one of these functions is performed, authentication occurs and a new process will be created with the specified user account. Unless nothing defined, the user profile, or a temporary profile will be loaded. As this procedure does not include a typical user logon process no political groups of users will be applied and there are few other footprints next to the profile and the registry hive user under HKEY_USERS.
You can double -check that by opening the Task Manager. You can find the correct process running with the specified user account, but the user will not be listed in the menu Users Task Manager. In addition, there will be no Group Policy settings listed in the registry hive of the user in HKEY_USERS SID user or temporary profile Software Policies or Software Microsoft Policies.
And that's the point! This circumstance allows a user to work without any user's policy, namely the likelihood of attacks increases. The user account is a normal user on the system and NTFS permissions still apply to the user. These two factors continue to complicate the possibility of harm to the system. Nevertheless, some doors are open now, and a clever user could take advantage of this situation.
Before continuing with the article, I would like to stress that the use cases, as well as additional explanations and recommendations are related to a user session. The purpose of this article is to restrict users while administrators retain access to this feature.
Imagine the following case use. One of your users is to have two accounts to Active Directory users, which is very common that many users have a normal and a test account in the same field. Both accounts are local users on the system and use RunAs or "Run as different user" is not prohibited. The user is connected with the normal account and is now using the second account to start a program with the RunAs or "Run as different user" method. In these circumstances the user would be able to start any program, it has access.
How to prevent access to programs
In my view, the only way to do the right restriction of application is to use the rules AppLocker or other third-party tools. In general, I recommend to my clients to use AppLocker rules, because they are free and offer the flexibility to configure the restriction to suit your needs. All resident AppLocker settings under "Settings Application Control Policies Computer Configuration Policies Windows Settings Security" and therefore all configurations are applied in the registry under "HKEY_LOCAL_MACHINE Software Policies Microsoft Windows SrpV2". Thus, with the AppLocker RunAs and "Run as different user" method will not work because all the settings are applied on the computer and are not related user.
If you are not willing to use AppLocker rules for any reason, you can always limit the RunAs and "Run as different user" function by removing access.
In the early days, it was very simple. Withdrawal of the authorization of the user from runas.exe was enough to completely restrict access to both functions. But since the release of Windows Server 08 R2, the "Run as different user" command has changed and is not based on more Runas.exe. You must perform two steps to completely remove the RunAs and "Run as different user" functions:
1. Restrict access to Runas.exe. There are two ways to achieve this:
a) Configure an AppLocker rule and deny access to C :. Windows System32 runas.exe to the appropriate user groups
b) delete the user authorization from C: Windows System32 runas.exe
2. The second step is to remove the entry "Run as different user" from the context menu. For this you must remove the following registry key
HKEY_CLASSES_ROOT exefile shell RunAsUser
HKEY_CLASSES_ROOT batfile shell RunAsUser
HKEY_CLASSES_ROOT cmdfile shell RunAsUser
HKEY_CLASSES_ROOT mscfile shell RunAsUser
HKEY_CLASSES_ROOT Msi.Package shell RunAsUser
(This change will affect administrators as well)
Even if you have already restricted access to the application using AppLocker rules or another third tool, I still recommend to delete the entry context menu to provide the safest possible solution.
If you are still looking for a simple way to limit access to functions for everyone (administrators and users), and then disable the Secondary Logon service (thank you Martin for Latteier the entrance).
Let's take a last look at risk management. I agree that this is a rare scenario. However, it is essential not to underestimate the internal danger and its possible negative impact on the system. As you can see, there are only a few steps before you to reduce exposure to risk. I recommend you implement the steps outlined above to ensure the safety of high system.
I hope you have enjoyed reading.
Best regards
Saša Petrović
0 Komentar