2

To get a computer to update its group memberships without rebooting the computer, you can purge kerberos tickets with the command klist -li 0x3e7 purge. A subsequent gpupdate or gpresult will reflect the new group memberships.

However, this does not seem to work on a domain controller. Why?

The tickets are purged successfully, but a subsequent gpresult /r does not reflect the changes.

Appleoddity
  • 3,860
  • 2
  • 13
  • 35

1 Answers1

1

A domain controller would fetch GPO directly from itself, over loopback SMB, and loopback SMB doesn't use Kerberos – it uses NTLM, and more specifically it uses NTLM in the special "local call" mode.

NTLM has specific handling for loopback connections – instead of doing challenge/response and then querying the directory for user details, the server process directly peeks at the security token of the client process, therefore it always sees the groups that were effective when starting that process.

The process security token is a local Windows concept and generally not something that can be cleared or reacquired on the fly – you have to restart the process (and perhaps also the process that starts the process), which means either restarting the service, (or doing a clean logout/login for interactive sessions,) or a full reboot.

u1686_grawity
  • 11,332
  • I didn't see any proof that the tickets weren't purged (before and after klist tickets). I suspect that the question is really "are the group membership updated, and how to validate". Adding groups almost certainly would result in a larger ticket, gpupdate could be a bright shiny. – Greg Askew Mar 20 '24 at 12:18
  • @GregAskew the kerberos tickets are purged and renewed. It just doesn't reflect the group membership change in group policy. So, the answer does seem to explain why that would be the case. However, to throw a wrench in the mix, I've come across at least a couple other (non-DC) servers that update some group memberships but not others - very strange. At this point, I've kind of chaulked it up to "partly" reliable. :) – Appleoddity Mar 21 '24 at 13:47
  • @Appleoddity: the simple approach would be to validate the group membership external to the group policy report. That's not needed for validation. – Greg Askew Mar 21 '24 at 13:59
  • 1
    @GregAskew you may be misinterpreting the purpose of the question, which is not provided for clarity and simplicity. Seeing the missing groups in gpresult is a symptom of the problem. The problem, as stated, is that domain controllers are not recognizing their group membership changes even though a kerberos ticket is purged and regenerated. I think the answer provided addresses the question. For your own curiosity there are other ways to check the local group membership "view" of the client such as Get-WmiObject -Namespace "root\rsop\COMPUTER" -Class RSOP_Session -Property SecurityGroups – Appleoddity Mar 22 '24 at 14:32