• State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 62 subscribers
  • Views 15113 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Access template permissions after group add/removal

michael.otis
over 7 years ago

We're working on implementing ARS 7.0 (clean install) after having 6.9 for quite awhile. We've kind of hit a snag with our elevated permissions.

 

We have workstation support that uses temporal membership to "elevate" themselves into a group that gives them permissions to read LAPS/Bitlocker Keys, etc. I can either elevate or put myself into that elevated group that has an access template assigned to it to allow the users to perform these tasks but the permissions never get applied.

The only way for the permissions to be applied are to restart the ARS Administration Service, after doing that, I am able to read the LAPS/Bitlocker Keys, etc.

This worked flawlessly in 6.9, maybe sometimes it took a minute or two for the permissions to apply but that's it.

 

Any ideas?

Parents
  • 0 over 7 years ago

    Hi,

    I still tend to agree with Johnny's first reply here; I believe you when you say this worked OK before, but with what I know, I would expect the new scenario to be the expected behavior when there are group membership changes involved.

    If you logon to a Windows machine, it builds your Kerberos token with all group memberships in there. If group memberships are changed while you are already logged on, those changes won't be applied until you logoff/reboot or wait for a long time (~12 hours).

    If you are accessing AR via Web/MMC, this would mean that your new permissions resulting from the newly added group would not kick in until you have logged in to your computer again. You can test to see if this is the problem by:

    1) Logging on to a PC
    2) Adding yourself to the group
    3) Waiting a few mins for AD replication
    4) Run 1 of these 2 DOS commands (or both :)
    klist purge
    klist tgt
    5) This will clear your Kereberos token and force it to be recreated
    6) Test AR access - if it works now OK, the behavior is by design - changes to groupmembers won't have any effect until you refresh the token (also counts for group removals!!)

Reply
  • 0 over 7 years ago

    Hi,

    I still tend to agree with Johnny's first reply here; I believe you when you say this worked OK before, but with what I know, I would expect the new scenario to be the expected behavior when there are group membership changes involved.

    If you logon to a Windows machine, it builds your Kerberos token with all group memberships in there. If group memberships are changed while you are already logged on, those changes won't be applied until you logoff/reboot or wait for a long time (~12 hours).

    If you are accessing AR via Web/MMC, this would mean that your new permissions resulting from the newly added group would not kick in until you have logged in to your computer again. You can test to see if this is the problem by:

    1) Logging on to a PC
    2) Adding yourself to the group
    3) Waiting a few mins for AD replication
    4) Run 1 of these 2 DOS commands (or both :)
    klist purge
    klist tgt
    5) This will clear your Kereberos token and force it to be recreated
    6) Test AR access - if it works now OK, the behavior is by design - changes to groupmembers won't have any effect until you refresh the token (also counts for group removals!!)

Children
No Data