A blog with focus on experiences with the Windows Client operating systems…
RSS icon Email icon Home icon

  • Busting a myth: AppLocker do not magically allow standard users to install applications or updates

    Posted on May 10th, 2012 By Andreas Stenhall + No comments

    The one most common misconception around AppLocker is the fact that it could be used to allow standard users to install stuff that in any normal case would require administrator privileges. This is absolutely 100% incorrect.

    What AppLocker does is set a number of rules on what can be run and executed on a machine. It is important to note that if you allow something to run or be executed via AppLocker rules the user will still need the appropriate privileges if the setup or application itself require administrative privileges at some point in time such as when doing automatic updating for instance.

  • Case of the mysterious issues with UAC in Windows 7 and Windows Server 2008 R2

    Posted on September 18th, 2010 By Andreas Stenhall + 3 comments

    At the TechNet/MSDN after work I attended last week I got an interesting question on why a user (domain admin) gets a UAC popup on trying to access folders via Explorer which he knows for sure he is supposed to be able to access looking at the ACLs of the folder. Instead, when clicking OK on the UAC popup the ACL is populated with his account.

    UAC requesting permission to continue

    My first thought to this behavior was Explorer.exe not being able to elevate and the “split personality” i.e. the two security tokens involved when UAC is in effect. Here comes a more detailed explanation that I think is of interest to more. Note that this problem also covers some other scenarios such as AppLocker rules not appearing to work as intended for administrators. Read on to learn what is causing this.

    First when UAC is enabled you get two security tokens when you log in, easily explained as one which contains the administrator privilege information and one which does not. Most of the times you run everything using the standard security token. When you for instance want to install software or change some system settings, then the security token containing the administrator privileges information is used.

    If you do not explicitly request an application to launch with higher privileges, or the applications itself request higher privileges, all processes and applications run in the user context with the standard security token. Virtually all applications including Windows applications and processes are possible to elevate by right clicking and choosing “Run as administrator”. This is not true for Explorer.EXE though as all your attempts to elevate it will not result in any actual elevation. There are a few caveats with this and let us continue with the example of access certain files and folders.

    So let’s have a look at what the ACL of the folder D:\Share looks like:

    ACL of users\stenis folder before UAC continue

    We can clearly see that there are no user accounts in this list. Under normal circumstances any user which is a member of the domain admins group should be able to access that folder but instead is presented with the UAC dialogue:

    UAC requesting permission to continue

    What happens when the user “stenis” in this case clicks “Continue” to that UAC dialogue box questions is that the ACL is populated with the user account in questions:

    ACL of users\stenis folder after UAC continue

    This happens because the fact that Explorer.exe cannot be elevated the normal Windows Explorer does not see that the user account should be able to access that folder. It is easy to verify as you can actually run Explorer.EXE elevated by changing the registry setting “RunAs” to “_RunAs” in HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}. Thanks goes to Andre Ziegler for this finding.

    So what does this tell us? It is a somewhat strange problem but still by design. The fact is that this “problem” is not applicable to the folder and file access as described in this blog but also for AppLocker rules for instance, as many domain administrators must choose “Run as administrator” to be able to run software which they think they should be able to run without this little procedure.

  • Standard users installing applications? Say welcome to the new reality

    Posted on April 8th, 2010 By Andreas Stenhall + No comments

    If you think that you have come a far way making sure all users are running as standard users you must stop and rethink. Well, having all users as standard users is very good from many perspectives but with coming challenges your efforts must not stop there. A growing problem is the fact that more and more applications install in the user space, i.e. in the \users\username\appdata directory instead of the traditional “Program files”.

    Also Windows 7 contain Windows Installer 5.0 which sports a new feature which makes the software vendors easily make Windows Installer (MSI files) that install software in the user space instead of program files, and thereby not requiring the user to be administrator or even require a UAC prompt for credentials for an administrative account.

    The standard users of course think this is great, meaning they after all can install and run for instance Google Chrome without needing to ask that restrictive IT department. From the IT departments view this fact that standard users can install and run applications is a concern.

    The answer to take care of this problem is simply the new Windows feature AppLocker. To be honest it is somewhat like Software Restriction Policies (SRP) but whatever bad things you have heard about SRP you can forget about them. AppLocker contains new features that make the implementation and ongoing management very easy compared to Software Restriction Policies. More about AppLocker in the AppLocker walkthrough.