![]() ![]() I hope all the above makes sense, so let’s have a look at how to achieve this! Step 1: CREATE A SIGNING CERT, signed by the built-in Jamf Pro CA This means that the signature on our package or profile, signed by a signing certificate which in turn was signed by the built-in Jamf Pro CA, is automatically trusted as well. ![]() This either by using a publicly trusted signing cert (purchased), an Apple Developer certificate which each Apple device automatically trusts,… or any signing certificate which has been signed by a Certificate Authority which the device already trusts…Īnd this brings us to ‘ using the built-in Jamf Pro CA as Certificate Authority for our signing certificate‘, because in both of the above scenarios ( packages installing during the Setup Assistant and profiles pushed out by MDM) the MDM profile and the Jamf Pro root CA certificates are already installed on the enrolled device. In order for the signature to work, or let’s say to be accepted by the mac/iOS device which is going to install it, it needs to be trusted. In both of the above use cases, signing packages and profiles, there is however one important consideration to make. To avoid this you need to sign the profile prior to uploading it to your MDM server. The result would be that the content of the custom profile you created changes, defeating the idea of creating a custom profile after all. If we look at configuration profiles, we know that an MDM solution like Jamf Pro would sign them automatically prior to pushing them out, so why would we need to sign them manually? Well, there are scenarios where you’d need to tweak an existing config profile, or build a custom one yourself to circumvent a product issue, work around a missing feature (for instance enabling FileVault at login instead of logout via a config profile in Jamf Pro), etc… When you would make a custom profile and upload it to your MDM solution, chances are that the MDM server would try to tweak the profile and add or remove keys which you added/removed prior to pushing it out to your macs. In order to allow the Setup Assistant to install the packages, there are 2 important requirements: the package need to be hosted in a cloud distribution point, and the package needs to be signed by a trusted signing certificate. Note: a must when doing enrolment customisation passing user info from Single Sign On to Jamf Connect. This in contrast to waiting for Jamf Connect to be installed post-enrolment. This allows users to have the most important software or tools installed right from the beginning after initial deployment.Ī great example of this would be the installation of Jamf Connect Login, allowing the end user to provision the mac with a user account through Jamf Connect immediately after the Setup Assistant. Since Jamf Pro 10.9 we can add an installer package to the prestage (Jamf Pro 10.19 and later allows multiple packages to be added), which will install in the background during the Setup Assistant. Well, the first and probably the most important reason, is the need for signed packages to install during the Automated MDM enrolment (e.g. Let’s start with this one: how to sign packages and profiles with the built-in Jamf Pro CA? Although not so new as topic as such, I came across a few discussions with people who did not know this was possible.īefore we dive into the how-to part of things, why would we actually need this? But fear not, I have a few new topics lined up already! I realised that this lockdown period made me slack a bit on keeping the momentum of this blog going. First of all, I hope everyone is still doing well!
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |