Skip to main content

Update Sept 7th, 2021 - Jamf Connect 2.4.5: We have resolved an issue that prevented the Admin Client ID (OIDCAdminClientID) setting from being respected during account creation via Okta and Jamf Connect, which unexpectedly created all new local accounts as standard users. For more details, please see the release notes here. 

 

Update Sept 3rd, 2021: 

Connect 2.4.4 introduced PI-010087, a regression, for organizations with more than one of the following managed preferences in their configuration: OIDCAccessClientID, OIDCAdminClientID, OIDCSecondaryAccessClientID

Issue description: When signing in, only the first of the available client IDs is used for evaluating user access and permissions. As an example, configurations with both OIDCAccessClientID and OIDCAdminClientID can result in a user logging in to their local account and being demoted from administrator privileges to a standard user account. Configurations with none or only one of these preferences enabled should not be affected. As a workaround, modify the configuration to remove additional client IDs that should not be evaluated.

Connect 2.4.4 has been removed from auto-deployment settings for Jamf Pro customers - Connect 2.4.3 will be displayed as the most current version available until a solution can be made available via a future update.

Connect 2.4.4 will remain available for download from Jamf Account. 

-----------------------------------------------------------------------------------

Today we released Jamf Connect 2.4.4 for general availability; this release includes the below details.

Key Feature Content

Menu Bar App Branding Enhancements: You can now configure the menu bar app to use a new alternate icon rather than the default Jamf logo and company name

Jamf Unlock 1.2.0*

  • UI translation for Japanese, French, German, Spanish
  • UI updates that improve the device pairing experience and authentication using a static PIN

*This update will be available in the App Store when it is approved by Apple.

 Key Technical Content

  • [PI-009301] Okta Verify number challenges now complete multifactor authentication requests as expected, when triggered by Okta's behavior detection policies.
  • [PI-009849] Fixed an issue that caused Jamf Connect to continuously queue Kerberos authentication requests when the `Renew Kerberos Tickets` (AutoRenewTickets) setting was enabled and computers were offline or not connected to an Active Directory domain, which resulted in users being locked out of Active Directory.
  • The Paired Devices window that displays a device used for Jamf Unlock authentication now displays the user's device name rather than just the device type.

 

Product Documentation

For more information, including Release Notes, please see the Jamf Connect Administrator Guide .

Important Note: To access new versions of Jamf Connect, log into Jamf Account with your Jamf ID. The latest version is located in the Products section under Jamf Connect. Jamf Account is a new portal where our partners and customers can easily find the features related to their individual accounts with Jamf. My Assets (re-named to Products in Jamf Account) and Support now reside within Jamf Account. More information about Jamf Account is located here: https://www.jamf.com/lp/jamf-account/.

Also, after much discussion with our community, we are going back to release specific Jamf Nation posts, beginning with this release, Jamf Connect 2.4.4. Thank you for all of the feedback! 

 

The Jamf Connect team

 

 

@kaylee_carlson , any idea if FB9231836 (Subclass of NSSecureTextCell is sent unrecognized selector on beta 2) was addressed by Apple so this release might work on future OS releases?

Thanks. 

For this version it's not scaling custom the menu bar "Connect..." sign in window image. So the sign in window is huge.

Using the same image as all of the previous versions.

@kaylee_carlson , any idea if FB9231836 (Subclass of NSSecureTextCell is sent unrecognized selector on beta 2) was addressed by Apple so this release might work on future OS releases?

Thanks. 


@steve_summers the necessary changes regarding NSSecureText* have been implemented in 2.4.4 to help resolve potential issues with future OS releases, yes.

For this version it's not scaling custom the menu bar "Connect..." sign in window image. So the sign in window is huge.

Using the same image as all of the previous versions.


@AdamCraigare you referring to "SignInLogo" or "MenubarIcon"? Do you mind sharing the dimensions of the image being used for custom branding? 

@AdamCraigare you referring to "SignInLogo" or "MenubarIcon"? Do you mind sharing the dimensions of the image being used for custom branding? 


Sign In Logo.
the image being used is a 2258 × 374 .png

Which I realize is way too large, but I just got our company's logo, and tried it and it always scaled down properly before so I never even thought about resizing it.

I just got my users updated to 2.4.3!

Although there are no details in the release notes, have found that Jamf Connect version 2.4.4 has resolved all of our identified issues when using Jamf Connect with macOS Monterey. Jamf Connect for us now works seamlessly with Monterey beta 5 & 6 in testing.

I've opened a support case for this as well, but we've noticed that our FileVault Recovery Keys are no longer getting escrowed into the JSS computer record during the EnableFDE mechanism on Jamf Connect Login 2.4.4. Still works reliably on previous versions of JCL.

I've just pushed version 2.4.4 to a device, converted the account from mobile to local, unbound from AD.  When the user tries to change his password, he receives an error that the local password is incorrect, even though he's using it to sign in, as well as authenticate to unlock items in System Preferences.  My guess its related to

  • [PI-009255] Jamf Connect fails to change passwords on computers that have previously been bound to an Active Directory domain.

    Workaround: Manually create a krb5.conf file in the /etc/ directory.

I've pushed the krb5.conf file to /etc.  Any idea on when a fix will be implemented?  This is the start of my trial to unbind our remaining Mac's from AD.

We are brand new to Jamf. We literally just implemented Jamf Connect Login with Okta as our IdP. We were pushing 2.4.3 and everything was working, so we deployed widely to our Mac Labs successfully.

Classes started this week and Tuesday (day 2) nobody could log in on Macs in these labs. It seems that Jamf's deployment integration upgraded all the Macs to 2.4.4 and the new version fails to allow people in. After providing their username and password, the prompt goes away, then immediately comes back. Providing garbage credentials results in a bad credentials message, so we know there is some kind of proper communication with Okta.

We ended up un-scoping all the labs, manually uninstalling all the Jamf Connect Login stuff (no small feat), then modifying Jamf's settings to only push 4.3.3 and never automatically upgrade, then re-scoping everything.

I submitted a ticket with Jamf support on Tuesday and they've finally responded this morning, so we'll see what they say.

 

Connect 2.4.4 introduced PI-010087, a regression, for organizations with more than one of the following managed preferences in their configuration: OIDCAccessClientID, OIDCAdminClientID, OIDCSecondaryAccessClientID

Issue description: When signing in, only the first of the available client IDs is used for evaluating user access and permissions. As an example, configurations with both OIDCAccessClientID and OIDCAdminClientID can result in a user logging in to their local account and being demoted from administrator privileges to a standard user account. Configurations with none or only one of these preferences enabled should not be affected. As a workaround, modify the configuration to remove additional client IDs that should not be evaluated.

Connect 2.4.4 has been removed from auto-deployment settings for Jamf Pro customers - Connect 2.4.3 will be displayed as the most current version available until a solution can be made available via a future update.

Connect 2.4.4 will remain available for download from Jamf Account. 

How long before 2.4.4 regression is fixed and we have a 2.4.5 as 2.4.4 and Monterey B6 work but now with have PI-010087 with 2.4.4.
1 step forward, 2 steps back!

Although there are no details in the release notes, have found that Jamf Connect version 2.4.4 has resolved all of our identified issues when using Jamf Connect with macOS Monterey. Jamf Connect for us now works seamlessly with Monterey beta 5 & 6 in testing.


Thank you so much for this post. I have been hoping for this but was also still doubtful until I read this.

@mikevandelinder Now that version 2.4.5 is in prod, should the OIDCAccessClientID key be present? Right now we only have the OIDCAdminClientID key present in our config profile for the Login Window and we are only seeing logs in Okta for the Admin application and not the Standard app.

@mikevandelinder Now that version 2.4.5 is in prod, should the OIDCAccessClientID key be present? Right now we only have the OIDCAdminClientID key present in our config profile for the Login Window and we are only seeing logs in Okta for the Admin application and not the Standard app.


we removed one of the keys per advice from the above post by @mikevandelinder 

Hi,

i can't find the download section for the new version of jamf connect. May someone post me a link pls?

thx

it will be in your account at
https://account.jamf.com/products/jamf-connect

thx

Reply


Terms & ConditionsCookie settings