I recently had to investigate an issue with group policy where a GPO was not being applied when a user logged on, even though it was linked to the root OU (see below):
Root OU ---- Computer OU
|----- User OU
Loopback processing was enabled on the Computer OU in merge mode.
My reading led me to find the following information:
https://blogs.technet.microsoft.com/askds/2013/02/08/circle-back-to-loo…
https://blogs.technet.microsoft.com/askds/2013/05/21/back-to-the-loopba…
The first thing I discovered is that if loopback processing is enabled in replace mode, the GPOs that would normally apply to the user are ignored completely. This was not relevant in my case since we are using merge mode, but still interesting.
The second thing I discovered is that in order for a GPO to apply in loopback merge mode, it must be set to apply to the user in the security/WMI filtering, but the computer account (or domain computers) must be granted read access in the delegation tab. Note: This would be achieved by adding the computer account to the security filtering, but that is not actually required. Note2: In loopback replace mode, the computer account does not require any permissions.
The unusual thing in my case is that the GPO should have been applied to the user before the merge, and loopback processing should not have come into play, however I can only assume that because the GPO was linked to an OU that was common to both the computer account and the user account, it was being ignored at the user level, and it needed the computer account to be granted read access so it could apply in the loopback processing.