Custom mobileconfig profiles being filled with random settings.

[TechnoKhan]

Good day and thank you for taking the time to read this!

I am trying my hand at modifying configuration profiles manually. I create a base template in JSS, download it, convert to xml and strip out all the stuff I don't want. I then rename it with the mobileconfig extension and upload it as a custom configuration profile in JSS. I then scope it, push it down, and it appears. However, the problem comes in when the configuration profile for some reason changes from the time I edit it to the time it gets uploaded and pushed down. Settings that I had cut out were added and ones I wanted in, were not.

Does JSS modify a custom profile to any extent when uploaded? Or am I missing the proper way to do this entirely?

A quick example is I am setting up a configuration profile that enables iCloud Keychains + allows for Safari Autofill. These are the only two settings aside from the xml's normal metadata. When I take a look at the settings once it is installed, its cleared out some of what I had and added in its own settings.

I am just wondering if I am missing something or if there is a step or practice I have missed. I appreciate any assistance with this and any input is welcome!

[mm2270 · Accepted solution]

Hi. Yes, this is a thing that happens, and yes it is because the Jamf Pro server is modifying your custom .mobileconfig file to conform to its own internal payloads. So unfortunately it ends up putting all of that stuff back into the profile that you just deleted or just chose to not have there. This is a big pain in the butt, and I wish it did not work this way.

The only way to prevent this is to lock the config profile with a signing certificate, before you actually upload it to your server. This locks the profile and prevents Jamf Pro from making any modifications to it. Unfortunately this has an additional side effect. You are not able to make any changes to the config profile inside the Jamf Pro UI. It will show up as locked, and if you choose to unlock it within the UI the server will then dump all those other settings back into the profile again. That means the only way to make changes is to modify the local mobile config on your system and re-upload it. And, I’m not certain, but I think you must delete the profile and then re-upload it. I don’t think you can overwrite the locked profile. I might be wrong about that, because I don’t know that I’ve actually tried that anytime recently.

The whole thing is a PITA. But currently the only way to prevent the unwanted changes is the way that I just outlined.

Hope that helps a little.

[sam_g]

From my understanding, if you do not sign the custom config profile, Jamf will mess with it. If you sign it and upload it, it'll remain intact.

[mm2270 · Accepted solution]

Hi. Yes, this is a thing that happens, and yes it is because the Jamf Pro server is modifying your custom .mobileconfig file to conform to its own internal payloads. So unfortunately it ends up putting all of that stuff back into the profile that you just deleted or just chose to not have there. This is a big pain in the butt, and I wish it did not work this way.

The only way to prevent this is to lock the config profile with a signing certificate, before you actually upload it to your server. This locks the profile and prevents Jamf Pro from making any modifications to it. Unfortunately this has an additional side effect. You are not able to make any changes to the config profile inside the Jamf Pro UI. It will show up as locked, and if you choose to unlock it within the UI the server will then dump all those other settings back into the profile again. That means the only way to make changes is to modify the local mobile config on your system and re-upload it. And, I’m not certain, but I think you must delete the profile and then re-upload it. I don’t think you can overwrite the locked profile. I might be wrong about that, because I don’t know that I’ve actually tried that anytime recently.

The whole thing is a PITA. But currently the only way to prevent the unwanted changes is the way that I just outlined.

Hope that helps a little.

[jtrant]

Currently having the same issue. I cloned the policy in question, downloaded, converted, made the changes, signed and tried to upload, but I'm getting an "Unable to create object from file" error. This is after deleting the cloned policy to avoid a UUID conflict. The XML looks good and installs successfully on my local machine manually.

Anyone run into something similar? We are running Jamf Pro 10.4.0. Apparently the issue with Jamf modifying preferences not specified in a payload is fixed in 10.6 but since 10.4 is working great in every other way, I would rather avoid introducing more potential problems.

Thanks a lot!

[mm2270]

Apparently the issue with Jamf modifying preferences not specified in a payload is fixed in 10.6...

Really? I hadn't seen that. I'm going to take a look at the 10.6 release notes to see if that's mentioned anywhere. If that's true, that's great, because it will help a lot with using custom created profiles.

[mm2270]

@jtrant Can you elaborate on what you may have heard about this being fixed? Or did you mean something else in your post above? I just looked through the 10.6.0 and 10.6.2 Release Notes and I'm not seeing a mention of this particular issue being addressed. I do see some specific problems being fixed, such as "Fixed an issue that could cause a computer's camera to become disabled when the Security & Privacy payload of a computer configuration profile was configured." but that's definitely not the same thing of course. Just wondering if it was something you heard from support but it wasn't included in the release notes. Thanks.

[gachowski]

just as an FYI... you can sign the profiles with apple configurator.... also not 100% sure but I think I have seen the "Unable to create object from file" error when the profiles have the same name... or same data as a profile all ready in the JSS...

C

PS while changing the default behavior of Jamf Pro is a good idea I am not sure it's a long term solution.. the real question is why are so many admins making custom profiles.. and the answer is please vote this up...

https://www.jamf.com/jamf-nation/feature-requests/6281/break-up-multi-mdm-payload-gui-payloads

[mm2270]

@gachowski I 100% agree that the entire issue would be moot if Jamf changed the way they have config profiles set up. We're (mostly) only creating custom profiles specifically because too many things get enabled/disabled in a default profile that you never had any intention of touching in the first place.
But I get the feeling Jamf won't change this anytime soon unless Apple revamps the way their profile manager stuff works, and good luck on that. So in the meantime, if Jamf Pro didn't muck with the custom profile, it could help us a bit.
At least there is a workaround, albeit a bit manual and ugly. It seems silly that we have to lock the server out from doing what it was designed to do though.

[TechnoKhan]

Thank you all very much for your input on this. It certainly answered the question and made me feel slightly more sane. I thought I was going nuts and just doing it wrong, repeatedly.

I have yet to try signing and uploading it. So I am going to give that a shot today or tomorrow if time allows. I would be most interested, along with the rest of you, in a feature that just didn't mess with our custom profiles. I up voted the link from @gachowski That is a perfect example of why it is nuts this has gone on this long.

I really appreciate all the information and will post back once I try signing and uploading again.

Thanks!

[patgmac]

You can also create/modify and sign profiles with https://github.com/erikberglund/ProfileCreator. It gives granular control over every setting.

[cdev · Accepted solution]

You can manually sign custom config profiles from the command line:

/usr/bin/security cms -S -N "name of signing cert" -I /path/to/profile.mobileconfig -o /path/to/outputfile.mobileconfig

If you have an active Apple Developer Certificate, you can copy/past the name of the certificate (spaces, parenthesis and all).

[TechnoKhan]

Thank you all once again for assisting me with this. Signing the profile worked as everyone said it would. I ended up using the command line given by @cdev though I had found it elsewhere. I am going to mark it solved as this may hopefully help someone else who ran into this issue.

Thanks!

[thomH]

Hi

Little unclear about this - does the signing only need to occur when you upload a complete config profile and NOT when you create one in Jamf and upload an xml to the 'Custom Settings Payload'? I have only done the later and never encounter anything about signed VS unsigned.

Thanks
UPDATE: This was clarified for me as on applicable to from scratch, new profiles. Custom payload edits do not apply.

Cheers,