The “Run in Logged on User’s Security Context” option is one of the least understood (and used) features of Group Policy Preferences. Understanding how to use it (and when) can save you hours of frustrating and fruitless troubleshooting! In this post, we will cover a practical example showing when to use “Run in Logged on User’s Security Context”. First, a little introduction on this cool little Group Policy setting:
“Run in Logged on User’s Security Context” is one of the 5 common options found within each Group Policy Preference CSE. You are probably familiar with other Common Options through the use of the “Apply Once and Do Not Reapply” as well as the massive filtering add-on “Item Level Targeting”. Understandably, this option is only available under the User Configuration node because it can change the preference security context.
Security Context in Group Policy Preferences
Group Policy Preferences are so easy to setup and use because of the simplified security context. Every preference item applied is processed under the local SYSTEM account. This applies to preference items created under both the Computer and User Configuration nodes.
When you select “Run in Logged on User’s Security Context”, the security context is changed from SYSTEM to the current logged-in User. This is a huge distinction when you are creating preferences for Files, Shortcuts, or Drive Mappings! Basically, any preference that touches a network device can be altered with this common option.
0x8007005 Access is Denied? Preferences Say What?
Knowing that Group Policy Preferences run as SYSTEM by default, the error message below might seem a bit baffling:
A simple Group Policy Files preference is failing because “Access is denied”. Looking closer, you will see two warning messages above. It appears that two File Preferences are failing and both are in the same GPO. Both are getting the same “Access is denied” warning. Let’s take a look inside that GPO to figure out why.
This GPO starts by deleting any file named “NutriKids Menu Planning.lnk” from the %DesktopDir%\. We know that the Delete preference will process first because it’s order is “1”. As a reminder, %DesktopDir% is a GPP variable for the current user’s desktop. You can see every variable (plus how to access them) by downloading these Group Policy notes.
Our second preference creates a new shortcut. It copies that shortcut from a server (\\msi\) and places it on the current user’s desktop. This two step process (Delete,Create) is a real easy way to ensure that any user created shortcuts point to their correct locations. It is also handy when you are migrating servers/shares and don’t want to end up with a bunch of broken shortcuts.
So What is the Common Factor?
The two preferences above have one thing in common – they are both attempting to write to %DesktopDir%\. Because we redirect our user’s desktop to a server, the local SYSTEM account get denied! SYSTEM can’t write to a server without the correct permissions. Even if you enabled Loopback Policy Processing and set it to OverLord Tank mode, the shortcut won’t ever get created!
The simplest solution is to open the Common tab on both preferences and enable “Run in Logged on User’s Security Context”. After a single GPUpdate or a 90 minute (relative) wait, the File preferences will apply and magically appear!
Microsoft has a little more information about the Common options. That information can be found here.
Your Turn:
“Run in Logged on User’s Security Context” is a pretty simple solution to a complicated issue. I am working on a part 2 to the “Troubeshooting Group Policy Preferences” checklist and this setting will be on that list. But I need your help!
What problems have you experienced with Group Policy Preferences? How did you fix it? Leave a comment below and your solution might be on second troubleshooting guide (with credit to you)!
I landed here trying to understand and troubleshoot ‘run in logged-in users security context’. This is something I will choose 99% of the time when creating Drive maps, because surely that makes sense? But today it doesn’t…
My standard setup:
New 2019 Server has shared folder, ‘Everyone full’ on the sharing and then ‘Folder Group’ have full NTFS permissions. Therefore if you are in the group, you can access the folder. The mapping should ‘run as user context’ because ‘system’ probably doesn’t have access to the folder..? Or if it does, everyone would have system access to the folder and this is not desired…?
Anyway what I did differently with this install is to use ILT, to only apply if you are a member of the specific group. Therefore if you aren’t a member, you no longer see a mapped is drive but you get ‘access denied’ when you click on it (which is normally what happens if you are not a member). For most customers I don’t do ILT, mainly because I forget, but this time I have done it.
During migration of Server 2008 > 2019 whilst both servers were still DCs (only these 2 DCs) we got inconsistent results but after dcpromo the 2008 server down to member server, the drive maps don’t seem to show up at all – until I remove ‘run in logged in users context’. WTF?
Anyway – this is not conclusive at the moment I still have to test more and confirm this is fixed for all users 100% of the time, but it’s looking like it. So in this case, the user context is the wrong context…?
I have this exact issue but I had to actually un-check run in logged on user’s security context in order to get my shortcuts to show up. Why the opposite? It makes sense the way you explain it but it never worked for us. The run in logged on user’s security context check box is default when creating GPPs.
Thanks for this.
FYI if the logged on user has administrative privileges then the security context is with the administrative privileges and not the standard user privileges. Creator Owner will be set to Administrators and not the logged on user. A pain when creating folders with the correct permissions 🙁 Ended up excluding administrative accounts from the GPO.
Very good caveat! Thank you for posting this.
Thanks Joseph, I really have one question: are the common settings of a collection inherited by its sub-items?
Right now I used the registry wizard that imported tons of settings and depicted the registry folder structure through “sub-collections”. So now where am I putting the ”Run in Logged on User’s Security Context” setting? On the top level collection “registry wizard values”, on the registry items down below, or on all including the subfolders?
Here is what I found out through my test lab. First, I had to enable verbose logging (http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat.aspx). Next, I created a simple registy key preference that ran in the user context.
That log file had a value in it named polmkrClassUserContext that had a value of 1. This value appeared per preference. When I enabled run in logged on users security context on the collection, I no longer saw this value. The preference acted like it was not configured to run in the logged on user’s security context.
If I had to make an educated guess, enabling this on the collection does not filter down to sub-registry settings. If you have to configure this setting on a lot of preferences, let me know – I will send you a way to make mass preference changes (like this) at once.
Thanks Joseph, I just replied per email.
I would really like to know a quick way to set this on sub registry settings in a GPO. currently I am having to right click everyone and manually set or unset it. Someone suggested a direct edit of the .xml but I could not find user context =”0″