• State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 62 subscribers
  • Views 14738 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
  • +2 over 7 years ago

    Michael opened up a Support case with us.

    Once confirmed that he was using Basic Authentication in IIS, I was able to easily reproduce the issue he described. After some digging, I found that IIS uses a token cache for Basic Authentication that will, as it sounds, cache the user token. This has a default of 15 minutes. Luckily, this can be overwritten in the registry.

    Under the following registry key:
    HKLM\System\CurrentControlSet\Services\InetInfo\Parameters

    Create a DWORD item with the following information.
    Name: UserTokenTTL
    Value: <seconds>

    In my testing, I set this to 1 second. I highly advise against setting it this low as it caused a significant decrease in performance; this makes sense as it would be contacting the DC to query the user to rebuild the token every second. However, it allowed the changes to show up right away.

    Once confirmed with Michael, he was able to confirm in his existing 6.9 environment that someone had indeed created that registry setting with a value of 30 seconds.

    EDIT

    Solution article has been authored.  Once the server caches update, it will be accessible at the following URL:
    https://support.quest.com/kb/225673

Reply
  • +2 over 7 years ago

    Michael opened up a Support case with us.

    Once confirmed that he was using Basic Authentication in IIS, I was able to easily reproduce the issue he described. After some digging, I found that IIS uses a token cache for Basic Authentication that will, as it sounds, cache the user token. This has a default of 15 minutes. Luckily, this can be overwritten in the registry.

    Under the following registry key:
    HKLM\System\CurrentControlSet\Services\InetInfo\Parameters

    Create a DWORD item with the following information.
    Name: UserTokenTTL
    Value: <seconds>

    In my testing, I set this to 1 second. I highly advise against setting it this low as it caused a significant decrease in performance; this makes sense as it would be contacting the DC to query the user to rebuild the token every second. However, it allowed the changes to show up right away.

    Once confirmed with Michael, he was able to confirm in his existing 6.9 environment that someone had indeed created that registry setting with a value of 30 seconds.

    EDIT

    Solution article has been authored.  Once the server caches update, it will be accessible at the following URL:
    https://support.quest.com/kb/225673

Children
No Data