Account-driven BYOD Enrollment Failing

Did you verify the domain ownership in Apple Business Manager & upload the json file to your webserver (as described here: https://docs.jamf.com/10.41.0/jamf-pro/documentation/Account-Driven_User_Enrollment_for_Personally_Owned_Mobile_Devices.html)? 

I don't understand the need for a web server...

It's strange that Jamf and Apple would ask their customers to do this on their own. This has worked before without a web server setup. 

It's an Apple requirement, nothing Jamf specific but yes. You need to upload a file named 'com.apple.remotemanagement' (with the correct content) to the /.well-known/ folder in the root directory of the website of which you verified the domain in ABM. 

If you run this terminal command: 

curl -I https://yourcompanysite/.well-known/com.apple.remotemanagement

You need to receive an HTTP/1.1 200 OK and the content type needs to be Content-Type: application/json

Once that is ok your account driven enrollment should work.

curl -I https://yourcompanysite/.well-known/com.apple.remotemanagement

Thanks for the info. Just in disbelief that this is a requirement at all from Apple. 

Where can we host this? in AWS? Running into this same issue

Anyone using a landing-page to allow users to pick what environment to enroll?

We are having the same dilema as our web host does not allow the option to host the required JSON file and we are trying to find a solution/ Apple is of no help. How does one host this file outside of the web site host and have it work? I am find little or nothing and we cannot be the only ones with the issue. I am not savvy in the way of hosting and web tech.

We are hosting it on AWS on an S3 bucket in the respective subfolder and make it available via Cloudfront.
Check this: https://www.youtube.com/watch?v=vohNJkr52U8
Starts at 12:20 and the next 30sec explain what to do. 

I am able to host the json file, and get the `

curl -I https://yourcompanysite/.well-known/com.apple.remotemanagement` 

return with 200 response and application/json but it still shows user error 

"Your Apple ID does not support the expected services on this device. Contact your administrator to sign in"

I tripple checked the user-driven account enrollment is ENABLED. anyone has any idea what else went wrong?

But do you host your website with Cloudfront as well? Does the video cover re-directs?

Such a blocker for BYOD....

BTW, the video says we do this and this, with no real details

Same issue here.  As of now, we cannot host a JSON.  I'm not understanding as they say there is a fallback.  I'm not understanding the fallback listed in this document - https://support.apple.com/guide/deployment/account-driven-enrollment-methods-dep4d9e9cd26/web

I thought it is worth to share how we implemented the hosting on S3... My DevOps did put a guide together how we did it. Likely I will not be able to answer on details. 

Setting up Account-Driven User Enrollment involves creating and hosting enrollment information in a JSON file on a web server. This allows devices to initiate a service discovery process to retrieve the information and direct the user to the enrollment portal on their device.

To host the Jamf Pro enrollment information on a web server, the following AWS resources are required:

Create an S3 Bucket:

Follow the guide here to create an S3 bucket that will store the configuration JSON file. Name your bucket after your domain name.

Rename your JSON file to com.apple.remotemanagement.

Create a folder named .well-known and upload your file to this folder. Ensure that the file type is shown as remotemanagement.

2. Create a TLS Certificate:

Follow the guide here to create a TLS certificate in the us-east-1 (N. Virginia) region using AWS ACM. This TLS certificate will be used with the CloudFront distribution.

3. CloudFront Distribution:

• Follow the guide here to create a CloudFront distribution that will serve as an endpoint for the configuration file stored in the S3 bucket.

• Add an origin:

  • Choose the S3 bucket created in Step 1.

  • Select Legacy Access Identity as the origin access type and choose an OAI from the drop-down menu. This OAI will be used in the S3 bucket access policy, which will be updated in the following steps.

  • More info here.

Update the TLS settings:

1. Edit the distribution settings to an alternate domain name.

2. Choose the TSL certificate created in Step 2.

3. More info here.

4. Update Route53 DNS records:

• Create an A record to alias a resource under the hosted zone of your domain.

  1. More info here.

4. Update the S3 bucket policy:

• If you did not select the 'Yes, update the bucket policy' option while updating the CloudFront distribution origin settings in Step 2, update the bucket policy of the source bucket created in Step 1 to allow access only from the CloudFront distribution.

• Use a similar policy to the one below, replacing ABC123 and acme.com with your own values.

• You can your OAIs here.

• More info here.

{ "Version": "2008-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity ABC123" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::acme.com/*" } ] }

→ TEST:
To test the setup, check the endpoint using the alternate domain assigned in Step 2.
i.e: acme.com/.well-known/com.apple.remotemanagement

The expected response would be:

{ "Servers": [ { "Version": "mdm-byod", "BaseURL": "https://acme.jamfcloud.com/servicediscoveryenrollment/v1/userenroll" } ] }