none
GPO taking very long time to apply

    Question

  • Hello cloud of wisdom,

    I have a stubborn Active Directory where GPOs are taking long time to apply. 

    Basically, the GPO is filtered by an AD group, and authenticated users are removed from permissions. 

    The policy applied is shown as Denied after a GPRESULT. However, after adding the user to the group it takes hours, even more han one day sometimes, to apply.

    After checking AD replication, I can confirm that the DC used by the testing workstations is having the Group membership updated, however, a simple WHOAMI /ALL does not show the user as member of group.

    It is a general problem happening to all users, not something specific of a user. 

    Any idea of where I can continue troubleshooting this?

    Thanks in advance


    http://xna-para-torpes.blogspot.com Your Spanish site about XNA !

    Wednesday, July 20, 2016 12:48 PM

Answers

  • Hi,
    Please have a try to run:
    klist purge - this will purge the existing kerberos ticket.
    klist tgt - TGT refresh, should display the ticket.

    Tools like whoami /groups will still not display the new group membership, but will if you create a new cmd window using runas since the process will be created using the updated security token.
    It may be that by launching a new cmd in this way and then running gpupdate, that this will also allow group policies targeted to any new groups to also take effect.

    TGT Refresh v TGT renewal
    Using klist in this way refreshes the TGT, and new group memberships are added.
    A TGT is renewed by default every 10 hours, but this will not add the new group memberships as it only extends the old TGT's validity. After 7 days, TGT refresh happens and the new memberships will be added.
    Regards,
    Wendy


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, July 22, 2016 2:18 AM
    Moderator

All replies

  • > adding the user to the group it takes hours, even more han one day
     
    Changing group memberships requires a logoff/logon or "klist purge" +
    Lock/unlock workstation. If you do not do so, you need to wait until the
    TGT expires (8 hours by defailt AFAIR).
     
    Wednesday, July 20, 2016 2:45 PM
  • Hi,
    I agree with Martin. It seems to be caused if you are using security group filtering for applying policy settings. The problem is that the Group Policy object you have applied to the user or computer requires security group membership to evaluate that it can apply to that computer. The group membership will have been replicated in Active Directory however the Kerberos Ticket Granting Ticket (TGT) on the local computer also needs to be updated. This TGT refresh is by default is configured to only happen every 10 hours in Active Directory.
    Performing a GPUPDATE might make the policy settings applied if the Kerberos token on the computer/user has updated since the last Group Policy Update. But, the only sure fire way to be sure that the new group membership straight away is to either log off as the user or reboot the computer to refresh the Kerberos token.
    Regards,
    Wendy

    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, July 21, 2016 7:10 AM
    Moderator
  • > adding the user to the group it takes hours, even more han one day
     
    Changing group memberships requires a logoff/logon or "klist purge" +
    Lock/unlock workstation. If you do not do so, you need to wait until the
    TGT expires (8 hours by defailt AFAIR).
     

    Hello Martin,

    yeah we have restarted several times, but still the Kerberos token does not show that group membership (using whoami /all).

    I do not know what else to check.

    Logon seems to work fine, GPOs seem to work fine (just this in particular appears denied for permissions), but still is not able to get a simple group membership.

    Any idea?

    Regards,



    http://xna-para-torpes.blogspot.com Your Spanish site about XNA !

    Thursday, July 21, 2016 7:54 AM
  • Hi,
    I agree with Martin. It seems to be caused if you are using security group filtering for applying policy settings. The problem is that the Group Policy object you have applied to the user or computer requires security group membership to evaluate that it can apply to that computer. The group membership will have been replicated in Active Directory however the Kerberos Ticket Granting Ticket (TGT) on the local computer also needs to be updated. This TGT refresh is by default is configured to only happen every 10 hours in Active Directory.
    Performing a GPUPDATE might make the policy settings applied if the Kerberos token on the computer/user has updated since the last Group Policy Update. But, the only sure fire way to be sure that the new group membership straight away is to either log off as the user or reboot the computer to refresh the Kerberos token.
    Regards,
    Wendy

    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Hello Wendy, we have actually restarted the workstaions several times, and it is happening on multiple computers. 

    It is really strange that the logon does not get the group membership properly from the Active Directory, even when we have confirmed that the DC that is serving the logon has the groups updated. 

    Best regards,


    http://xna-para-torpes.blogspot.com Your Spanish site about XNA !

    Thursday, July 21, 2016 7:59 AM
  • Hi,
    Please have a try to run:
    klist purge - this will purge the existing kerberos ticket.
    klist tgt - TGT refresh, should display the ticket.

    Tools like whoami /groups will still not display the new group membership, but will if you create a new cmd window using runas since the process will be created using the updated security token.
    It may be that by launching a new cmd in this way and then running gpupdate, that this will also allow group policies targeted to any new groups to also take effect.

    TGT Refresh v TGT renewal
    Using klist in this way refreshes the TGT, and new group memberships are added.
    A TGT is renewed by default every 10 hours, but this will not add the new group memberships as it only extends the old TGT's validity. After 7 days, TGT refresh happens and the new memberships will be added.
    Regards,
    Wendy


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, July 22, 2016 2:18 AM
    Moderator
  • Hello Wendy,

    thanks for the insights on how all the Kerberos process works underneath, but it does not help to solve the issue, that is happening in pretty much all workstations.

    A simple logoff/logon should refresh the Kerberos token including the news groups, and therefore the user being able to access all all the resources the groups has permissions on.

    I am going to tell the customer to open a ticket directly with support to see if they are able to investigate and solve the issue.

    Thanks anyway for your help!


    http://xna-para-torpes.blogspot.com Your Spanish site about XNA !

    Friday, July 29, 2016 9:07 AM
  • Hi Mihe,

    Did you got any fix for this? I am facing similar issue. the GPOs i push take a long day to reflect on computers.

    Thanks

    RM

    Wednesday, July 11, 2018 11:36 AM