What's new in this release -
Jamf Connect Login (version 1.2.0):
• [JC-322] Fixed an issue that intermittently caused the login window for Microsoft Azure AD users to be hidden when the user clicked on the background. • [PI-006887] Fixed an issue that prevented users from selecting multi-factor authentication (MFA) pop-up menu items when Jamf Connect Login was integrated with Okta.
Jamf Connect Sync (version 1.0.4):
• [JC-377] Fixed an issue that intermittently prevented Duo MFA prompts from closing automatically. • [JC-343] Fixed an issue that prevented password changes from updating in the user’s keychain.
• [JC-388] Status menu items no longer appear selectable.
For more information, including Release Notes, please see the Jamf Connect Administrator’s Guide:
For some reason, I am unable to authenticate with Jamf Connect Login 1.2.0. Reverting back to 1.1.3. works as it should.
When signing in, authenticating with Azure and MFA, the login prompt loops continuously. Are there changes that need to be made with the new version of Jamf Connect Login 1.2.0?
I build out the packaged using Composer to add in some reference files for Jamf Connect Verify and Graphics. I sign with my Apple Developer cert.
Hi @cwilsonncaa This sounds like you may have a redirect URI for your Azure application registration set to "Web" instead of "Public." If that is not the issue, I would first try to update to the latest version of Jamf Connect 1.3.0 or contact support so they can further troubleshoot.
@cwilsonncaa We had this same issue, and resolved it by going into Azure AD and going to the Jamf Connect Login application that was created. Go to Permissions and make sure "Grant Admin consent for %org name%" is selected.
If you setup Login Connect early on this was not an issue, but came up later.
"After registering Jamf Connect Login with Azure, you must grant admin consent to the app". It did not say you "must" in earlier instructions.
@mattvlg I did get this working. We have had a couple issues, some in Azure and some with Composer. Can you share your method of packaging and deploying? If using Composer and deploying via enrollment packages, my config is as follows:
- Verify you created the Jamf Connect Login app in Azure as a native app. Azure is currently defaulting to Web app with the new app registration experience. I had to recreate it using the legacy app registration experience.
- Grant the app Windows Graph API Admin Permissions to read Azure Active Directory (see pic from previous post)
- Open fresh session of Composer (force quit and re-open), I have learned that this sometimes screws with permissions
- Build package in Composer
- Give all folders and files included in the package 'Mode: 755' permissions. I did this by selecting the main folder and selecting to, "Apply Permissions to Applications and All Enclosed Items."
- Ensure you are signing the package in Composer with a valid Apple Developer ID
- Upload Composer built package to Jamf - Give the package a priority of '1' to ensure highest deployment priority
- Add package to Enrollment Package payload in your Prestage Enrollment
- Upload PLIST as Custom Setting in Configuration Profiles and scope to same target as Prestage Enrollment. Depending on how granular your setup is, this could be simple. I scope to all users and computers and exclude targets that are not desired. This ensures the configuration hits quick enough so you don't receive the "Identity Provider" errors and getting a trial version of Jamf Connect Login. You can also get more precise by setting the PLIST to deploy as the first configuration profile. Jamf pushes out in alpha-numerical order. So I have a category called "Authentication" to which my Jamf Connect PLISTs belong. They deploy before any other configuration profiles due the category being the first listed.
Note, we also have MFA/ Conditional Access and Passwordless Authentication configured in Azure and it all works. Issues with Azure configs of those groups can create issues for Jamf Connect
@cwilsonncaa Thanks so much for taking the time to respond. Glad to hear things are working for you.
In Azure I did grant the appropriate permissions via the legacy app registration page. For some reason if I try to click on the "Grant Admin Consent for..." button in new UI (shown in your screenshot) it will not successfully approve. When I try the new UI, an o365 consent window would open to ask for permissions, and then the final step would attempt to redirect to http://127.0.0.1/jamfconnect, and that gives me a browser error page (server not found).
Like you did, I deployed a Config Profile with a Custom Setting (uploaded my PLIST file) and deployed it to my test machine.
After that I used the stock package provided by Jamf and deployed it. I am running the trial version. Initially I did see an identify provider error, but that seemed to resolve itself. Now I'm just stuck at the login screen. In Azure I can see that my login attempts have been successful.
At this point I've run out of ideas so I'll probably need to create a support ticket.
"In Azure I did grant the appropriate permissions via the legacy app registration page. For some reason if I try to click on the "Grant Admin Consent for..." button in new UI (shown in your screenshot) it will not successfully approve. When I try the new UI, an o365 consent window would open to ask for permissions, and then the final step would attempt to redirect to http://127.0.0.1/jamfconnect, and that gives me a browser error page (server not found)."
That is the normal and expected behavior.
Mind sharing your PLIST?
Also, to get around the identity provider issue, in your Prestage Enrollment, DO NOT scope your PLIST Configuration Profile for Jamf Connect Login. It will install and then remove before the application runs. The best way to deploy is as I mentioned above. Either scope the Configuration Profile to the Prestage Enrollment Smart Group or scope to all users. This ensures it installs and sticks prior to application running.