Troubleshooting AD Certificate section of a .mobileconfig

We have pretty much the same wireless configuration here. I tried a lot of variations but never found something I liked, since Apple's options are limited.

I eventually wrote a bash script that requests the machine certificate and stores it with the private key in a temp folder, encodes it into the format used by mobileconfig files, and uses XML embedded in the script to create a mobileconfig profile which the script also installs.

One thing to note is that I do not embed any other certificates. I built a package that dumps our chain certs into a temp folder with a postinstall script that installs them to the keychain and configures trust, then the above script is configured as a postflight script.

Since it is a system profile, it automatically adds the necessary System keychain entries, and then the wifi connection is constantly active. Works well, even though Apple's 802.1x supplicant is pretty buggy sometimes.

Also, have you checked Kerberos on the system to make sure it can get a ticket before trying to request the cert? Are your cert templates correct?

Thanks for the info Alex. I figured that my end-product would look alot like yours with configurations generated and then installed by script. Would you mind sharing a sanitized snippet of your code when it creates and submits the request to the CA server?

Also, the client machine I am trying from is joined to the domain. Which command should I be using for testing the Kerberos ticket?

It sounds like your profiles need to be added as a Device Profile and not a User Profile. So try this command in terminal:

/usr/bin/profiles -I -F /path/to/mobileconfig

You may also want to make sure that you have an Kerberos ticket:

klist -l

If not make one:

sudo kinit -k computername$

The profile command returned the following:

profiles.AddAProfile user cannot be found in local DS
profiles install for file:'/Users/pstrombe/Desktop/Settings_for_Everyone-6.mobileconfig' and user:'pstrombe' returned -4570 (The operation couldn’t be completed. (OSStatus error -4570.))

I do have a ticket, but I thought there was a machine ticket too:
nocteam-imac:etc pstrombe$ klist -l Name Cache name Expires * pstrombe@ICSD.K12.NY.US 1148704446:61 Aug 6 20:36:40 2012 nocteam-imac:etc pstrombe$

I have the same problem as above. Did someone find a solution?
Thanks

Check out this guide and read it very carefully. I believe this was the guide that I followed when I was setting this up for my environment.

Key points are listed below:

Template requirements

• "Enroll subject without requiring any user input" is enabled.
• Subject name format: Common name
• Subject Alternative Name: User principal name (UPN)
• Domain computers have Read and Enroll permissions enabled.

Profile requirements

• Make sure the "Certificate Template Name" in your AD Certificate payload matches the "Template name" (not the "Template display name") of the target certificate template.
• Make sure your profile includes the intermediate and root CA's for the certificate you are requesting, and also the entire chain of trust (root + intermediate CA certs if they are different from the client certificate CA's, and the server certificate) for the CA server.

Client requirements

• Machine must be bound to AD.
• Ensure the machine has a Kerberos ticket (<machineName>$.<DOMAIN>).

I had an issue similar to this. The fix was to update the JSS. My issue was on Yosemite running JSS 9.65. Updated to 9.82 and it started working after many work around attempts

@dwandro92 Thanks for the details. I am having trouble with this and I think it may be because of kerberos.

Ensure the machine has a Kerberos ticket (<machineName>$.<DOMAIN>).

I don't have a ticket for the machine, and I get an error when I try to get one:

sudo kinit -k computernameremoved$
kinit: krb5_init_creds_set_keytab: Failed to find computernameremoved$@domain.com in keytab FILE:/etc/krb5.keytab (unknown enctype)

I get prompted for the machine account's password, which of course I don't know. It seems like it is supposed to be in the key tab file, but for some reason it isn't in there. 10.11.4. Domain binding is otherwise working. I unbound and rebound to the domain but no change.

Any thoughts or suggestions about the machine kerberos ticket? Thanks

Bump @Josh.Smith, I get the same issue

@dwandro92 any thoughts?

@Josh.Smith @vao

Try this:

sudo kinit -k -e arcfour-hmac-md5 "$(hostname -s)$"

@Josh.Smith @vao

Hopefully you guys have made progress since, but I opened the keytab file it listed to figure out what was listed in there and discovered that all of the hostname entries are in lowercase.

I then tested the kinit command with an all lowercase hostname and it successfully generated the ticket. Still seeing the "certificate request failed" error, but at least that mystery is solved.

macs being case sensitive is SO ANNOYING... thanks man that totally was the reason i couldn't register a kerberos ticket.

this is from 2016 but did you ever resolve it? i got one machine doing this right now.

I haven't seen anyone mention it, so I'll ask: Are you using the Jamf AD CS Connector to grab the machine certificate from the AD CS template? Using the AD CS Connector negates the need for the device to be bound; the Connector gets the cert on behalf of the device. We have a setup very similar to yours and it's how we get the certs to both our Macs and iPads.

This Jamf white paper will walk you through the process of setting the connector up.

Not sure at all. I inherited this environment. Is there any way to tell if its active inside jamf?

under PKI certificates, i see two connectors but i cant view any properties of them... so not sure.

however i was able to solve the problem by reimaging the device. It can now get keys fine. i spent some hours looking for another way and then just gave up and reinstalled osx.

Sorry that I'm just now getting back to you!

It should be listed in the exact area of your screenshot, so it looks like it's not installed. I can't back this up with anything, but I think that a stock install of Jamf Pro will have the built-in CA and 'Other'. We have a 3rd CA, which is our AD Certificate Authority connected via the AD CS Connector.