Windows 10: Cannot Get GPO Policies Adopted By User

C--Z · Jun 13, 2020

I'm trying to learn a few things about Windows Server and Active Directory. I've fiddled with this in the past and had pretty good luck with deploying policies, etc. I've set up an instance of Windows Server 2016 Standard and a Windows 10 Pro workstation.

I set up a GPO named RDPTestPolicyGroup.

I created a user called "ad user." This user is part of the group RDPTestPolicyGroup. I can see this under AD User Properties > Member Of.

In AD Users and Computers I see RDPTestPolicyGroup and for Members I see Ad User. The Group scope for this is "Global" while the Group type is "Security."

When looking at Group Policy Management, I can see under Forest:RDPTest.local\Domains\RDPTest.local\Group Policy Objects\RDPTestPolicy\Security Filtering I have "Authenticated Users" and "RDPTestPolicyGroup." Under Delegation I see that RDPTestPolicyGroup is set to "Read" under Allowed Permissions and "Inherited" is set to "no."

When on the workstation, which is joined to the domain, and logged in as ADUser, when I run:

GPResult /Scope User /v

Under "The user is part of the following security groups" I can see that the user is part of the RDPTestPolicyGroup but none of the policies that this group should be enforcing on the workstation are in effect. The policies that I set are "Enable Screen Saver = Enabled" and "Screen saver timeout = Enabled @ 60 seconds.

I've run GPUpdate /force

I've rebooted and let the PC sit there for a few hours to see if the policy would take; it does not.

So I don't think I've properly linked the GPO to the group. I'm not sure what is missing.

HELP!

:)

jflanagan · Jun 13, 2020

GPOs linked to user OUs not appearing in Results Wizard

Hello, I'm noticing an issue in my domain where GPOs linked to user OUs are not being applied and not even appearing in the Group Policy Results Wizard report (neither under Applied GPO's nor Denied GPO's, like they don't exist at all).

A few clues:

I did recently release June Windows updates including MS16-072. However, I was aware of the security processing change and all the related GPO's already had "Authenticated Users" with Read and Apply permission. I added "Domain Computers" to one GPO as a
test but no luck.

So far, issue is appearing on Windows 10 computers only. Computers are correctly processing GPO's linked to the computer's OU/hierarchy. A GPO containing loopback-processed user settings does appear under the user settings in the Results wizard, but that
GPO is linked to a "computers" OU.

If I link a "user" GPO to a "computers" OU, it appears in the Results Wizard under user settings. However, this is a drastic change in behavior and will interfere with desired outcomes such as a user having drives mapped to their department's files regardless
of which computer they use.

Please advise, do I need to adjust some setting in Windows 10 to restore processing of GPO's linked to user OU's?

Thanks in advance for any assistance.

Brink · Jun 13, 2020

Who broke my user GPOs?
Hi folks. From Orlando, Florida, Sean Greenbaum here with some news about a recent set of security patches released on June 14, 2016. If you’re reading this, chances are you are having group policy issues, or you heard this patch will cause you to have issues and you want to get ahead of it. So, without further ado.

What did I miss.

We released new security patches for all currently supported Operating Systems. Among those patches was this one: MS 16-072, which is also referenced as KB 3163622. OS Specific articles are released as 3159398, 3163017, 3163018, and 3163016.

KB 3159398 – Vista, 2008, 7, 2008 R2, 2012, 8.1, 2012 R2
KB 3163017 – Windows 10 TH1
KB 3163018 – Windows 10 TH2 and Server 2016 TP4
KB 3163016 – Server 2016 TP5

After applying the appropriate patch to your systems, User group policies are retrieved from SYSVOL differently than before. Prior to the update, domain joined computers used the user’s security context to make the connection and retrieve the policies. After the update is applied, domain joined computers will now retrieve all policies using the computer security context. The users that get the policy is still controlled by the policy scope just like before. The only change is the computer is getting the policy for the user.

For group policies with the default permissions, this isn’t an issue. By default, “Authenticated Users” has Read permissions to all group policies when they are created.

But, why did you do that?

Well, it’s complicated. Insiders tell me (and by insiders I mean the very first link I supplied you with above) that this was done to prevent a possible Man-in-the-middle (MiTM) attack between the PC and the DC. Using the computer account helps mitigate this by enforcing the use of Kerberos.

Learn something new

Before I go too far, let’s make something clear. There is a difference between Group Policy scope and Group Policy permissions. The Scope is who can apply the GPO. The permissions control who can read, write, delete, or modify the permissions of a policy. These permissions are stored on the delegation tab of each policy. We are going to be focusing the rest of this article on the Delegation tab.

Let’s also make something else clear. For a policy that is scoped to Computer accounts, there is no functional change. In order for the computer to apply the policy, it needs read and apply permissions to the policy. By scoping a policy to apply to a certain group, that group automatically gets Read permissions. This functionality has not changed at all.

But for User policies, the ones that are scoped to a subset of your users, that’s where the issue is. This is a fairly common configuration for user policies, so there is great potential for problems here.

A default GPO looks like this.

As long as “Authenticated Users” has Read permissions, group policy application will continue to work after applying MS16-072 / KB 3163622. That’s because Computers are “Authenticated Users” too. Therefore, the computer that this user is logging on to has read permissions to this GPO already through “Authenticated Users”.

GPOs can be scoped to apply to a smaller audience than “Authenticated Users”. What happens if I scope this GPO down to an AD security group (or individual users) instead of “Authenticated Users”?

On the Scope tab, you typically remove “Authenticated Users” and add your own users or security group(s), populate it with users and go about your day. Like so:

Back on the delegation tab you see this:

As you can see, your user account has read permissions to the GPO through the AD Group “User Group 1”, but “Authenticated Users” is gone. That’s no longer enough permission after installing MS16-072. Since the computer account is now used to retrieve the policy, it needs Read access to the policy in order to retrieve it from SYSVOL and hand it off to the user for processing. As you can see, your computer account isn’t a member of any of these default groups.

Since I want this policy to apply to this user regardless of what computer they log on to, I need to add either “Authenticated Users” or “Domain Computers” to be able to Read this GPO as well. Here I’ve added “Domain Computers”.

If you look closely here, you’ll see “Domain Computers” has Read permissions. “User Group 1” has “Read (from Security Filtering)” permissions. That’s how you can tell User Group 1 is security filtered to apply this GPO from the Scope tab, and Domain Computers just has Read and not Apply permissions.

You: Well great. Now I have to go through each GPO and add the computers to have Read permissions. Right?
Me: Yep.

You: Well, I have hundreds of group policies. That’s going to take forever. Is there a way I can do this quickly?
Me: Yes there is. PowerShell to the rescue.

…but first….

Decisions, Decisions

Here you have some options on how to proceed, and you have to make a decision on which strategy is the best for you. The official guidance from Microsoft is to ensure the computer accounts have “Read” access to the user policies you wish to have applied. This can be done several different ways.

Strategy 1: Add “Authenticated Users” to each of your user policies. This is certainly the easiest method as it ensures that all authenticated computers and user accounts can read the settings in the policies. This works regardless of what domain, forest or trust they come from, as long as the local domain is able to authenticate it. However, it does grant all user accounts the ability to read the policy (Note: Not apply the policy, just read the settings contained in it.)

Strategy 2: Add “Domain Computers” to each of your user policies. Using “Domain Computers” will grant all member computer object the ability to read the GPOs, without also including user accounts. It too isn’t without its gotchas though:
Note: By default, when a computer is joined to the domain, it is automatically added to the “Domain Computers” AD security group. If you manually manage the membership of this group, then it’s possible “Domain Computers” won’t have a complete membership of all of your computer accounts.

Note: Remember that “Domain Computers” is exactly that – the computers in your current domain. If you have multiple domains, or trusts, and if you cross link any GPOs across those boundaries, you will also need to add the other domains “Domain Computers” group to the policies as well.
Strategy 3: Use your own custom groups. If you would like to granulize exactly which computers the user policy is able to be applied to, you will want to have your own custom AD security groups populated with those computer accounts.

As my lab is a single forest, single domain with no trusts, I’ve chosen to use “Domain Computers” for the rest of this article. Any PowerShell code or step by step instructions are the same whether you use “Authenticated Users”, “Domain Computers” or your own custom groups. Simply replace any instance where I use “Domain Computers” with the group you are intending to use.

Ok, I’m ready. Let’s fix it.

Great. Now that you’ve chosen a strategy that works for you, let’s begin.

Option 1: The “Just fix it already” option

Very simple and straight forward. Get a list of all the GPOs in the domain, and add “Domain Computers” to have read permissions. This script doesn’t distinguish between user policies, computer policies, scoped, not scoped.

Code:
Code:
$gpos = get-gpo -all foreach ($gpo in $gpos) {  Set-GPPermissions -Name $gpo.DisplayName -PermissionLevel GpoRead -TargetName “Domain Computers” -TargetType Group }
That’s it! You’ve just added the “Domain Computers” group for the current domain to have GPORead permissions on all your GPOs currently in the domain. If you have other domains and are cross linking GPOs to the other domains, don’t forget to add the “Domain Computers” groups for those domains as well.

Option 2: I want to be more detailed than that. Can I get a list of all the GPOs that need my attention?

Of course. In fact, our product group published this very fine script here. This script searches for GPOs that are missing the “Authenticated Users” permissions, and prompts you to automatically fix them. Looking at the code, you could easily adjust this to use “Domain Computers” or whatever group you find appropriate in your environment.

Option 3: I prefer the personal touch with my policies

That’s the same way I prefer my fresh home baked cookies. No machinery or automation here. Start from the Delegation tab of the policy. Click Add, find the group, and make sure the permissions are Read. Easy. Now do that for each user policy.

Option 4: AGPM! Wait, I have AGPM!

AGPM (Advanced Group Policy Management)

If you already use AGPM to manage your policies, you can use the Production Delegation tab in AGPM to update the security on any GPOs you deploy going forward. See the AGPM section below for details.

Ok I fixed it, so I’m done right?

Temporarily. Our group policy tools GPMC and AGPM will continue to create GPOs using the default permissions I showed at the beginning of this article. As you create new user GPOs, and you scope them to specific user groups, you’ll need to continue to remember to add the appropriate groups to those GPOs before it can be processed.

If you are using a 3rd party tool to create and manage your GPOs, you’ll want to reach out to that vendor to see how their product is affected and if any change is needed to your policy creation and deploy process.

Remember: If you didn’t use “Authenticated Users” and you add additional domains to your forest, and if you are cross-linking GPOs between domains in your forest (the GPO exists in Domain1 and is linked to OUs in Domain2), be sure to remember you will need to grant the new domains “Domain Computers” or your custom group to the policy before it will have access in the new domain.

Do you use Deny:Read permissions on some of your GPOs? Read this.

When you grant the computer the ability to Read the GPOs, if your user account is in a group that grants apply rights, and in a group that denies read rights, previous to MS16-072 the user would not get the policy. Since the Read is now done by the computer context, there is a possibility that the user will now get the GPO when that is not your intention.

To fix this, update the permissions on any GPO where you are doing Deny:Read to also include Deny:Apply.

Using AGPM? Look here for some important information

Once you’ve installed the patches for MS16-072, if you are using AGPM you’ll want to make some changes here as well.

First, very important, make sure you reimport your GPOs into the AGPM database. Trust me, do this. We’ve already received reports from customers that did NOT do this step, and it caused some serious problems when they went to deploy later. This makes sure we have the latest copy of the production GPOs. Do it. Right now. I’ll wait.

All reimported? Good.

Now that you’ve reimported your GPOs in AGPM, lets configure AGPM so that it knows of the new permissions and deploys the correct security settings going forward.

From the AGPM module, select the Production Delegation tab. We need to grant “Domain Computers” Read permissions.

Only grant Read permissions.

Confirm the settings.

Now that the delegation settings are correct, redeploy your GPOs. This will make sure the permissions apply. Select all the GPOs you need, right click and Deploy.

Boom. Victory! We see that “Domain Computers” is here, “User Group 1” is the group that is scoped to apply these settings, and “User Group 2” is the group we specifically Denied Read and Apply permissions earlier.

One more thing

We also released MS16-075 / KB 3161561 in June 2016 to patch some SMB items. SYSVOL and Netlogon use SMB. There have been reports of users getting Access Denied when trying to access \\domain.fqdn\sysvol or \\domain\sysvol.

If you are experiencing this error, the current workaround is to set the SmbServerNameHardeningLevel registry value to 0 on the DCs. It is not needed on the other servers. If you experience this issue on other DFS servers, see the KB for the updated workaround info for those servers. Specifics are detailed in the KB 3161561 article.

More Info

Our Directory Services team has also published information about this update on their blog. If you have any questions, be sure to check there too.

Until next time,

Sean Greenbaum

Premier Field Engineer, Secure Infrastructure
Click to expand...
Source: Who broke my user GPOs? | Ask Premier Field Engineering (PFE) Platforms

Harvard James III · Jun 13, 2020

Delete user profile after x days GPO for Win10

Computer Configuration -> Policies -> Administrative Templates -> System -> User Profiles

"Delete user profiles older than a specified number of days on system restart"

This GPO is supposed to delete any user profile older than x amount of days but fails to do so because my antivirus will run a scan on the profile and update the "last modified" property. Apparently there's a KB(983544) that fixes this issue in Windows
7 but it's not compatible with Windows 10. Any help with this would be greatly appreciated!

Windows 10: Cannot Get GPO Policies Adopted By User

Cannot Get GPO Policies Adopted By User

Cannot Get GPO Policies Adopted By User

Cannot Get GPO Policies Adopted By User

Cannot Get GPO Policies Adopted By User - Similar Threads - Cannot GPO Policies

Errors while reading policies from this GPO, not all policies are displayed

Errors while reading policies from this GPO, not all policies are displayed

Errors while reading policies from this GPO, not all policies are displayed

user config GPO linked to computer OU but not apply to all computer altough they get the policy

user config GPO linked to computer OU but not apply to all computer altough they get the policy

Active Directory Group Policy Objects GPO

Active Directory Group Policy Objects GPO

Microsoft edge - default settings users can override GPO policy is not working

Screwed up with GPO, now it cannot apply the "AppV" & "UEV" Policy.