Migrated configuration profiles retain source server signature and cannot be changed in destination

[fleish]

I recently migrated some computer configuration profiles from a staging server to production and all seemed to go well once I took care of missing dependencies. Only later did I notice that on my managed clients in production these profiles were showing as "verified" by my staging server instead of my production server. I engaged JAMF support about this and they confirmed that currently there is no way around this and the recommended way to migrate profiles to avoid this is to download them from the source server & then upload them to the destination server. This method will attempt to create a new profile that will warn about it being read-only because it is signed and also give an option to remove the signature.

I think JAMF migrator should either migrate the profiles without a signature so the destination server can sign them with the appropriate certificate or migrate them with the signature but in such a way that they show up as read-only with the signature removal option such as when the upload function is used (see attached screenshot). I'm not sure if the latter is possible due to the difference between using the JAMF UI vs. the API or if I'm missing something else that is causing me to encounter this issue where others are not but hopefully it can be addressed relatively easily to avoid having to delete & re-upload my computer configuration profiles.

[BIG-RAT]

Are all migrated profiles showing as signed by the server they were migrated from?

[fleish]

Yes, when viewed on the clients that have the profiles pushed to them they are signed by the source server the profiles were migrated from.

[BIG-RAT]

Haven't been able to replicate the behavior. Don't see any signing information in the XML that is pulled from the source server so I'm unable to find a fix at the moment. I've only tried profiles with security & privacy or network or kext (which have other issues) and all show as signed by the destination server once deployed.

[fleish]

Interesting. I dumped the raw XML and the only other thing I see that might be relevant is PayloadOrganization "OUR STAGING" which is the same name that shows up in the profiles on the client machines as "OUR STAGING Verified" which may have led me & JAMF to assume it was signed by the staging certificate. Can you advise where it would be pulling that value from?

[BIG-RAT]

Click Verified (green text) from one of the profiles in question, then expand Details. Check the Common Name (just below Issuer Name). Also scroll down to CRL Distribution Points and see what the URI is. Do those differ from what you see when looking at the same attributes in the MDM Profile?

[fleish]

I was able to confirm the actual certificates are same between the profiles coming from production & are not the same certificates found when looking at machines that received the profiles from staging. So it does appear to be a "friendly display name issue", presumably from the PayloadOrganization valud like previously mentioned. I've still been unable to find where it would be getting that from.

[BIG-RAT]

In the text below the profile name, something something Verified, the something something comes from what's entered in Settings --> Activation Code --> Organization Name. Change the Org. Name and deploy a new profile, it should show up under the profile name. Previously deployed profiles will retain the information that was present when the profiles was deployed. The Common Name I'd mentioned earlier references the Org. Name used when the server was initially set up. Hope that makes sense.

[fleish]

Of course the one place I didn't think to look, just assumed it was the activation code. That indeed looks to be the spot, thanks!

[fleish]

Also, it would be deluxe if there was an option in jamf-migrator to be able to manipulate that value so it could be changed during a push/import.

[thierry-dang]

I have quite a different behavior with signed profiles. I migrated a configuration profile which was signed by a third party (antivirus editor) to a production instance.

On it, the signature is gone, which broke the configuration profile because Jamf modify it.

I need to manually download the signed config profile from the Download button, then import it to keep the signature.

Is it a normal behavior ?

[BIG-RAT]

Yes expected. Profiles downloaded through the API have no signing information. As you've discovered the only way to get the signed profile is through the Jamf Pro web console.