a week ago
Hey everyone,
I’ve set up Jamf Connect with Google IdP following the documentation and tested it; everything seems to run fine. However, I've run into issues during PreStage Enrollment deployment in Jamf Pro. I can’t seem to launch Jamf Connect properly for local account creation to show the Google login screen. Right after the Setup Assistant, it only shows a black login screen with empty fields for user and password. According to troubleshooting, it might be due to the permissions in the package, but since I’m using the official Jamf Connect 2.42.0 package and distributing it through Cloud Distribution Point (Jamf Cloud), I don’t think there should be an issue.
Has anyone had a similar experience and found a solution?
Here is my configuration excluding secrets:
<key>AllowNetworkSelection</key>
<true/>
<key>CreateJamfConnectPassword</key>
<true/>
<key>CreateNewUserHide</key>
<true/>
<key>DenyLocal</key>
<false/>
<key>EnableFDE</key>
<true/>
<key>EnableFDERecoveryKey</key>
<false/>
<key>Migrate</key>
<true/>
<key>OIDCIgnoreAdmin</key>
<false/>
<key>OIDCNewPassword</key>
<true/>
<key>OIDCProvider</key>
<string>GoogleID</string>
<key>OIDCRedirectURI</key>
<string>https://127.0.0.1/jamfconnect</string>
<key>OIDCUsePassthroughAuth</key>
<true/>
a week ago
How are you installing the Jamf Connect package?
Are you installing it in your prestage so that it gets installed during setup?
Do you you have your Jamf Connect configuration profile scoped in your Prestage AND properly scoped so it doesn't get removed after install?
If you are doing all that, when did you upload your package to Jamf? Was it in the last month or so? There is a Product Issue with Jamf 11.11 & 11.11.1 where uploaded packages are not being checksummed correctly and will fail to install in a prestage. It is supposed to be fixed in 11.12, which hopefully will be released soon.
It you did just recently upload the package, contact Jamf support, I think they have a work around to correct the file upload so you can use it in your Prestage.
a week ago
Thanks for you reply! Yes, I've included the package in the prestage, scoped in on the same computers as configuration profiles. But I've re-uploaded the package today and our instance is on 11.11.2... So perhaps that is the issue. I've contacted the support as well, so we will see.
Thursday
So still no response from Jamf support. I’m really starting to question the decision to get Jamf in the first place.
a week ago
If you are using jamfconnect 2.42, it fails to install on prestage. Use version 2.41
Tuesday
Oh really? So both Jamf Pro and Jamf Connect latest versions are bugged? 😳
Thursday
So I've got the same result with 2.41.0 as well
a week ago
If you are deploying a branding package via prestage, it must be signed correctly.
Here is the relevant help files page - Packaging Jamf Connect Files and Images with Composer
and here is a link to Creating a Signing Certificate Using Jamf Pro's Built-in CA to Use for Signing Configuration Profile...
Tuesday
I'm not.
a week ago
@mickgrant jamf connect packages are already signed by Jamf and notarized by Apple
a week ago
Jamf Connect packages are, but any logos or branding being deployed to be used by Jamf Connect must be signed. Which is why I posted the links to the documentation where it says as much
Tuesday
It really looks like the package didn’t even install. Account creation was skipped and admin account was hidden from the user as configured in the prestage. I tried deploying connect version 2.41.0 with the same result.
Saturday
Is FileVault enabled? If yes, this is the expected behavior. If you want the IDP login screen to appear with FV enabled, you must modify your plist. https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Turning_On_FileVault_wit...
Tuesday
Check the management logs. Under history of management logs, you would see something like this if it is installed.
Thursday
Yeah, well the log shows the entry and it’s not failed, but I think the application still isn’t running or maybe it didn’t even install.
Tuesday - last edited Tuesday
cross check jamf connect configuration profile, make sure Idp is reachable on the network and url is mentioned correctly
Thursday
We can now also observe the error with us. Account creation during the PreStage does not work.
Thursday
What IdP do you use?
Thursday
Entra
Thursday
Found the error in our system. In the PreStage Enrollment profile, the distribution point of the Jamf Connect package was set to None....
Thursday
We have Cloud Distribution Point (Jamf Cloud)
Thursday
So the tech support just replied, saying it's probably the same known issue as in version 11.11. They're suggesting this workaround:
PreStage Enrollment packages fail to deploy in Jamf Pro 11.11.0 due to missing MD5 value
Until [the upcoming version] , the workaround is to use Terminal to calculate the package's MD5 value, then use the Jamf Pro API to apply it to the package record.
The MD5 can be calculated in Terminal via the following command:
md5 /path/to/file
You can drag and drop the file into Terminal to automatically fill in the path.
Next, collect the package record from the Jamf Pro API using a GET command against the /v1/packages/{id} endpoint. Copy the resulting XML, and add the "md5" value, then use a PUT command against the same endpoint to insert the MD5 value.
::Workflow example::
The correct checksum can be calculated in Terminal against a package with these methods:
md5 /path/to/package.pkg
shasum -a 512 /path/to/package.pkg
Package records can be checked and updated in Jamf Pro via the API. For example, we'll check for example a package with ID 116, "AdobeReaderDC-latest.pkg":
curl -X 'GET' \
'https://'instance name'.jamfcloud.com/api/v1/packages/116' \
-H 'accept: application/json' \
-H 'Authorization: Bearer <token>'
Returns the following response:
{
"id": "116",
"packageName": "AdobeReaderDC-latest.pkg",
"fileName": "AdobeReaderDC-latest.pkg",
"categoryId": "-1",
"info": "",
"notes": "",
"priority": 10,
"osRequirements": "",
"fillUserTemplate": false,
"indexed": false,
"fillExistingUsers": false,
"swu": false,
"rebootRequired": false,
"selfHealNotify": false,
"selfHealingAction": "nothing",
"osInstall": false,
"serialNumber": "",
"parentPackageId": "-1",
"basePath": "",
"suppressUpdates": false,
"cloudTransferStatus": "READY",
"ignoreConflicts": false,
"suppressFromDock": false,
"suppressEula": false,
"suppressRegistration": false,
"installLanguage": "en_US",
"md5": "dbc11b91d3812a32f31ba077249bba7e",
"sha256": "",
"hashType": "MD5",
"hashValue": "",
"size": "",
"osInstallerVersion": "",
"manifest": "",
"manifestFileName": "",
"format": ""
}
But the actual package could show a different MD5 value when checked locally:
md5 /Users/‘Username’/Desktop/Replication\ Folder/AdobeReaderDC-latest.pkg
MD5 (/Users/’Username’/Desktop/Replication Folder/AdobeReaderDC-latest.pkg) = 56d5629a12bb19d898d155acfa55f503
We would then need to update the package record with the correct MD5 value:
curl -X 'PUT' \
'https://'instancename'.jamfcloud.com/api/v1/packages/116' \
-H 'accept: application/json' \
-H 'Authorization: Bearer <token>' \
-H 'Content-Type: application/json' \
-d '{
"packageName": "AdobeReaderDC-latest.pkg",
"fileName": "AdobeReaderDC-latest.pkg",
"categoryId": "-1",
"info": "",
"notes": "",
"priority": 10,
"osRequirements": "",
"fillUserTemplate": false,
"fillExistingUsers": false,
"swu": false,
"rebootRequired": false,
"selfHealNotify": false,
"selfHealingAction": "nothing",
"osInstall": false,
"serialNumber": "",
"parentPackageId": "-1",
"basePath": "",
"suppressUpdates": false,
"cloudTransferStatus": "READY",
"ignoreConflicts": false,
"suppressFromDock": false,
"suppressEula": false,
"suppressRegistration": false,
"installLanguage": "en_US",
"md5": "56d5629a12bb19d898d155acfa55f503",
"sha256": "",
"hashType": "MD5",
"hashValue": "",
"osInstallerVersion": "",
"manifest": "",
"manifestFileName": "",
"format": ""
}'