Jamf Pro Version Check
Baldovino Caya
There are two ways that I can think of. The first is to grep the JAMFSoftwareServer.log. The version is written on every startup. The other is to check the version.xml inside the deployed application. It should be in $JSS_INSTALL/tomcat/webapps/ROOT/WEB-INF/xml. It holds all of the version of different binaries in a normal xml format.
Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.
This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.
The Extension Attribute script provided in the SOFA GitHub is named macOSVersionCheck-EA.sh (click here). This checks the local system version against the latest compatible version in the SOFA JSON feed, and sends either Pass or Fail to the Jamf Pro server. This can then be used to scope non-compliant computers into a Smart Group, which can be used to push MDM/DDM software update commands or any other compliance-related action.
The Extension Attribute script provided in the SOFA GitHub is named XProtectVersionCheck-EA.sh (click here). This checks the local system version against the latest compatible version in the SOFA JSON feed, and sends either Pass or Fail to the Jamf Pro server. This can then be used to scope non-compliant computers into a Smart Group, which, as with the macOS check, can be used to push MDM/DDM software update commands or any other compliance-related action.
Okta Device Trust for Jamf Pro managed macOS devices allows you to prevent unmanaged macOS devices from accessing corporate SAML and WS-Fed cloud apps. Okta Device Trust ensures that only known and secured devices can access your Okta-managed applications.
Device Trust deployment is not renewed on devices that are not used to access secure applications. For this reason, it is recommended to issue certificates only to the devices that require access to secure resources.
Device Trust isn't supported with all versions of Microsoft Office thick clients: This Device Trust solution has been tested to work with Microsoft Office thick client versions 16.13.1 and 16.15. However, it doesn't work with Microsoft Office thick client version 16.14 (build 180610).
Webview must have access to the device keychain: Device Trust for managed macOS computers works with any SAML/WS-Fed-enabled app that supports authentication through a webview. The webview in which authentication is performed must have access to the Okta Keychain on the device. To prevent end users from being prompted for consent when the certificate is used in the authentication flow, Okta allows the following apps. See Modify the default allowlist:
Apps must support Modern Authentication: To secure Microsoft Office apps with this Device Trust solution they must be enabled to support Modern Authentication. For more information, see the Microsoft article How modern authentication works for Office 2013 and Office 2016 client apps. Also see Office 365 Client Access Policies.
Take care when disabling the macOS Device Trust setting: Do not disable the macOS Device Trust setting on the SecurityDevice Trust page if you have also configured an app sign-on policy that allows trusted macOS devices. Otherwise, your Device Trust configuration will be in an inconsistent state. To disable Device Trust for your org, first remove any app sign on policies that contain a Device Trust setting, then disable macOS Device Trust in SecurityDevice Trust.
This information allows Okta to verify that end user devices are managed by Jamf Pro at the time of certificate enrollment. For Jamf Pro, you need at least these READ privileges to access Jamf APIs in order for Okta to verify that the device is managed:
Make a note of the provided Secret Key Value and Org URL, as this is the only time these will appear in Okta. Also, if you later want to edit your configuration and generate a new Secret Key through the Reset macOS Secret Key button, you must perform this procedure again.
When entering the key and the URL, retain the single quotation marks ( ' ) but replace the parentheses and the placeholder text with the actual Secret Key Value and Org URL, as shown in the following example:
By default, the Okta Device Registration Task allows some popular apps so that end users aren't prompted for the keychain password when accessing them. To modify the default allowlist, see Modify the app allowlist.
The Okta Device Registration Task is a script that is distributed by Jamf Pro to the macOS devices you have targeted for this Device Trust solution. When deployed on the device, the Okta Device Registration Task does the following:
Configures Chrome and Safari browsers and tested native apps These Modern Auth-enabled native apps: Microsoft Office 365, Box, Google Drive, Skype for Business, Slack on the device to present the certificate automatically during secure app access.
Schedules a lightweight task that runs once a day and whenever users log in to their computer. The task checks whether the Device Trust certificate is expired and tries to renew the certificate 30 days before expiry. Certificates are valid for 1 year.
Note: There are other approaches that you can implement in Jamf Pro to trigger deployment of the script (for example, Extension Attributes, which allow you to validate that the certificate is on the device and to deploy the certificate if it is missing).
You may need to revoke an end user's Device Trust certificate(s) from the Okta Certificate Authority. This is recommended if the computer is lost or stolen, or if the end user is deactivated. To re-secure an end user's computer with Device Trust after revoking their Device Trust certificate(s), you need to remove the revoked certificate from their computer before enrolling a new certificate.
During deployment, the Okta Device Registration Task publishes logs in Jamf at three log levels (INFO, WARN, ERROR). To diagnose deployment issues, Jamf administrators can view deployment logs on a policy or individual computer basis. To generate more granular logs, use the verbose option as the Parameter Value in Jamf Pro.
The Okta Device Registration Task allows some popular apps by default so that end users aren't prompted for the keychain password when trying to access them. You can customize the default allowlist as described in this procedure.
The Okta Device Registration Task is a python script that you obtain from Okta, modify, and then upload to Jamf Pro for distribution to the macOS devices you have targeted for this Device Trust solution.
If a module not found error (for example, "ModuleNotFoundError: No module named 'Systemconfiguration'") occurs, confirm that the dependencies from [link to 'install the device trust dependencies"] are set up correctly.
If the device_trust password is not present then device trust-secured apps can't access the Okta keychain. To remedy this, uninstall the certificate. Seee Revoke and remove Device Trust certificates. Re-enroll the device. See Step 4. Add the modified Okta Device Registration Task to Jamf Pro and distribute it to macOS devices.
A certificate becomes bound to a given user the first time that user accesses a device trust-secured application from a device trust-secured macOS device. Unused certificates are unbound. Okta can issue up to five unbound certificates to the device, one each time you perform the enrollment procedure. As a security precaution, Okta will not issue more than five unbound certificates to a given device. To avoid reaching the unbound certificate limit, ensure that users use the unbound certificates already on the device before you attempt to obtain more certificates through enrollment. If you reach the enrollment limit, the Syslog indicates an enrollment failure and the error message Maximum enrollment limit of 5 certificates for a device is reached appears in the JAMF log.
DebugData shows the unique ID of the devices associated with Device Trust events and is useful for debugging purposes. This information can also help you verify thatDevice Trust is being enforced on devices in your device inventory, which may be useful prior to rolling out the feature to a large group of users.
Try to access a Device Trust-secured app from a browser or thick client. If an error displays while trying to access the app, Quit and Close the browser (Chrome or Safari), relaunch the browser, and then try to access the app again.
Alternatively, you can create a Static Group and select computer members by enabling the checkbox next to each record. However, it is unknown when Jamf will release a Jamf Pro version to fix long delays displaying the list of computers for selection, so avoid use of static groups, if you experience these delays.
When unsure of a change and its effects, first "stage" the new criteria in an Advanced Search, validate the results match your expectations, then make the corresponding changes to your existing smart group.