Has anyone had experience with a privilege management solution called "Admin By Request?" If so, how has it worked for you? I am also wondering if it's necessary to create config profiles for approving FDA and its system extension. (I generally create two config profiles for applications that require them: one for PPPC, and one for the system extension. I did create the profiles for ABR, but I don't want to deploy them if they aren't necessary.)
Question
Looking for feedback: Admin By Request from Fast Track Software Apps
+4
+16We haven't purchased and implemented it yet, but in our trial we did NOT have to deploy a PPPC or System Extension profile for ABR to work. It is possible that it might be required for some of the additional functionality but not the admin elevation we tested.
+13I'm going to have to look in to this further; I've been looking for something other than the script to allow temporary admin rights. @hodgesji could you expand a little on what you did during the trial and if you ran in to any hiccups along the way?
+16Of course! We currently utilize the excellent Privileges app (https://github.com/SAP/macOS-enterprise-privileges) and we have some custom code built for creating and maintaining local access groups on the Mac which prevent unwanted elevation. We also have some custom code and a daemon built out to automatically demote users so we they don't indefinitely get admin access.
We wanted to find a tool that could provide the same functionality as above with the addition of an approval process and differing levels of access depending on context while also provide platform parity across our windows fleet.
In addition to doing the same things as above, we tested the following functionality to make sure ABR met our needs:
- Simple installer with a pkg deployable in Jamf
- The new ABR client introduced Azure integration with Jamf Connect (which we also run) so we can could determine the user's group membership for access.
- Sub settings allowed us to use azure group membership for different levels of access (approval being required, time of elevation, etc.)
- Approval mechanism is quick and allows the user to elevate later if they aren't still at the Mac when it got approved.
The few hiccups in our testing were around the new 4.0 client not connecting to Azure AD properly. We had to work with their development team to get some changes made to the client but I assume that would be ironed out once the new client matures a little. We also were not able to test any branding changes even though we made branding changes in the portal. This could be because we were running a trial, but branding wasn't that important to us anyway.
+4@hodgesji Thank you very much for that write up, I think it will help me out tremendously! Being friendly with Jamf Connect and Azure AD are the two main reasons we're looking at ABR in the first place.
Cheers!
+3Of course! We currently utilize the excellent Privileges app (https://github.com/SAP/macOS-enterprise-privileges) and we have some custom code built for creating and maintaining local access groups on the Mac which prevent unwanted elevation. We also have some custom code and a daemon built out to automatically demote users so we they don't indefinitely get admin access.
We wanted to find a tool that could provide the same functionality as above with the addition of an approval process and differing levels of access depending on context while also provide platform parity across our windows fleet.
In addition to doing the same things as above, we tested the following functionality to make sure ABR met our needs:
- Simple installer with a pkg deployable in Jamf
- The new ABR client introduced Azure integration with Jamf Connect (which we also run) so we can could determine the user's group membership for access.
- Sub settings allowed us to use azure group membership for different levels of access (approval being required, time of elevation, etc.)
- Approval mechanism is quick and allows the user to elevate later if they aren't still at the Mac when it got approved.
The few hiccups in our testing were around the new 4.0 client not connecting to Azure AD properly. We had to work with their development team to get some changes made to the client but I assume that would be ironed out once the new client matures a little. We also were not able to test any branding changes even though we made branding changes in the portal. This could be because we were running a trial, but branding wasn't that important to us anyway.
We have a similar setup but some of our macs are getting the wrong groups when setting sub settings . Any idea as to what would cause this ?
+16We have a similar setup but some of our macs are getting the wrong groups when setting sub settings . Any idea as to what would cause this ?
ABR Subsettings are retrieved from Jamf Connects connection to Entra ID. Unfortunately the groups are only user-based since the Macs themselves are not put into Entra. When a user logs into Entra ID group membership of the user account is associated with ABR for subsettings.
We found that when ABR is first installed, you need to wait long enough for it to sync subsettings or you can force it to sync by going to About Admin by Request from the menu bar and then click on the Connectivity tab. That tab should also show the connectivity status and mode, as well as the username it is checking subsettings against.
If you are still having problems with subsettings, I would reach out to support and see if there is something else going on.
+4
What is the mechanism you use for approval being required?
- Sub settings allowed us to use azure group membership for different levels of access (approval being required, time of elevation, etc.)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.