Skip to main content
Question

Jamf Connect 2.0.1 Release

  • October 19, 2020
  • 11 replies
  • 61 views
K
Forum|alt.badge.img+10

Today we released Jamf Connect 2.0.1 for general availability; this release includes the below fixes. As a reminder, the newest version of Jamf Connect focuses on ease of use and streamlined workflows for both admins and end users with:

• A redesigned Jamf Connect Login application
• Combined Jamf Connect Verify and Sync applications
• A streamlined installation process
• Additional features to the Jamf Connect Configuration application

To upgrade to the latest version, please check out the detailed instructions in the Jamf Connect Administrator Guide or this KBase article.

Jamf Connect 2.0.1 Fixes -
Jamf Connect Login Window:
• [PI-007101] Fixed an issue that prevented Google ID users from being prompted to enroll in multifactor authentication (MFA) when required.
• [PI-008868] Fixed an issue that prevented the Use Local Authentication by Default (OIDCDefaultLocal) setting from being respected.
• [PI-008870] [JC-1956] Fixed an issue that caused the acceptable use policy screen, when configured, to incorrectly display.
• [PI-008874] Fixed an issue that prevented OneLogin users from creating accounts via Jamf Connect and Jamf Pro's Enrollment Customization settings.
• [PI-008861] Fixed an issue that caused to Login Window Message (LoginWindowMessage) to be unavailable in the Jamf Repository settings available in Jamf Pro's Application & Custom Settings payload.
• [PI-008899] Fixed an issue that caused the notify screen, when enabled, to expand to the full screen width.

Menu Bar App:
• [PI-008593] Fixed an issue that caused the menu bar app to fail to redirect users to the Okta dashboard if the AuthServer preference key in the configuration is spelled with any capital letters.
• [PI-008869] Fixed an issue that caused the menu bar app to incorrectly display a license validation error on computers with a valid Jamf Connect license.
• [JC-1939] Fixed an issue that caused the menu bar app to always open Jamf Self Service if it is installed on the computer, even when the SoftwarePath preference is configured to open a different software.
• [JC-1987] Fixed an issue that caused the Home or Home Directory menu bar item to appear even when the UserHomeDirectory preference is not configured.
• [JC-2080] Fixed an issue that prevented the value of the ShortName key from being used for Kerberos authentication.

Configuration App:
• [JC-1922] Fixed an issue that caused Jamf Connect Configuration to fail to clear formatting on text pasted into the code editing field.
• [JC-2053] Fixed an issue that caused the Jamf Connect Configuration UI to be missing the User Help, Keychain, Scripting, and Certificates settings sections.

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

Thank you!
The Jamf Connect team

A
Surajit

11 replies

B
Forum|alt.badge.img
  • bbdot
  • New Contributor
  • October 20, 2020

Hi there!

When should we expect the Patch Policy definition to be updated to include the 2.0.1 release of Jamf Connect?

Thanks!

N
lucas_cantor
Forum|alt.badge.img+8
  • lucas_cantor
  • Contributor
  • October 20, 2020

Is anybody else seeing this update cause Macs to hang at the login window progress bar (after FileVault unlock)?

I've opened a support ticket as well, but I'm curious.

We have FileVault enabled on all Macs, and we have the DenyLocal preference in com.jamf.connect.login set to false. This normally results in users bypassing the Jamf Connect Login window entirely after a reboot, with the FileVault unlock window bringing users to their Desktops after they accept the Jamf Connect Login EULA.

After updating to Jamf Connect 2.0.1 the FileVault unlock works and Macs can communicate with our JSS and run policies, etc... but the login progress bar just hangs.

J
Forum|alt.badge.img+7
  • Jimbo
  • Contributor
  • October 22, 2020

@lucas.cantor

Since the Mac is reporting even while hanging on FV login, try to deploy a policy with the Files and Process payload, and in the Execute Command field, use:

/usr/local/bin/authchanger -reset -jamfconnect

Once you confirm it deployed successfully to the Mac, try rebooting the Mac and see if it still hangs.

lucas_cantor
lucas_cantor
Forum|alt.badge.img+8
  • lucas_cantor
  • Contributor
  • October 22, 2020

Thanks @Jimbo

This was my first thought as well, but unfortunately it doesn't solve the issue.

The issue occurs whether upgrading to Jamf Connect 2.0.1 from Jamf Connect 2.0.0 or clean-installing Jamf Connect 2.0.1 on a brand new clean-install of macOS.

When testing the latter as part of our zero-touch deployment process, the "/usr/local/bin/authchanger -reset -jamfconnect" command is run anyway, but login definitely still hangs regardless...

Jamf support has gotten back to me with a few questions to confirm and logs to collect, but no answers yet :(

M
Forum|alt.badge.img+9
  • merps
  • Contributor
  • October 23, 2020

@lucas.cantor seeing the exact same thing on 10.15.7 fresh builds - have been fighting with it for the past couple of days.

I was able to successfully upgrade a test box from the JC2 Beta version to 2.0.1, but can't get a fresh build to present the Jamf Connect Login interface. It does the EULA after login, so I know "something" is working but the login progress bar hangs around 2/3 full.

I haven't tried 2.0.0 yet, but I'll see if that makes a difference.

lucas_cantor
Forum|alt.badge.img+8
  • lucas_cantor
  • Contributor
  • October 24, 2020

@merps I’ve heard back from Jamf support after they were able to reproduce the issue and isolate a root cause:

Hi Lucas, Happy Friday! Thank you for your patience while we look into this! I performed some testing and was able to replicate the behavior. From that testing, it's looking like the combination of the EULA being configured and the DenyLocal key being set to false with Jamf Connect 2.0.1 is causing the transition from the FileVault screen to the EULA to hang. The FileVault authentication does complete successfully after I removed the EULA entirely or set the DenyLocal key to true so that the FileVault authentication transitions to the Jamf Connect Login window before the EULA. With this, I've gone ahead and filed this behavior as an issue for the relevant teams to investigate further. In regards to our case here, it may be best to remain at the current Jamf Connect 2.0 version until a fix is released or we learn more. Please let us know if there are any questions about this or if we can clarify anything. Thank you for bringing this to our attention!
M
Forum|alt.badge.img+9
  • merps
  • Contributor
  • October 26, 2020

@lucas.cantor Awesome, thanks for the update. After testing, I've had better results with 2.0

lucas_cantor
D
Forum|alt.badge.img+5
  • dnorman
  • Contributor
  • November 5, 2020

I'm using the LAPS key in my PLIST with jamf connect and it worked fine on Catalina. It doesn't work on Big Sur. Maybe there's something else I'm missing specifically for Big Sur. I will try with 2.0.2.

G
Forum|alt.badge.img+3
  • gary_owen
  • New Contributor
  • December 9, 2020

@dnorman In case you haven't seen this the 2.1.1 manual now states the following :-

"Note: On macOS 11 or later, the Local Administrator Password Solution (LAPSUser) is not required to enable FileVault for standard accounts."

peternbevan
Forum|alt.badge.img+5
  • peternbevan
  • Contributor
  • December 9, 2020

It turns out you can either have FileVault enabled for Catalina by using the LAPSUser clause, OR you can have it for Big Sur if you remove the LAPSUser clause. Not ideal. I've had to revert to a messy FileVault enable policy after ADE for Catalina machines. We expect to continue using Catalina for some time until all software compatibility issues for Big Sur are resolved, and beyond for older hardware.

peternbevan
Forum|alt.badge.img+5
  • peternbevan
  • Contributor
  • December 9, 2020

Vote up my Feature Request for a Jamf Connect configuration which can enable FileVault in more than one macOS.

Terms & ConditionsCookie settingsAccessibility statement