ryannewington
commented
3 years ago Hi @sniper9191
You're completely right about the local group membership stuff - it's a tricky problem to solve, as we are restricted to how windows works internally.
However, when we need to consider the context of what AMS is trying to achieve. The main goal of AMS is to reduce lateral movement opportunities for an attacker that got into your system. We do this by removing standing admin rights across all servers. So if an attacker managed to get onto server x, we don't want them to get onto server y and z, just because the user they had compromised had permanent admin access on those servers. JIT is still valuable, because for the attack to be successful, they need to find servers where their compromised user currently has claimed JIT access. The local admin issue doesn't come into play here, as they are moving across the network over the wire, so the kerberos ticket will not have the admin group in it past expiry, therefore they would be a standard user on that device.
If we look at a server environment of say 2000 servers, and pre-JIT there were 10 admins of every server, then there are potentially tens of thousands of active lateral movement paths to take advantage of. Post JIT implementation, those paths are restricted to just the combination of users who are actively logged on. Functionally, this breaks most broad-based attacks.
We can reduce those remaining paths even further by deploying a tool such as our idle logoff tool, to boot these users off their sessions each day.
We're trying to stop cases where the loss of a single server to an attacker through compromise, ends up becoming the loss of an entire fleet of servers through credential theft and subsequent lateral movement. In that case, JIT is extremely effective even with the limitations discussed in your post.
If you are looking to restrict what your users can do and the duration they can do it for, then AMS may not be the product for you. It's a very valid use case, but not one we are trying to solve. A PAM-type solution would probably be best here.
I'm happy to discuss this further!
stale[bot]
This is probably beyond the scope of Access Manager itself, but...
If I were to grant GIT access to a user account, this change in permission doesn't take effect, if the user is currently logged in on the computer. It only takes effect if the user login / re-login.
While it might be easy to request users to re-login to gain local administrator permissions, it is a problem to encourage users to re-login after their JIT time window had expired - these users could easily remain logged in perpetually, and retain their JIT admin rights beyond the time window. (lock/unlock doesn't help either)
klist purge wouldn't help here, since we are talking about local group membership, and not Active Directory group membership. Even if the user account has gotten Kerberos tickets reflecting its new Active Directory group membership, it doesn't update the LSA policy databse (which is used to assess local permissions) token until the user re-authenticates locally.
While doing runas /user:username processname helps to trigger an authentication, it only applies to the process (and child processes) being executed by runas, and doesn't apply to all other pre-existing processes.
Has anyone found a solution for this problem? Without being able to ensure that local admin rights aren't retained beyond the JIT time Window, there seems to be limited benefit to implementing the JIT feature in my organization.