Yes, the setup for this is pretty lame. I can help if you need any. I have tested on iOS and Mac and it works great.
@kericson I'd appreciate your help, if you don't mind. I installed the proxy OK and added it to PKI. I got the device profile setup with the cert payload, but the profile fails to install. In the server logs, I see repeated entries of "[WARN ] [ina-exec-43] [Credentials ] - We don't want to return an X509 Cert from a PKCS12 data blob"
In the management commands view of the device, I see "Unable to retrieve ADCS certificate for profile payload."
I'm working on getting some screenshots together for you.
Quick steps:
1. Copy a workstation template in your root ca and make sure it set to supply in the request
2. Install the ADCS connector make sure to use the Public DNS name
3. Add the ADCS connector inside of JAMF
4. Create a profile with these certs Root CA, Issuing CA, and the ADCS payload
5. For the Subject, I did $username@mydomain.com
Maybe tomorrow I can add the screenshots.
@kerickson thanks for the quick response.
1. I'm not sure how the CA is setup, but it is generating certs for devices managed by AirWatch, so I copied the template and server name from the airwatch settings. I don't have direct access to the CA.
2. ADCS connector was installed using public DNS name
3. ADCS connector was added inside of Jamf
4. I added all 3 payloads you suggested
5. For subject, I did CN=$USERNAME$SERIALNUMBER as that is what we have working in AirWatch today.
Tested, and still failed. I noticed a few things that may be "non-standard" with my environment.
First, the AD CS connector is behind an F5 load balancer. Its the F5 that hosts the server certificate, and it uses a wildcard cert for all the websites behind it. If I visit the AD CS connector URL from a device, I see the wildcard cert used for the site, not the cert generated during install. I tested using the server cert generated by the AD CS connector install and I tested with the wildcard cert but both failed.
Second, I noticed AirWatch is configured to supply user name and pw for a service account when submitting the cert requests, but Jamf doesn't seem to have the option. I checked the cert template and noticed that only specific accounts have rights to enroll with it. I asked our PKI team to grant the AD CS Connector server system account the rights to enroll that template and will test again once they set it up.
2. Install the ADCS connector make sure to use the Public DNS name
Pardon my ignorance, are you referring to the public-facing DNS name of the Jamf Pro server?
Just to confirm, so my Wifi .1x profile needs to have AD CS, network, and AD certificate payload?
The reason i asked is that at the moment I have deployed machine cert by running a script to a mobileconfig. However, in order for .1x WiFi profile to work, i need to specify on the profile which AD cert to be used for authentication.
Thanks
No need for the AD cert payload. You use the ADCS as a issuing cert in the cert payload. The public DNS name is for the server with the ADCS connector installed on. I have JAMF Pro in the cloud so I have a on prem server where the ADCS connector is installed on with a public dns name.
@khey See if this helps ADCS Guide
@kericson thanks for sharing that ADCS guide. It looks like you granted domain computers permission to the certificate template, do you know what happens if the Macs are not joined to the domain?
I am using NoMAD to keep computers unbound to the domain. I was hoping we could create an Active Directory service account that we grant permission to the certificate template, but I don't see a place in JAMF to enter the service account credentials.
The permissions are for the ADCS server to request the cert, not the computer. You can set the permissions just for the ADCS server I just did domain computers.
For some reason I cant seem to get this to work. My config profile sits as pending..not sure why.....
I too was hoping to have a User Certificate downloaded, but I can also use a computer certificate. not sure what has to happen though if my Macs are not bound to active directory.
anyone know if there are any logs to look at to help determine why its pending.
made a few changes and got the same as above..
Hi guys,
Am using $COMPUTERNAME in the certificate payload hoping that JAMF Pro will actually query the computername and then pass on the information to the Proxy and then the CA to issue the machine certificate. It seems that the certificate that is generated is using the proxy computer name instead of the workstation.
Any pointer?
Thanks
Hi @jimderlatka,
I would check the following:
- You can connect to your proxy over HTTPS 443 from your Jamf Pro (use telnet to test).
- You proxy server can connect to your AD CA? check if the required ports are opened Jamf AD CP
- Check the Security of your certificate template, make sure the Domain User or Domain Computer have read and enroll access.
- Is your test machine joined to the domain and kerberos is active? if not, are you using NoMAD or EnterpriseConnect to have the kerberos active?
sorry just getting back from vacation
non-domain joined... using enterprise connect.
I did have a port blocked which is corrected now, and I am seeing a cert shuttled to the MacBook now.. but its not formed correctly. the details section with common name and email address basically have the server name that the AD CS service is running on... not sure why yet.
@jimderlatka I believe that means your cert template requires an AD machine account to be present in AD. Ask your CA admins to remove that requirement, or create a new template that doesn't include that. Sorry I don't know what the name of the checkbox(es) would be since I also have someone else handle that stuff. But I know I have two cert templates that I've used, one requires the machine account, the other doesn't. When I use the former, it also uses the ADCS server name.
I think I finally got everything I need... I was able to issue the certificate now just like it looks in windows
had to add this to my subject line
CN=$FULLNAME,EMAIL=$USERNAME@Loyalty.com,DC="LOYCORP",DC="local",OU="GTA",OU="Corporate",OU="Users",OU="The Loyalty Group Object"
This basically configured all the details part of the certificate so it looks pretty now.
@jimderlatka tried your fix for my machine based certificate and its still showing the name of the proxy server.....
Make sure your template is a computer template not a user template. In my testing user template didn’t work.
You also need to make sure you're not using a template that requires a computer account in AD.
@jimderlatka i did use $COMPUTERNAME instead of %USERNAME on the payload.
@patgmac could find that option in my certificate template. Do you mean in Security Settings? to allow everyone read and enroll access?
Thanks
@khey I'm not sure honestly. We have 2 templates that I've used here, one worked with ADCS, the other didn't. When I asked my cert guy what the difference was, he said the one that wasn't working required an AD machine object.
@patgmac I think its the Certificate Template Subject Name option "Supply in the request" instead of "Build from this Active Directory Information"
Thanks
Ok. tried everything.. I can get a Computer Template to deploy no problem, but for connecting to wifi eap tls the certificate is missing an nt principal name... I believe I need a user certificate template....
but I cant seem to get a user certificate to work at all....... Has anyone had any luck getting a user certificate template to install......I've tried everything and nothing seems to work.
@jimderlatka Did you try using your variable like computername@yourdomain.com? This will create a cert with a UPN name. My example is $username@acemfg.com
Has anyone tried using this solution to deliver user based (Login Keychain) certs with no user intervention?
