Troubleshooting AD Certificate section of a .mobileconfig

pstrombe
New Contributor

We are implementing a new TLS wireless network in a windows environment. I have the windows 2008 r2 running an enterprise Certificate Authority setup to auto-enroll windows laptops; all of which work great.

The problems are with trying to get our mac clients working with TLS:

I've created a .mobileconfig using Profile Manager in 10.8 Server with Network, Certificate, and AD Certificate sections configured. When I run the profile it prompts for a username and password when I did not enable that option in the AD section of profile manager. This should not be the case! The whole point of TLS is that the certificate is a machine vert and not user based certificate. What am I doing wrong?

After prompting for username/password the profile then fails to install and says "The Active Directory Certificate" payload could not be installed. The certificate request failed."

I am stumped trying to troubleshoot this. The mac client's console does seam to have any more info than was in the error message. On the CA I cannot find any event logging a failed request. In the Certifcate Authoirty snap the "failed request" section does not have my info.

I have enabled auditing on "Issue and manage certificate requests" but don't see my requests appearing in any event logs. http://technet.microsoft.com/en-us/library/dd772671(v=ws.10) Where should I be looking for information about why my request failed?

15 REPLIES 15

alexjdale
Valued Contributor III

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?

pstrombe
New Contributor

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?

CFountain
New Contributor

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$

pstrombe
New Contributor

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$

andreroux
New Contributor

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

dwandro92
Contributor III

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>).

Sanchi
Contributor

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

Josh_Smith
Contributor III

@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

vao
New Contributor III

Bump @Josh.Smith, I get the same issue

@dwandro92 any thoughts?

dwandro92
Contributor III

@Josh.Smith @vao

Try this:

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

cclements
New Contributor

@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.

wifichallenges
New Contributor III

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.

arpierson
New Contributor III

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.

wifichallenges
New Contributor III

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.

e308c5cddfab4c179c0c272db35027f1

arpierson
New Contributor III

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. 088b86d172d24db0956f2b8218291fca