• State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 62 subscribers
  • Views 15108 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?

  • 0 over 7 years ago

    If you put yourself into a group, you need to re-login to Windows in order for that group membership to be attached to your token so that AR can then re-evaluate your permissions.  But you probably know that already.

    I'm not sure I understand the first part of your comment:

    "I can either elevate or put myself into that elevated group"

    How else do you "elevate" yourself - do you mean through "Run As Administrator" or some such?

  • 0 over 7 years ago
    No, the process has nothing to do with Windows.

    We have access templates assigned to certain groups that allow the users to read or write certain information in AD through ARS.

    In 6.9, a user could temporarily (temporal membership) elevate themselves into one of these privileged groups and they would instantly be able to read/write AD attributes because of the access template being applied.

    That no longer works in 7.0.3, if a user is put into a group that has an access template applied to that group, the permissions from the access template are not applied, not even if the user logs out and back in. The permissions only apply if the ARS Administration Service is restarted.

    So for example:

    A group called Workstation Support has an access template applied to it for a certain OU that allows users of that group to read LAPS and bitlocker recovery keys from computer objects.

    To begin, I'm not apart of the group Workstation Support but I get added to that group through temporal membership or manual addition.

    In 6.9, I would instantly be able to read those values through ARS.

    In 7.0.3, I am not.
  • 0 over 7 years ago
    I see what you're saying. If this is consistently reproducible behavior, I would suggest that a Support ticket is in order.
  • 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!!)

  • 0 over 7 years ago
    This has nothing to do with security tokens because we're not talking about people using these groups in an active environment. It's an issue with the web interface and ARS checking group membership to apply an access template IN ARS, not in AD, to view AD information. It has nothing to do with actual machines, just displaying AD information about those machines.
  • 0 over 7 years ago

    Correct. ARS uses user token logged in to ARS ADmin Service.
     (a) ARS is "resourceA" accessed by Window user (windows token).
     (b) ARS “proxy” grants accessed user to access another “resourceB” Managed AD domain.
     All rules how ARS can see group membership (cross-domain, resource domain, caller domain groups) inside the binded token (a) and “on behalf” to “resource2” (b) follows standard Windows / AD group membership resolution rules.
    (it is the factor to design cross-domain management at ARS deployment)

  • 0 over 7 years ago
    In our previous installation we had an admin domain where ARS resided and managed the production domain, in this domain we have ARS in the production domain managing the production domain, you think that's the cause?
  • 0 over 7 years ago

    Unfortunately, I cannot comment on the details of your deployment. I tried to raise a general concerns and direction of investigation of the problem.
    Single domain scenario (ARS, delegation users/groups, the Managed Domain all reside in the single domain) is the simplest (eliminates all mentioned concerns).
    Example: Does subnet in AD configured correctly, so ARS ADmin service gets AD data from the closest DC (not over ocean by mistake)?

  • 0 over 7 years ago
    It's an interesting point that Aidar raises which alludes to potential AD replication latency around the group membership changes.

    If you look at the 7.x Admin service event log, event id 1010 will tell you which DCs the service is currently talking to for each managed domain.
  • 0 over 7 years ago
    Yes, DC selection for a specific site is turned on and uses DC's that are in the same site as the ARS servers. Replication latency should not be a problem.