none
GP with Security Filtering on Computer Group not working

    Question

  • In my Windows Server 2012 R2 domain, I'm trying to exclude a computer group from having to enter a password after the screensaver kicks in.

    Here's my AD:

    Domain
    |- Users
    |- Workstations
        |- Security Group A
            |- Computer A

    In case it's not clear, the Workstations OU contains all the computers. Computer A is a member of Security Group A.

    At the Domain level, I've applied a GP to set screensavers with password protect (working). At the Workstations OU, I've enabled GP which enables loopback, filtered for Group A only (working). Also at the Workstations OU, I've set a GP to disable the password protect for screensavers, filtered for Group A only (not working).

    GPRESULTS show that the computer is applying all the GPs except the last. It will work if I apply it to Authenticated Users, but not if I filter it for just Group A.

    Can someone please advise me on where I'm going wrong? I've already tried to restart the computer.

    Tuesday, July 07, 2015 6:18 AM

Answers

  • Dear Martin & Lain, sorry for the delay in replying. Thanks for answering my question.

    Sadly, I'm stuck with XP for my test machine, but I finally figured out the problem. It seems that Group A also has to contain Authenticated Users. I'm guessing it's because the GP I'm applying there is for User Settings, and all the users are in a separate OU entirely.

    Dear Martin, yes, loopback certainly is a pain. If I had to create anything more extensive than this, I'd definitely use your suggestion.

    • Marked as answer by MFX Gin Friday, July 10, 2015 6:58 AM
    Friday, July 10, 2015 6:57 AM

All replies

  • Hi MFX Gin,

    I'm not sure what client operating system version you're running, but if I assume it's Windows 7 or later then if you run gpresult using the /h switch, you'll get a Html report which will tell you why the policy was not applied. It may help as a starting point to know what reason it gives.

    Based on what you've provided so far, I can't see a reason it wouldn't be applying. So long as the computer has the ability to Read and Apply the GPO, it should be applying. All I can suggest verifying is that you haven't accidentally missed one of those rights either directly or indirectly (i.e. you could leave Authenticated Users as Read and then select Apply for "Group A" which would result in the computer getting both the required Read and Apply rights.)

    Assuming the Html file isn't particular illuminating, you can take a look at the Applications and Service Logs/Microsoft/Windows/GroupPolicy/Operational node within Event Viewer for more detailed information.

    Cheers,
    Lain

    Tuesday, July 07, 2015 7:05 AM
  • Have a look at
     
    I think that using GPP Item Level Targeting is much smarter than using
    Loopback, because Loopback almost always imposes unwanted side effects :)
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Tuesday, July 07, 2015 2:40 PM
  • Dear Martin & Lain, sorry for the delay in replying. Thanks for answering my question.

    Sadly, I'm stuck with XP for my test machine, but I finally figured out the problem. It seems that Group A also has to contain Authenticated Users. I'm guessing it's because the GP I'm applying there is for User Settings, and all the users are in a separate OU entirely.

    Dear Martin, yes, loopback certainly is a pain. If I had to create anything more extensive than this, I'd definitely use your suggestion.

    • Marked as answer by MFX Gin Friday, July 10, 2015 6:58 AM
    Friday, July 10, 2015 6:57 AM