lithnet / access-manager

Access Manager provides web-based access to local admin (LAPS) passwords, BitLocker recovery keys, and just-in-time administrative access to Windows computers in a modern, secure, and user-friendly way.
Other
239 stars 20 forks source link

inconsistent jit functionality #135

Closed CodeNameTheOnlyOne closed 2 years ago

CodeNameTheOnlyOne commented 2 years ago

we are having some issues with inconsistent jit functionality. i do not think this is a problem with lithnet, more of a windows problem, but was looking for some troubleshooting advice.

when i request jit acesss users are getting added to the jit group, and i can see on the pc that the jit group is a member of the local admins group, but sometimes they are still not able to run as admin.

is there a windows command to run on the pc in question to querry who it thinks is in a certain group, or why a user was denied.

as in this scenario i could see from the domain controller that the user was in the correct jit group, and should have been given access and it was failing.

when i requested jit i got added to the group and was able to elevate successfully, so it has me baffled, why one user works and another does not, when both show as being members of the group on the domain controller.

just to test i created a new user and was able to request jit and it also worked right away.

i am thinking it might be an issue with this user account but jit works on some machines and not others for it, it seems inconsistent.

any advice on how to troubleshoot these issues would be great as we are moving to deploy this in more locations.

ryannewington commented 2 years ago

@CodeNameTheOnlyOne

Are the computers you are trying to access in the same site as the AMS server?

This sounds like a replication issue. AMS will always try and find a DC in the same site as the target computer, and add the user to the group on that DC. If AMS were unable to locate the site the computer is in, it would fall back to its closest DC, and you might then see replication delays impacting the duration of time it takes for access to appear to work.

So I'd start by checking 1) Is replication between all DCs working correctly? 2) Are AD sites and subnets defined correctly, and are the computers in a site with a DC?

If you can share a snippet of the AMS server log, for one of these attempts that appeared to be delayed, we can see what DC the AMS server is using to perform the group operation.

CodeNameTheOnlyOne commented 2 years ago

Single site with two domain controllers, both domain controllers show the jit group with correct membership, i do not think it is an issue with ams as the users get added to the groups.

is there a way to query group membership from a member workstation. i think the pc is either caching the group membership or something werid.

ryannewington commented 2 years ago

The only thing I can think of was the user had an existing session, where they were not an admin, and just reconnected to it. In order for the new group membership to apply, they need to log off/log on.

You can get the user to run the built-in whoami /groups tool when this issue arises, and see if their token contains the JIT group or not.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.