Self Service - Cannot reach a Jamf MDM server

[mdaymude]

The last post I can find relating to this is from 2017; There isn't a solution there and I've tried almost everything previously listed.

We've been using JAMF for a few years mostly without issue - this is the first time we're seeing this error. There's a similar error "connecting to jamf server" which can be resolved by simply uninstalling and allowing JAMF to reinstall Self Service. No luck on this one. also tested:

computer restart, trying from an IT account (removes any variables from the users startup items), refreshing the MDM, clean uninstall and reinstall of the JAMF Framework.

I did find the list of ports, but we aren't seeing any blocked ports (on machine, router, or via ISP). Issue is present both on and off VPN (so that is irrelevant).

Currently this is only affecting the one machine but as I don't have a fix there's trouble if it spreads. The Mac still has access to jamf controls via terminal, still receiving profiles and policies, still reporting in all information to the server... Self Service appears to be the only thing affected.

If anyone has any idea what this could be I'm open to further troubleshooting.

[gabe2385]

@mdaymude Self service relies on /Library/Preferences/com.jamfsoftware.jamf.plist to show the correct server address, run

/usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf jss_url

 to see if the url is correct.

[gabe2385]

Hey @mdaymude I just tested on my test machine and got the same error as your screen shot by changing the url, was able to run 

/usr/bin/defaults write /Library/Preferences/com.jamfsoftware.jamf jss_url (JamfSERVER)

to fix it replacing (JamfSERVER) with our production server.

[mdaymude]

ran the read on my machine (which is working correctly) to verify the URL... I'm a bit surprised it's just the basic URL to JAMF Pro. Tested the change to incorrect and correct on my machine and verified as well... sent it to the user and he is still having trouble with it... I've remoted in and verified that even with the correct JSS Server listed in the plist it still shows the same error.

Edit: Apologies for my misclicking and such with this site... I haven't had to post here previously so I'm still getting use to the UI. Accidentally marked this as the solution (which I think it likely would be in most cases) but it didn't resolve it this time. There's something else going on.

[junjishimazaki]

On that computer in terminal, what do you get when running: jamf checkJSSConnection

[mdaymude]

"Checking availability of (site)...
The JSS is available."

...this is why it's so confusing to me. I'm not seeing any possible cause and everything else is working correctly.

[junjishimazaki]

It's also stored in Keychain. In Keychain, select Login on the left pane. Go to Keys. Search for com.jamfsoftware.SelfService.privatekey and com.jamfsoftware.SelfService.publickey. Delete those keys and delete the self-service app. I think you can run sudo jamf recon/policy to re-install the app. 

[mdaymude · Accepted solution]

This information allowed us to further troubleshoot and we were able to find the issue!
It is Keychain Access, but it's not the private or public key; the user had a password enrolled for automatic login to Self Service. We don't use the user logins on Self Service (it has been enabled for techs, but not for standard users and isn't built out enough for regular use). Removing the login password from Keychain Access resolved the issue.
From what I can tell, it seems someone tried to log into Self Service, and saved credentials which don't actually work there. Further attempts to open Self Service were relying on those credentials and those were being denied by the server... so it gave an unable to connect to MDM server error as a result.

Resolution:
Verify that the jss_url is correct in /Library/Preferences/com.jamfsoftware.jamf
Verify Keychain Access keys are correct (publickey, privatekey, and login if used. If your company does not use logins verify that any login keys are removed).

Massive thanks to gabe2385 and junjishimazaki for their assistance.

[junjishimazaki]

I don't remember self-service allowing automatic login but I'm glad you figured it out. But, my org does the same, we don't allow logins to self-service except for IT. 

[ncats_lab]

This is not working for us.

The URL is correct in  /Library/Preferences/com.jamfsoftware.jamf.

checkjssconnection shows connected.

deleting the app and keychain logins and re-installing (jamf policy; jamf recon) does not fix the issue. 

We do not have any form of login to Self Service set up.

[pbileci]

We have this issue, too. Removing the keychains for Self Service worked for me. Previously, I had removed the Macbook from Jamf, removed the freamwork, then re-enrolled it. That works, but it's more time-consuming. So I'm glad the Keychain fix worked.

[jonifast]

We are also seeing the same problem with several Macs. 

Removing keychains and the app did not work for us and login was never enabled.

This happened without any changes to the environment.

[ncats_lab]

We found the issue for us - The problem was our SSL cert. We had to rebuild our p12 SSL cert to use include the intermediary ssl cert. 

openssl pkcs12 -export -out certificate.p12 -inkey privkey.pem -in fullchain.pem

[pbileci]

Why would this be an issue for some Macbooks but not all of them if they all have the same certificate? When I remove the framework, I also remove all profiles, so it should push a new SSL profile to them once I re-enroll in Jamf. That's probably why it works when I do that.

[ncats_lab]

The SSL Cert installed on the Server - not the Mabook. 

<jamfURL>/tomcat.html

[musat]

We wind up getting this same error message on scattered Macs in our district. Sometimes reenrolling them clears up the issue, but not always. Really trying to find some "permanent" solution for this error. We are Cloud hosted if that makes a difference.

[ManOfTheNight]

Having the same issue here luckily with just one device, intermittently. Self service app re-installation, jamf policy/recon, and/or removing Keychains has not solved the issue at any time.

Wiping and re-installing the same device has solved the issue at times, but again after wipe the issue could come back again. I can't see any real reason why this happens intermittently, with the same device and same user account being used. Luckily the device at hand is just a test-device and not a remotely sent one which would need re-installations from time to time.

I'd love to find a reason and a way to fix it without wiping (or re-wiping).

[ManOfTheNight]

Replying to myself after a few test runs. At least with our devices, this issue seems to happen because of specifying some Computers to Scope / Targets under Policies.

When Wiping / Re-installing, it also replaces the computer's name to defaults, so it isn't the same as it was limited in Scope / Targets, thus "seems to function again normally" with Jamf Self Service.

We are using these specific Targets with test computers - making sure new additions or changes in Jamf is functioning correctly before deploying it to all computers (or specific Groups).

I hope this information can help someone in these forums, and also wish that Jamf could check it out and perhaps fix the issue from happening after some future update. There might also be something we're doing wrong because Jamf allows it.

[AllSaints]

This last week we have seen the same thing on 2x 2018 MacBook Airs.

We were able to fix by deleting MDM profiles and re-enrolling as per

- https://easyosx.net/2022/03/14/profile-installation-failed-new-profile-does-not-meet-criteria-to-rep...

- https://community.jamf.com/t5/jamf-pro/cannot-remove-profile/m-p/243119

Seems like we aren’t alone and we are all asking why?

Jamf support case: CS0817324

[AllSaints]

Now 3x MacBook Airs.

Jamf support case: CS0817324 moving very slowly (almost in the forwards direction)

[dwight_banks]

Was this case resolved for you? 

[AllSaints]

Support focused on Configuration Profiles being applied at User level and deployed through Self Service. We had an older WiFi configuration Profile (with expired NPS certs) which we changed to Computer Level and we didn't see another occurrence of the issue. There was also a few updates to jamf pro during that time.

As a side note. It was both convenient and concerning to learn that we could remove the MDM Profile and re-enroll the device without having to re-image the computer.

[Jawalker]

I had this same issue today with a new profile i created on a MacBook for testing. Simple solution, Z Scaler was blocking all internet access until I had signed in. Thought I would add this just in case others are using the same software.

[mdaymude]

I've definitely seen this as well since my original post.
for zScaler setups we have everything set and tested before installing zScaler. If it's "installed and running but not signed into" it blocks SSL, not "all internet access" but will still destroy any attempt to get into most things. depending on the company settings, once signed into it may lock the ability to turn it off. If there is a compliance requirement in place zScaler will still allow the sign-in for itself, but since "compliance isn't met" by the machine for other reason it'll continue to block. You can end up with a deadlock situation where zScaler says "you aren't allowed to work because you aren't in compliance, and you can't get in compliance because the JAMF access you need (or other things) to become compliant (like Company Portal) isn't going to be allowed.

Really frustrating.