The AD CS connector was released a few weeks ago, and I found setting it up to by quite tricky - at least it was for my environment. I want to share my experience in hope it will help others.
AD CS Connector requires Windows Server 2016.
The PowerShell script that performs the installation uses functions that don't exist in earlier editions of the server OS, so don't try to hack the script to make it work on older OS's.
AD CS When you're behind an F5 or similar
My company uses an F5 BIG-IP load balancer to publish internal servers like the AD CS connector to the internet. As standard practice, the public DNS name for the AD CS connector points to the F5, and the F5 NAT's the traffic on to the AD CS connector. The F5 is configured with a wildcard certificate (*.yourdomain.com) from a trusted certificate authority, allowing all sites behind the F5 to be encrypted by this one certificate (and allowing the F5 to inspect all traffic). The AD CS connector uses client certificate to authenticate the Jamf Pro cloud server (meaning, the Jamf Pro cloud server has to present its own identity certificate before it is allowed to access the AD CS connector). If you allow the F5 to play man-in-the-middle, it will block the AD CS Connector from successfully negotiating the connection with the Jamf Pro cloud server. (IIS logs on AD CS connector will display 403 error, unauthorized). To resolve, you need to have the F5 allow traffic from Jamf Pro cloud server to directly hit the AD CS connector, and allow the AD CS connector to present its own HTTPS certificate (self-signed one generated during install) rather than presenting the F5 wildcard certificate.
Permissions
The AD CS connector makes requests to your certificate issuing server using the system account of the AD CS connector host server, rather than using a service account. I'm sure there is a way to make this work, but I could not get it. I had to create a domain service account and change the identity of the ADCSProxy application pool on the AD Cs Connector so that it used that service account. I also added the service account to the IIS users group on the AD CS Connector host server. After making those changes, restarted the site and app pool.
Template Permissions
After setting up the service account, I gave it "Read" and "Enroll" permissions on the AD CS Template. I had tried giving these same permissions to the system account for the AD CS Connector host server, but it didn't work. Using a service account worked.
Certificate Format
If you're using EAP-TLS authentication, you must have the user's UserPrincipalName (UPN) in the subject or SAN property of the certificate. The Jamf certificate payload does not give you the option to specify UPN in the SAN property, so you need to set it in the certificate subject. Subject example: CN=user@domain.com
Bug?
Here is where I hit what I believe to be a bug. I added a device extension attribute to be the LDAP property userPrincipalName. The device inventory would properly display the extension attribute as user@domain.com, but when I used $EXTENSIONATTRIBUTE_# variable in the certificate subject (CN=$EXTENSIONATTRIBUTE_#) I found that Jamf would convert "@" to be "@" so that a UPN of "me@domain.com" becomes "me@domain.com" in the certificate subject. Since "me@domain.com" is not a valid UPN, the RADIUS server could not locate the user and thus did not allow the wi-fi connection. I had to work around this bug (which has been reported to Jamf) by hard-coding the certificate payload to use a service account UPN as the subject (CN=serviceaccount@domain.com). This will cause every certificate to have the same subject, which is not ideal, but at least it works.
Hope this helps someone.
