1

I am having some trouble getting the results I want when it comes to rolling out a new policy. Let me see if I can explain this clearly.

  1. I have a user policy i want applied to all users who log on to a certain subset of computers.
  2. The company currently has two OU’s. One for the Computers, and one for the Users.
  3. The Policy is currently linked to the OU containing the computers.

I placed the computers I wanted to apply the policy to into a security group and then limited the security filtering to just that group of computers. I also enabled policy loopback, but since I removed :Authenticated Users from the security filtering, it does not get applied to the users that log into the computer. If I enable Authenticated users, it gets applied to all the users regardless of the computer they log on at.

I know I am doing something wrong somewhere and have been rattling my brain all day on this, any help is appreciated. Do I need to reconfigure my OU structure to make this happen? Should I put the specific computers in their own OU within the computer OU instead of a security group?

4 Spice ups
2

You cant have only applied the GPO to the OU that has computers in if you say that users get the GPO applied to them no matter which computer they log on to when you add Authenticated Users to the security filtering…

3

Open a command prompt and type the command GPRESULT as this often gives clues whether the policy is being filtered out.

I had more or less the same pain this year with a selective policy and in the end, I ensured the Users were split into OU’s and applied the policy to the OU they were in and left in Authenticated Users.

4

I think the way I am going to have to do it is split the computers I want to apply the policy to into their own OU. Trying to filter by security group is just too big a hassle.

5

I don’t think its the computers that are the issue, its the Users.

6

If I separate out the computers that need the policy into their own OU, apply the policy to that OU, and set the security filtering to Authenticated users it works. I was just trying to find a way to use do it without separating the computers into their own OU.

7

You may need to split it into two policies. Even with Loopback processing enabled, you’re still trying to set user configuration settings.

In the first policy, configure your user settings, and configure Security Filtering for Authenticated Users

In the second policy, configure Loopback Processing, and configure Security Filtering for the group you created with the computers in it

Since your applying these policy to the OU with the computers in it, the user configuration setting will not affect any other computer except the ones in the security group

8

OK I finally figured out what I was doing wrong…

“Authenticated Users” includes both users AND computers. My policy is linked to the Computers OU and security filtering is now set to the security group of computers I want to target, as well as “Domain Users”. Group Policy Loopback for the policy is also enabled.

In addition, I was mainly using Policy Modeling in GPMC to see how this policy would be applied. Evidently this does not handle modeling loopback policies very well and was processing the user portion of the loopback policy even though the machine portion got denied.

gpresult was also giving me some erroneous information because I had not rebooted my computer in a while and had changed my computer’s security group.

1 Spice up
9

I have run into a similar scenario, currently, below is my workaround; although, interestingly it does not happen for all of our departments:

  1. Machines are in a separate OU from users.
  2. Users are in a dedicated OU structure managed by our provisioning system.
  3. I apply a loopback GPO using “replace” mode with the user configuration having mapped drives under the “Preferences->Windows Settings” area to the machines OU.
  4. I have a security group with all of the users in “Security Filtering”.
  5. I then just add “domain computers” as an additional group in “Security Filtering”.
  6. Done.

If I add “Authenticated Users” my policies work as well, but obviously it is applied to any user logging in. So, explicitly adding a “custom security group” and “Domain Computers” takes care of addressing my customized settings for specific users.

I am currently working with another tech to see if we can figure out what might be causing issues in our VLANs, since the setting works in other VLANs. I will do my best to reply with an update.

Hopefully, this helps someone!

10

As promised, I wanted to follow-up just in case we got our loopback processing working with just user groups in the “Security Filtering” as an entry. We did!!!

First, the configuration that resolved our issue:

  1. Loopback processing in “Replace Mode”.

  2. Security group with the user that will receive the drive mapping(s) is the only entry under the “Scope” tab in the “Security Filtering” ACL.

  3. The drive mapping “Action” set to “Replace” versus update, if there is an existing manual mapping pointing to the same drive letter the “Update” action doesn’t always apply. I believe there is another thread that talks about this too on Spiceworks.

  4. When editing the GPO and looking at the drive mapping configuration itself, under the “Common” tab, make sure that “Run in logged-on user’s security context (user policy option)” is unchecked, see below for screenshot:

    loopback_processing_settings.jpg
    loopback_processing_settings.jpg800×648 154 KB

  5. Lastly, we found issues with the test client we were working with not having the correct DNS configuration in TCP/IP settings.

  6. We had recently migrated the client to another domain and its DNS search order list was still pointing to the old domain controllers.

  7. We pointed the client to our campus DNS root servers. Our DNS root servers have a delegated zone which points to our target (newly joined) domain.

  8. To do some deep dive troubleshooting we used netlogon debug mode, which generates a log file in “C:\Windows\Debug\netlogon.log”. Used the following MS article: Enable debug logging for Netlogon service - Windows Client | Microsoft Learn

  9. The log indicated that the machine’s FQDN or hostname could not be properly resolved on the new domain, which pointed us to check TCP/IP settings and thus we made the changes up above.

  10. Ran a gpupdate /force as admin, so that machine policies would be refreshed along with user policies and rebooted the machine.

  11. Logged in as the user and verified the drive mappings corresponding to the security group the user was in mapped correctly.

Some errors not related to this issue in event viewer under the “System” log:

  1. EventID 5719: This issue is posted, but if you are able to log-in to the machine with no issues, you can ignore this issue.

Resolution: Now we do not need to include “Domain Computers” domain security group in the “Scope” tab under “Security Filtering” for the GPO. Lesson, make sure that your DNS resolution to all of your DCs is working correctly, especially, like in our case, if you are migrating machines to a different domain. DNS is critical to any Domain Services.

Not really related to this, but a change we made as well, which could have had an impact, since we don’t support it, yet. We went into the registry and disabled IPv6. Doing so, in the TCP/IP GUI, does not actually completely disable IPv6.

Hopefully, this helps someone!