Skip to main content

I'm having trouble getting Jamf AD CS connector to work flawlessly, and wondering if anyone else has a similar use case, and if they managed to solve it.

 

Recently procured Jamf

On-Prem AD

AD CS setup in a different domain, but there is a trust relationship (and it works for other MDMs and bound clients)

Using a domain user account, instead of the local user (AdcsProxyAccessUser) created by the .\\deploy.ps1

 

The domain account has been configured on both the AdcsProxy site configuration, for  oneToOneMappings under system.webServer/security/authentication/iisClientCertificateMappingAuthentication

It's also been modified to be the Identity for the AdcsProxyPool.

 

 

Certs issue successfully, but only if the same user account is a member of the administrators local group on the server.

Jamf Support are saying this shouldn't be the case, but cannot get to the bottom of which permission it needs that's granted by Administrators, that it needs to successfully issue certs.

 

 

 

Any ideas if I've missed something?

 

 

We retired our ADCS Connector spring 2023, but had a similar setup. We had to replace the AdcsProxyAccessUser with a domain account to meet security requirements. It blows my mind that Jamfs script creates and uses a local account for a function designed to work in a domain environment, but I will digress. The account you are replacing AdcsProxyAccessUser with should not need admin access, but it does need access to a few things a typical user account would not have access to.


 


When we were trying to set this up years ago and having a lot of issues, Jamf gave us a copy of their implementation notes. It covered a lot of the configuration Jamf does not formally support. Unfortunately, I probably wont be of much help beyond providing this link assuming you dont have it already.


ol/adcsc/doc at master · jamf/ol · GitHub

Thanks @AJPinto 

 

I hadn't seen that doc, but all the options it mentions for changing it up to be a domain account had already been tried through other testing.

We do seem to have gotten to the bottom of it though!

 

I broke it down step by step, and started to investigate the issue where I could not update the Application Pool identity to be the domain user account, unless that user was in the administrators local group. I would get an error about the credentials being incorrect.

I found this article online - whilst not directly linked to ADCS or Jamf in anyway, the error message matched, and the symtoms seemed to also match: https://cyberark.my.site.com/s/article/EPM-Standard-user-unable-to-change-app-pool-identity-despite-Admin-Task-for-IIS-Manager

 

Based on this, I went and had a look at the permitted users/groups under local policy for "Access this computer from the network", and found that only the administrators group was permitted.

We managed to get the domain policy controlling this setting excluded from this server for testing, and after a reboot, this now showed "Administrators, and Authenticated Users" were permitted.

The password for the domain account was accepted when attempting to change the Application Pool identity, and cert requests succeeded when the domain user was not in the administrators local group.

Reapplying the policy broke it all again - appears we have the smoking gun!

 

 

The policy was amended to include Authenticated Users, and all seems to now be working!
I'm tempted to run the .\\deploy.ps1 script again with the -cleanInstall switch to confirm that everything does work as expected with a new install, but I'm also tempted to say if it's now not broken, why try to fix it!

Reply


Terms & ConditionsCookie settings