Post

Replies

Boosts

Views

Activity

Reply to Device Management / Device Assignment / Profiles
Yes I managed to assign the profile to device serial numbers. My problem is that I cannot update or delete a profile. Imagine that I changed the MDM server certificate and now need to configure a different anchor certificate. Or imagine I now want to skip different setup items. My only choice is to create a new profile because I cannot modify the exiting one. In this case, the new profile would replace the old one, but I have no operation to delete this old profile as it is no longer in use. My question is are these update and delete operations possible as the API documentation does not mention them?
May ’23
Reply to DEP MDM Enrollment iOS/macOS
Thank you for the answer. So far, I managed to implement the OTA enrollment mechanism. This includes the following steps for reference: User navigates to the first URL in order to start the enrollment process. User authenticates using the web view. Server returns a payload to request device attributes. Payload is signed using the trusted server certificate. Mobile device POST (first) the requested information. Payload is signed using the device identity certificate (issued by Apple). Server returns a SCEP payload to continue the enrollment process. Mobile device reaches the server to get the SCAP certificate authority. Mobile device reaches the SCAP endpoint with PKCS7 embedded CSR to get signed. Inbound payload is decrypted using the SCEP certificate authority private key. Server returns a PKCS7 embedded X509 - SCEP issued certificate. Returned payload is signed using the certificate extracted from the inbound SCEP request. Returned payload is signed using the SCEP authority. Mobile device POST (second) using the newly issued certificate. Server returns the enrollment profile encrypted using the SCEP issued certificate and signed using the server certificate. Mobile device installs the MDM profile and CHECKIN into the solution. For DEP, the steps are different because the mobile device automatically reaches the MDM server when running the initial setup. With this first request, it directly provides some device attributes. The inbound PKCS7 request is signed with the device identity certificate (apple_identity_cert), and includes an HTTP header x-apple-aspen-deviceinfo where the device information are provided. From this point, the Web UI ensures the user is authenticated. Then, it finally returns the enrollment profile (MDM profile, device identity PKCS12 profile and any additional certificates to trust). The payload is encrypted using apple_identity_cert (because I have no other certificate to use) and signed using the trusted server certificate. In other words, the SCEP part is ignored in the DEP enrollment, which may be my problem here? The enrollment profile is directly returned because the documentation indicates this. Note that the steps above are working for iOS and not for macOS. Let me know if I do something wrong. Thank you!
May ’24
Reply to DEP MDM Enrollment iOS/macOS
I am still struggling with DEP. It is unclear to me how DEP enrollment works. The documentation indicates that the device connects to the configured configuration_web_url, trusting certificates from anchor_certs. From this web interface, the device expects an enrollment profile as defined in the Authenticating Through Web Views. The documentation does not indicate if the returned profile must be encrypted and/or signed. In my case, I return the enrollment profile (MDM payload + PKCS12 for identity certificate + trusted authorities), signed using the server certificate and encrypted using the device identity certificate. This was extracted when the device reached the enrollment URL (PKCS7 content from the HTTP header key x-apple-aspen-deviceinfo). Unfortunately, the MacBook fail to decrypt the encrypted payload. The logs from console seem to indicate that the certificate cannot be found in the keychain. Is there something I could do to unlock this situation?
May ’24