Skip to main content

Hi all,



Can I please confirm that by integrating my AD CA to Jamf Pro, does it mean that i can push AD Cert to computers via Config Profile eventhough the computer doesnt have connection to the domain?



We are about to deploy .1x WiFi Profile to use AD cert for EAP-TLS and do have a concern with computers that are not on the network to receive the AD machine Cert.



Thanks



Update
Just to sum it up for other people's reference.



On your Certificate Authority
1. Right click Certificate Template - Manage Template
2. Select Workstation Authentication and Right Click - Duplicate Template
3. Type in the Template Display Name and Template Name
4. Click Security tab - Add Proxy Server computer and set Read, Enroll and Autoenroll permissions (as advised by Jamf)
5. Click Subject Name - Click "Supply in the request" option
6. Close Certificate Template Console - Right Click Certificate Template - New - Certificate Template to Issue - Select your Certificate Template



On your Jamf Config Profile
1. Add Certificate Payload
2. Give it a name, and set your Certificate Subject to "CN=$COMPUTERNAME.my.domain"
3. As a particular application in my environment requires Subject Alternative Name - i set it to DNS name with a value of "CN=$COMPUTERNAME.my.domain"
4. Template Name - as the one you created with the process above.
5. Depending on your CA structure, dont forget to add your intermediate and root certificate payloads so the certificate chain is valid.

Just finished setting up a new AD CS environment last Friday and integrated Jamf's AD CS Connector. Had to troubleshoot some communication issues with the Connector. Lots of good content in here to help with the whole process and wanted to contribute one piece that may help others.



My main issue was getting Jamf to connect to the Connector, I kept getting "Unable to retrieve ADCS certificate from certificate payload" when testing certificate config profiles. As suggested by TravellingTechGuy's blog I looked through the JAMFSoftwareServer.log file and found:



Certificate request ID 05 has failed. (Unable to build an ADCS Connector client.)

.

.

.

Caused by: org.springframework.web.client.ResourceAccessException: I/O error on GET request for "https://jamfpro-adcs.my.org/api/v1/version": PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target


I also looked at C:inetpublogsLogFilesW3SVC2 on the Connector server and found 403 errors from my master JamfPro Tomcat server.



Both of those led me to think there was a certificate trust error. The AD CS Connector requires clients to have a certificate to communicate with it (remember the two certificates you upload to the JamfPro interface). There's the client-cert for the JamfPro Tomcat server to use, and a CA from the AD CS Connector server (adcs-proxy-ca). My master JamfPro Tomcat server did not trust the adcs-proxy-ca certificate so it would not authenticate against it. I run RHEL on all of my JamfPro servers so I am guessing this might by why my server did not trust the adcs-proxy-ca cert after uploading it through the web GUI? Potentially a Windows Server based Jamf environment would not have this issue.



To resolve, I copied the adcs-proxy-ca certificate to my JamfPro Tomcat server (/etc/pki/ca-trust/source/anchors/ is a system directory RHEL uses for certs, so you can copy the adcs-proxy-ca cert here if you want the OS to trust it as well) and added it to the Java cacerts file, followed by a restart of Tomcat.



keytool -import -trustcacerts -cacerts -storepass changeit -noprompt -alias adcs-proxy-ca -file /etc/pki/ca-trust/source/anchors/adcs-proxy-ca.cer

Reply


Terms & ConditionsCookie settings