AD/certificated based WiFi authentication configuration profile issue

[bbot]

We're experiencing a couple of issues with our wifi configuration profiles and the renewal process.

1) In our environment of ~600 Macs, we've seen a few people each week that get dropped off of wifi. It appears that the configuration profile we have configured for network is attempting to re-try and fails. a) To remedy this, we normally remove from JAMF, then re-enroll and reboot and this reapplies the profile automatically. Alternatively, we created a clone of our wifi configuration profile and placed it in Self Service to allow people to try to reconnect. However, this did not work 100% of the time. Our helpdesk has a better success rate by downloading the mobileconfig and then installing it locally. Now I'm finding we can't manage these since it was not installed by JSS. What's the best way to clean this up?

2) We're replacing our CA server, which means we need to update all of our certificates. I'll need to upload the new root and sub certificates to all machines and reconnect to wifi. In our last renewal, we found that users that were on wifi were hit and miss for getting their configuration profile updated and were kicked off of wifi in the process. Is there a trick to getting this working 100% of the time?

Configuration profile setup:
Our configuration profile adds the root & intermediate certificate, then uses an AD certificate payload to request the user certificate from our Windows server. Then the "network" payload is configured to connect to the wifi using the AD certificate. (All machines have this installed automatically by JSS and JSS only)

We also have a clone of the profile above that is placed in Self Service. Some machines have had this profile installed locally on their machine outside of JSS by running the .mobileconfig.

[timlarsen]

We may have similar issues at our organization. My main challenge is relying on a user-based config profile and AD certificate template in the first place since we don't have a computer-based ADCS template setup in our environment (on my list of things to test). User-level config profiles, I find, are a bit flakey: they will definitely come down the first time a new, AD user (user-based profiles only work on directory based accounts), but not always subsequent times (for example if you reset MDM). They also will only come down on the login action, and not at any other time which can be inconvenient at best.

What errors are you seeing in your /var/log/system.log when the profile tries to install? I think this will tell you if there was a problem connecting to your AD server, or if there is another problem not related to connectivity.

For us, the Self Service-based WiFi profile has never worked...but I think that's because users only try it when they are not on our internal network and thus cannot connect to our AD server.

Good luck - let us know if you come up with any workarounds!

[bbot]

@timlarsen I'll grab the logs the next time it happens. In some cases I've found Macs that fell off the domain. A simple re-bind to AD, then requesting the certificates will resolve it.

For most cases, it requires un-enrolling from the JSS, then re-enrolling on ethernet to get the configuration profile to push.

How are you handling certificate renewals when your user based certificates expire?

[bbot]

Something interesting. We switched our CA server to not automatically accept requests and go to pending state for testing.

In a 10 minute time span, we found about 25 macs requesting new user certificates. The only thing that would do this is the configuration profile. Has anyone seen configuration profiles trying to re-apply themselves?

Another odd finding. I removed the profile and re-added via JSS and it requests and downloads 3 user certificates.