I've poked around Nation a bit, but haven't seen anyone with this exact problem. Trying to connect to our 802.1x wireless network in Jamf Connect's "Network Connection" dialog with no luck. Entering network credentials does nothing, and no feedback is given from the dialog.
All other devices (Windows machines, phones, etc) connect to this network by initially authenticating with domain credentials (even devices not joined to domain). The Apple OSX devices using Connect are not domain bound.
I'm guessing this may be an issue of pushing out correct certs with Jamf Pro. If so, I'm exactly sure on what certs are needed, and in which manner they should be pushed to machines.
Here are some screenshots of our network and SCEP payloads.
We have a profile specific for the WiFi and associated cert.
There are only 2 payloads:
First create the SCEP payload. We have to use never reissue because it adds the profile ID to common name and our devices get rejected by the network controller. It's worth trying to get it working with renewal if possible.
Then create the network payload
As seen in the final screenshot, the Identity Certificate is the SCEP cert defined within this profile.
@Shane @nwsbear I tried to setup a SCEP profile in my DEV environment, however, I find that the profile just says pending for the computer I have it scoped to. Can't seem to get past that point. Have either of you ran into that? I should note that I have a separate config profile our our network configuration.
I find that the profile just says pending for the computer I have it scoped to. Can't seem to get past that point
Check the IIS logs and Event Viewer on the SCEP Server/Proxy endpoint
We've found that if a profile gets stuck in pending for us its either been:
A authentication issue, the service account stops working and we were seeing 401 errors in the IIS logs
Check the NDES password cache. We were running into a issue with profiles stuck in pending and started seeing a error event viewer/logs on the server a error complaining about the password cache being full:
The password cache is full. Network Device Enrollment Service stores unused password for later use. By default, passwords are stored for 60 minutes. Use one of the existing passwords. If you cannot use an existing password: Wait until one or more existing passwords expire (by default passwords expire 60 minutes after they are created). Restart Internet Information Services (IIS).
We followed some instructions on increasing the cache value from the default of 5 (some online resources say to set it to 50% of your device count) and it seems to have helped (in our particular case)
It's unfortunate that even in debug mode the JAMF server log just doesn't provide enough info on whats happening with the SCEP process when it's failing.
In saying the above, . This was just how we solved the "Stuck in pending issue"
Hopefully theres some info that might help. Good luck.
Thank you, it was the password cache being full. We increased that number and the pending thing went away. We have a user and machine cert being generated now. We had to setup a second NDES for the user cert because we needed a unique OID for the cert. We are using this for our vpn Global Protect so it selects the correct user cert automatically rather than having the user manually pick one since there are multiple certs.
The only problem we have now is the unique OID is malformed so Global Protect can't read it and doesn't select it. We have a meeting with Jamf on this.
We use Aruba brand Access Points in our WIFI network. 802.1x is used to connect to the network through these products and we include users in the network by verifying with a certificate. At this stage, identity and certificate verification is done with an application called ClearPass. The ClearPass application also serves as an MDM server and SCEP server. When we connect to Access Points, the ClearPass application sends a profile file to users via a web interface. Actually the whole solution is contained in this profile file settings. We changed the part specified as "user" in the settings of this configuration profile file, sent to MacOS devices by the ClearPass application, to "system". Thus, as soon as our MacOS device was turned on, the user was able to connect to the network automatically without logging in. If the application you use is ClearPass, I support this article with screenshots. You can use the screenshot below. After making this change, you need to delete and reinstall the WIFI profile on the macOS device. After this step, the problem disappears.