Best practices for Jamf cloud implementation

[thebrucecarter]

Greetings all,

We have recently migrated our Jamf Pro instance from on-prem to the cloud product.  We are now looking for best practices information and suggestions from others who have made this move and changed the way that they had implemented things locally.  We made a fair sized jump (from late v10 to current v11, for various reasons) and some things definitely changed in that gap.  For instance, the way that LAPS handles the password rotation and loses the cryptographic linked capabilities.  One of the things we are particularly interested in is how to keep a secure environment (e.g. no "one account and password to rule them all" situation) but still have the token information needed for doing things like OS updates.

But, frankly, any suggestions are welcome.  We have a bit of a grace period for organizational changes here during the migration project, and we want to take full advantage of it.  We are working with consultants (Rocketman Tech) through this project, but we also wanted to hear from peer organizations that might have some valuable background to share.

Thank you very much!

Bruce Carter, University of Notre Dame

[sdagley]

@thebrucecarter We're not using it currently but AFAIK nothing about being Cloud hosted should interfere with using the LAPS feature in recent versions Jamf Pro.

The escrow of the Bootstrap Token from the Mac does not depend on the use of LAPS so there's no issue doing MDM initiated macOS updates from a Cloud hosted environment. Other than the fact that Apple still hasn't implemented a 100% reliable managed macOS update mechanism that is.

[thebrucecarter]

p.s.  That administrator LAPS cryptographic issue is described as follows:

Note:

Jamf does not recommend using MDM LAPS for password rotation if the account needs to use FileVault or authorize software updates on computers with Apple silicon. Rotating a managed local administrator account password from the PreStage enrollment that has become cryptographically enabled with a secure token will result in the login password being changed. However, the new password will not work for cryptographic user authentication purposes.

in the documentation here:  https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/Automated_Device_Enrollment_...

about 3/4 or so of the way down the article.

[sdagley]

Thanks for clarifying. That's not abnormal, giving a LAPS account FV unlock capability would be extremely fragile. For my org we don't rely on a LAPS account for access if the user can't unlock FV, and use the escrowed FV key instead.

[thebrucecarter]

Yes, it is definitely fragile, as in it broke one of our build workflows all over the place.  We are adapting and adopting right now, but it would have been good to know about this in advance.  I have to admit, it is in the current documentation, but we went from a late version of 10 straight to the current version of 11, and we missed a few things.  We are modifying workflows to use the FileVault escrowed key for some situations, elevated local privileges for some others, and are using the capability in Jamf Connect to automatically give field staff admin on their assigned support footprint.

Thank you for responding!

[AJPinto]

Generally speaking, Jamf Pro on Prem and Jamf Cloud would be configured and managed the same. Jamf Cloud adds a few extra features but just grow into them as a feature add and don’t plan to deploy them from the get-go. 

As far as LAPS. We use a security tool for handling local account password rotations, it also has a secure token so it can rotate any accounts password and not just one created a very specific way during device enrollment. Jamf's LAPS is well and good, as is rocket mans, but if you want a truly secure environment you usually need to pay for a purpose-built tool.

[thebrucecarter]

Thank you, AJP.  I will pass that on to our InfoSec people.  We are trying to proceed with informed caution...  :-)

[Valcovish]

If you’re setting up macOS with Jamf and Intune, here are a few best practices to streamline the process and ensure a smooth user experience:

Use DEPNotify for DEP Setup – Instead of relying on the custom Jamf Pro enrollment workflow, DEPNotify makes it much easier to configure and guide users through the setup. It provides a clear, structured UI and helps automate tasks, making the deployment process more efficient and user-friendly.

Avoid User Enrollment if Possible – User enrollment has significant limitations, especially in enforcing policies and deploying managed settings. Instead, go with Automated Device Enrollment (ADE) whenever possible to ensure better control and compliance.

Set Up Compliance in Intune – To ensure the Company Portal app works correctly, create a compliance policy in Intune. This will allow conditional access policies to function properly and keep devices compliant with security requirements. Without this, users may experience issues accessing corporate resources.

Use SCEP for Certificate Deployment – For a seamless certificate distribution process, leverage SCEP (Simple Certificate Enrollment Protocol) with Jamf Proxy. This ensures devices get the necessary certificates securely, reducing manual work and potential security risks.

Enable Firewall via Configuration Profile – It’s crucial to enable the macOS firewall via a configuration profile and restrict two-way communication to only the necessary apps. This improves security while allowing essential services to function correctly without exposing the device to unnecessary risks.

These steps will help create a more secure, automated, and user-friendly macOS deployment. Let me know if you need further details!

[thebrucecarter]

Thank you, Valcovish.  We don't currently have Intune implemented, although that may be a future direction.  We are currently architecting a solution using SwiftDialog as an informational pathway during builds.  Right now we are using the built-in jamfhelper command, but we need something a bit more informative and flexible.  We are trying to move toward a "no-touch" drop-ship model as part of this migration (in for a penny, in for a pound) so we need to be a LOT more user friendly than we are with technician handled builds.  We have Apple School Manager set to route everything to our PROD Jamf Pro instance, total agreement there.  We thought we had blocked all avenues to user enrollment, but one of our departments found a way around all that (and against our recommendations and guidance) and managed to generate a few issues during the migration.  Again, no Intune (yet, we have done a proof of concept) but possibly someday.  We do have a ton of Microsoft stuff on campus, and our new boss is from a Microsoft shop, so anything could happen.  I will need to pursue the SCEP recommendation with InfoSec, thank you for that.  We do indeed control the firewall (and screen lock, and a few other security settings) with Configuration Profiles.  We're trying to be as light touch as possible while still being good stewards of the security profile of our equipment.

Thank you again for this response!

[sdagley]

@thebrucecarter Regarding your mention of using swiftDialog to report progress during builds, have you taken a look at https://github.com/jamf/Setup-Manager yet?