1

Hi all,

This afternoon has been driving me absolutely mad and i’ve been Googling all over the shop for a resolution but to no avail.

The company I work for has department group policies setup authenticated against security groups which will configure a mapped share to appear in the users Computer window.

My problem is, I have one machine that just will not apply any of these mapped drive group policies for any user.
The issue isn’t user specific because if I move to another machine it works absolutely fine. All my shares and others are present!

The GPO is only applying to the security groups which have the individuals within them. It works fine across the rest of our estate.

Performing a GPRESULT will show that the policy (which is displayed as the policy guid) has an inaccessible status.

The machine and my account can access the shares manually, and i could manually map the drive, but that’s not what I really want to do.

It’s really baffled me as to why one machine cannot have these GPO’s applied when it’s not a computer GPO.
Oh and the one computer that it does work on and the one that doesn’t, both reside in the same Device OU.

The only thing about this new (not really new) machine is that it was recently re-imaged. Could I be checking anything on the machine in the meantime?

Thanks

4 Spice ups
2

You should reintegrate that machine into the domain. Then do a gpupdate /force to rerun the policies.

Move it to a workgroup, reboot. Delete the device name from Active Directory, integrate the device into Active Directory, move it to the correct Organizational Unit, then do the gpupdate /force on the machine.

Side note, if the GPO is only for Computer Configuration, you could do a gpupdate /target:computer /force to bypass the User Configuration and cut out like 10 seconds. I usually just do gpupdate /force cause it gets both configs.

2 Spice ups
3

Will give that a try tomorrow. Cheers

1 Spice up
4

This kinda sounds like an issue I ran into recently. I had security filtering on a GPO locked down to a specific security group. But for some reason, the GPO wouldn’t apply. I was baffled. It turns out, a Microsoft update has changed the way it works, so you now have to add ‘Authenticated Users’ to be able to at least ‘Read’ the GPO (via the Delegation tab). Check it out here: MS16-072: Security update for Group Policy: June 14, 2016 - Microsoft Support

1 Spice up
5

Interesting. Will certainly give that a try first as its the easiest solution. We do use wsus so I’m not sure if this is across the estate. It might be though and I assume it only affects users that have never logged onto the machine before.

6

Indeed, KB3159398 is the most likely culprit. You are reciting just about every symptoms caused by KB3159398. It fundamentally changed how User configuration group policies are processed. It sounds like the updated got applied to one computer only.

If this is the case, it would affect any user settings for any user on any computer with the update applied when Security Filtering is used. Even if it is not the problem, Best Practice has always stated that “Authenticated users” should have the Allow: Read permission as mikemike pointed out.

Because the computer has no READ access to the user’s GPO (which, post-update is required), so you get “inaccessible”. Permissions on the actual resource are not a problem.

It’s really baffled me as to why one machine cannot have these GPO’s applied when it’s not a computer GPO.
Oh and the one computer that it does work on and the one that doesn’t, both reside in the same Device OU

MS16-072: Security update for Group Policy: June 14, 2016 - Microsoft Support

Because the one where drive mappings don’t work was recently re-imaged, either the image contained all of the recent updates, or after imaging and before joining it to the domain, all available updates were applied.

Kinda surprised that this didn’t come up in any of your googling, this was kinda a big deal last month.

7

Is it a re-imaged machine using the previous machine name?

That means a new PC, with a new SID with an old name. Your User GPOs are probably whats working and your Computer GPOs may not be.

If you connect to this machine via rdp/name you probably want to do ipconfig /flushdns on your pc as well.

8

I’m remoted onto our AD now to start making the changes (although I can’t remote onto the problematic machine). How would I go about adding RO permissions for authenticated users on this GPO?

I assume it needs adding to the GPO, or does Authenticated users need adding to the security group with RO permissions?

Thanks

9

From Group Policy Management Console

Highlight the GPO, in the “Delegation” tab, click “Add” near the bottom left, then use either the troubled computer object, authenticated users or “domain computers” (which is my preference), click OK, then select “Read” and click OK.

You delegate read permissions on the GPO, do NOT add authenticated users to the group.

10

If you can’t remote in, its probably because there is a DNS issue as well. If you want to remote in, use its IP address, or flush your DNS cache on your workstation.

You add the RO permission in the Delegation tab of the GPO

11

Or, you can run this and it will add the appropriate permissions on all GPOs.

Get-GPO -All | % {Set-GPPermissions -Guid $_.Id -TargetName "Authenticated Users" -TargetType Group -PermissionLevel GpoRead}
12

I’ve done the delegation one instead :wink:

Only reason why I can’t remote to the machine is it’s either in sleep mode or it’s off. It is a laptop. I know it’s still physically connected to the network though.

Will just have to see tomorrow morning.

P.S. whats the difference with the delegation and scope security filtering?

13

I think it’s sorted, I remember I had this issue on my Windows 10 machine and in the end just manually added the mapped drives.

Now i’ve added it they’re auto changing the description to the GPO and including the used/available drive space.

Thanks a bunch all!

14

Well, the security filter is kinda a subset of delegation; an entry in the security filter will Delegate an Allow: GPO Read & Apply to the security principal in the filter. It can only be used to restrict the target of the GPO.

Delegation (as you’ve seen) is a view into all of the permissions of a GPO, in addition to changing to whom it can be applied; it also can control who can modify the policy, who can change where if the GPO is linked, etc. Its a fancier version of the security tab on the entire GPO, not just whether or not it applies.

15

Starting to make sense now.

You mentioned using Domain Computers (which is your preferred method), but whats the difference between this and Authenticated Users? I’ve set it as Authenticated users for now.

16

Authenticated Users = an AD account that has authenticated (with a password) and logged on. This means all logged on computers (because they have a password, too), and any logged on user with a password (because you can have users without passwords)

Domain Computers = uh, Domain Computers, generally every computer, though it can be modified from time to time.

My preference is for the latter, strictly because computers (who are now the security principal used to pull the GPO for user processing) absolutely requires Read access to all GPOs to process them. A user does not need to be able to read all GPOs in the domain. The way I see it, using Domain Computers here more closely adheres to the principle of least privilege than does granting read access to Authenticated Users. However, Microsoft’s best practice does state “Authenticated Users” is appropriate.

17

Just a quick update, got into work today and it all worked! Thanks for the help guys!