UPDATE 04JAN2022: Link updated to https://www.jamf.com/blog/how-to-azure-conditional-access-and-jamf-connect/
UPDATE 10DEC2021: The information in this post has been replaced by https://community.jamf.com/t5/jamf-connect/jamf-connect-and-microsoft-azure-conditional-access/td-p/...
NOTE 11MAY20201: After communication with the Microsoft developer's team, there appears to still be an issue as to when conditional access policies will apply to Jamf Connect's application. It appears that while we can now define the application in a CA policy, the CA policy does not apply to a native/mobile app login even though the policy IS applied when the scope of the CA policy is defined as "All Cloud Apps." We are awaiting clarification on what is going on with this behavior. Overview: By adding an unique redirect URI to the web application registration for Jamf Connect, Azure Conditional Access defines Jamf Connect as a “cloud app”, which may be used with Azure Conditional Access policies. Purpose: Administrators may wish to enforce Azure Conditional Access polices on an app by app basis. Azure Conditional Access allows administrators to select “cloud apps”, but Azure does not display “native/mobile apps” in the list of cloud apps. Unexpectedly, “native/mobile apps” are included in a definition of “all web apps.” The app registration for Jamf Connect should be exempted from conditional access polices which would cause an incurable situation - if access is restricted to devices marked as compliant with Microsoft Endpoint Manager, but a user is unable to log into the device to enroll the device, for example, the device is stuck in an inextricable state. Procedure: Setting up the Open ID Connect 2.0 application in Azure Follow the instructions in https://docs.jamf.com/jamf-connect/administrator-guide/Integrating_with_Microsoft_Azure_AD.html to create an App Registration in Azure. Add a Web platform redirect URI Navigate to Azure Active Directory → App Registrations → and select the name of the app you created above. Select Authentication from the left hand navigation pane under the section Manage. Use the “+ Add a platform” option. A new pane will open on the right named “Configure Platforms”. Select the option for Web. On the next window, Azure will prompt for a redirect URI. As this option will not be used, enter an invalid URI which cannot be mistakenly used: https://0.0.0.0/jamfconnect Use the “Configure” button at the bottom of the screen to save your work. Modify Azure Security and Conditional Access policies for Jamf Connect Navigate to Azure Active Directory → Security. Select “Conditional Access” on the left hand navigation pane. Select your conditional access policy from the list or create a new policy. In the section “Cloud apps or actions,” the Jamf Connect application you created in the first step will now appear as a valid cloud application which can be included or excluded from a policy.
Conditional Access Policy Considerations
Several Conditional Access Grant policies can create unacceptable behavior to access a client device:
In the above cases, a user would be unable to log into a client machine to fix the issue of being out of compliance by running a Jamf Pro policy to get the device back into compliance.
In the above cases, the Jamf Connect software is not of the Microsoft apps accessing a specific service (for example, Microsoft Outlook accessing O365 mail), and all access would be blocked.
Administrators are recommended to carefully read conditional access polices and conditions applied to avoid locking users out of client devices inadvertently.
Sean, could MS Azure Conditional Access Policies be used to implement macOS Login Window access control lists on systems using Jamf Connect to authenticate logins against Azure? I haven't used Azure or Jamf Connect before but based on what I've read and information from Jamf reps I've spoken with, I think another way to do this would be to register multiple instances of Jamf Connect in Azure and give 'consent' to the appropriate Azure users and groups for a given ACL. In the case of our Azure tenant that would mean our Azure admin would have to create and manage those registered instances of Jamf Connect; not sure that the same wouldn't be true for Conditional Access Policies (I don't seem to have the privileges to create those).
Hello, we are a recent adopter t JAMF Connect with Azure. We have MFA implemented. The issue I have is MFA is occurring at every new login (reboot) on a users computer, and also makes the person very password (this user would be me and a test account as I have not rolled it all out yet).
I am working with support, but not clear of the exact thing we should be looking at. We were not aware of the issue during our onboarding or did not have time to look into it.
Test Devices have been added to InTune for compliance.
@mhegge I had this problem once and pulled my hair out over it. The support rep asked me if maybe the user I was trying it with (my own) was an admin user in Jamf. Actually it was. I tried another user with no admin rights in Jamf whatsoever and it worked as intended. Maybe that helps in your case..
@thomaslc - The ACL question is an interesting ask - you definitely could make as many Azure App Registrations as you wish, but only one app registration can apply to the computer at a time. Utility of this may be Jamf Protect discovering a ransomware attempt and then pushing out a config profile to the machine that only Red Team could access the machine for forensics until cleared...
It may be worthwhile to use the Roles to assign everyone other than the primary user of a machine into a Standard account and then elevate permissions ad hoc via Make Me Admin script or SAP's Privileges app. Bit more granularity you can assign in Jamf Pro permissions than Azure's roles.
@mhegge - The "verify password" is 100% expected and part of the OIDC/ROPG workflows link to purdy graphics
Asking for MFA every time - Each login on the machine is considered a separate session; the cookies the web page may be saving to tell the browser that the user already MFA'ed recently are destroyed on each login. loginwindow process is running as
root so we want to be super secure in this area, and that webkit modal box is completely destroyed between logins.
You may be able to set Azure Conditional Access policies to exempt MFA if on a certain network or only if a certain level of risk event is detected by Azure. I always try to err on the side of "Just because you're paranoid doesn't mean they're NOT out to get you," so if a user is asked for MFA, welp, they're doing it for the organization's security.