More configuration profile issues

I'd split up the certs, have a separate configuration that installs the certs at the same time as you install the Wi-Fi profile.

We do it all in one profile and we install using the Apple profiles command, we don't push via config profile using JSS.

Given the issues we have pushing config profiles, we wanted something that would definitely work consistently. I'd highly suggest trying to install manually via script.

@qhle373 Which certs would you split into a different configuration profile? The screenshot above is a look at our current config. 2 payload for network (wifi and one for wired), the certificates are the intermediate and ca-root, and the last is our AD.

@CasperSally If you do not push, does this mean when your user certificates expire, you have to manually install certificates on everyone's machine?
I've tried scripting this, but we'd have to generate the certificates as the user and it prompts for admin password. I wasn't able to figure out a way to run the "profiles" command as the user and bypass admin credentials. Not all our users have admin credentials which means we'd have to help ~200 users enter in the password to generate the new certs.

If I were to remove the settings from the original configuration profile and select "only deploy to newly assigned devices", does anyone know if this will update laptops that have this existing profile too?

@bbot

We export and install config profile as part of imaging process. The config profile is installed as package during imaging, and then part of a post image script post image installs and then deletes it. The certs running out haven't been an issue, but we reimage every year and our cert is 2 years.

If you wanted to do same workflow outside of imaging you could

• Export your config profile from JSS
• Make a package to copy the config profile to something like /private/var/profiles/config.mobileconfig
• Then create a policy with the package with config profile and a script that does following which will run as root.

#!/bin/sh
/usr/bin/profiles -I -F /private/var/profiles/config.mobileconfig
sleep 20
rm -r /private/var/profiles/config.mobileconfig

Note: JAMF has told me that having config profiles with certs in them in the JSS, even scoped to nothing and set to install only via self service can cause strange config profile issues when pushing other profiles. I removed them but still see the same config profile issues so not sure on that.

@bbot They won't get the new cert if "only deploy to newly assigned devices" unless you change the scope.

We use 802.1x & have an internal CA issuing certs to our clients & that CA used to expire annually.

The 802.1x settings, Root CA cert & AD Cert request are all in separate profiles & all deployed via the JSS.

When we've needed to update the certs we've updated the Profile then pressed "Deploy To All", that's work for the past few years.

Are you sure that Casper pushed the profile & that is wasn't downloaded & installed in another way? OR has the JSS changed?

@bentoms The configuration profile was pushed through the JSS. After working with Casper, we found the cause to be in the sql database. They sent me a command to clear out ~9000 bad entries in the database and the configuration profile appears to be okay now.

Now I'm dealing with another issue..."The 'Active Directory Certificate' payload could not be installed. The certificate request failed." It is happening to about 25% of my machines, and seems to be more common when pushing to machines that are on wireless instead of a wired ethernet connection. Looking at the cert server, there are no error logs so it looks to be getting stuck at the local machine. The only way I've been able to replicate this error is if I delete all the kerberos tickets on my test machines. Is it possible that machines are missing kerberos tickets causing the cert request to fail? I'm fairly new to certificates / network configs and any help is greatly appreciated.

I have 2 more days until the certs expire and I'm rushing to find an answer.

10 out of 12 times, I was NOT able to request wifi certs if no kerberos ticket was present. 2 out of the 12 times it did generate without a kerberos ticket. I was always able to request wifi certs when I had a kerberos ticket.

@bbot i'd check the ACL's set on your cert templates to see who can grab/request.

@bentoms I'll have our windows server admin take a look. If the certificate request failures aren't hitting the server, wouldn't this mean it's failing at the client level and not the server level?

@bbot Is this a Windows CA? You should be able to see the log entries for the requests on the server.

I have some details on this here.

@bentoms Yes, Windows CA.

I had our server admin look into the failed requests and she said they were unable to find any error logs. The error i'm seeing on mac machines is "AD certificate getCertificateFromServer failed"
GetCertificatefromCAServer ERROR: CertServerRequest 382312694

Thanks for the link!

@bbot No problem. Keep us posted.

That request number should be searchable on the CA's logs.

@bentoms Pulled the logs on the server, the only logs that were available on the CA show errors when I tried generating a computer level cert instead of a user cert, which is normal behavior since we have it set that way.

Our certs are expiring Thursday, so our current course of action is to push out the certs tomorrow, and we'll have to manually configure the ones that fail.

If we wanted to phase out a configuration profile that includes network settings, what's the best way to do this? We basically want to make it inactive, but do not want to remove it from user's machines as it will disconnect their wifi.

@bbot you cannot via profiles afaik.

@bentoms Gotcha, got the same response from our jamf support rep. As our certs are expiring tonight, we're manually enrolling Macs through a configuration profile in Self-Service. Quite painful, but I felt it was better than pushing out the certs and running the risk of having a high rate of failure.

Our new intermediate and root certs are good for the next 10 years, so going forward when the user certs expire, we can have them generate a new cert through "Profiles.prefpane" on the Mac. Next question is to figure out how to script this into a jamfhelper popup so they can click one button and be done... I know there is a profile expiration notice and users can click into the Profiles section and click Update, but I'd like to make it one more step simpler for them.

Thanks again for all your help!

@bbot No problem!

We went from annual expiry to a 20 year root this year.

So, so happy to make that change. :)