ADCS - Failed to inject certificates into the profile

[valkyrie]

Hi guys

I am out of ideas, I'm hoping someone here can help me.

We use Global Protect in our company, and have set up the jamfconnector to retrieve the certificates.

We have an ADCS configuration profile, which has been working fine up until now. Newly enrolled computers aren't getting their certificates anymore. When I go to check this in 'management' for that computer, I get the error 'Failed to inject certificates into the profile'. Any ideas where the issue could be? Connection to the jamfconnector and issueing server should still be ok.

Thanks!

Valérie

[sdagley]

@valkyrie Is there a configuration in ADCS for the timeout delay before giving up on a certificate request? I was seeing the problem you describe when using the Jamf PKI Proxy for Venafi issued certificates with the default timeout, and increasing the timeout resolved the issue.

[valkyrie]

AFAIK, we don't have a timeout delay configured. Would increasing the timeout do anything then?

[sdagley]

@valkyrie You'd probably want to check with Jamf Support regarding  timeout setting adjustment in ADCS. If your profile has requested  certificate, and one isn't available from the ADCS within the timeout period, that could be why you'd get the failed to inject error message because there's nothing to inject.

[ChrisCox]

@sdagley How would one increase the timeout as you described? I do not see that anywhere in Jamf's documentation for Configuring the Jamf PKI Proxy and Venafi Connection.

Edit: Nevermind. I found the answer by poking around my own server. For anyone wondering, just run the following command replacing ## with the actual number of seconds you want your timeout to be:

jamf-pki-proxy config set --proxy-timeout ##

[jorge_gonzalez]

Hi @ChrisCox nice find! Where did you run this command. We are experiencing the same issues with failed to inject certificates into the profile. Any documentation would be be helpful. Thanks 

[ChrisCox]

@valkyrie You might need to verify that your systems are getting renamed before the push of the configuration profile. I discovered recently that the process does not like default Mac names with spaces in them, e.g. "MacBook Pro" or "So-and-So's Mac Mini", so I had to modify scope for the configuration profile to only include systems that have been renamed properly instead of just all systems since that generally pushes it out immediately after enrollment.

[icolombage]

@sdagley Were you able to resolve your issue? We are running into the same issue on newly provisioned macs, wanted to see if you made any headway 

[sdagley]

@icolombage I think you meant to tag @valkyrie , I'm not seeing any certificate injection issues in my environment after adjusting the timeout in the Jamf PKI Proxy settings.

[icolombage]

@valkyrie Were you able to resolve your issue? We are running into the same issue on newly provisioned macs, wanted to see if you made any headway 

[valkyrie]

@icolombage We managed to get it working again last week. Our system admin team had changed something for our sys-account, but hadn't changed it on the server that runs our Jamf Connector, so the sys-account couldn't get through, and as such didn't get any certificates back to inject into the profile.

[icolombage]

Thanks @valkyrie - we went through our creds and confirmed nothing changed on our end. Working through with Jamf support to identify why it doesn't work consistently 

[rochama]

Hey, have you fixed this issue? Would you mind to share how?

[icolombage]

@rochama what we isolated it to was a timing issue. It seems that the certificate profile was trying to pull a cert before some other policies had run. Our team noticed clearing the pending profiles/policies and allowing it to re-apply resolved the issue. So now we are looking into calling the certificate policy later in our deployment. Not a real resolution to our issue, but it unblocks us to move forward. 

[rochama]

We fixed that but in my case it was a misconfiguration in the SCEP server side, a device certificate was required to make the handshake with NPS server then the cert from SCEP could be issued. There was some minus settings we had to change as well like the Common Name had to have $EMAIL instead of $USERNAME because the NPS server was expecting the user´s email to authenticate. But that´s it it was the SCEP server configuration in the end.

[Jason]

Has anyone seen this when using the Jamf AD CS Connector?  The jamf-pki-proxy command wouldn't be applicable for that, so i'm not sure if the timeout can be increased (or is even an option)

[nexus0000]

we are getting a similar issue using JAMF AD CS but so far have been unable to resolve it.

will probably contact JAMF support and see if they can help out.

[nadsad]

Hi nexus0000,

We also have similar issues and i was wondering if you had help from JAMF Support and if so what was the solution?

[k3vmo]

I'm still fighting with this as well going back and fourth with them for months.   Is there a timeout setting within the ADCS Connector?

[Jason]

Hi @nexus0000 and @nadsad .  I was able to get this working in my environment.  The issue for us was a conflict between Group Policy on the Windows Server and the local account that is created by deploy.ps1

deploy.ps1 creates the local "AdcsProxyAccessUser" account, adds it to IIS_IUSRS group, then in IIS adds it to Sites > AdcsProxy > Configuration Editor > system.webServer/security/authentication/iisClientCertificateMappingAuthentication/oneToOneMappings.

For us at least, local accounts are blocked from remotely logging in.  So we created a new domain service account to get around that.  I then added that account to IIS_IUSRS and gave it the "Allow log on locally" user rights assignment.  I went to the oneToOneMappings configuration and added in that user ID and password, replacing AdcsProxyAccessUser. Lastly, I set the domain in the oneToOneMappings to match our domain.  

All good after that, no more Failed to Inject error.

[nadsad]

Hi Jason,

Thank you for your reply!

Basically we have gotten it to work but its not working that great. It doesn't matter if we run the locally created account AdcsProxyAccessUser or a domain service account (we are using a domain service account).

For some reason the configuration profile doesn't apply most of the times because it has issues getting the certificate but sometimes it works.

Basically what we do - we scope 2 test computers - nothing happens - descope one of the computers and adding it again after - we keep doing this and then suddenly the profiles applies and the certificates are installed and we can see on the Windows Server on the IIS logs that follow entries:
(I have x the IP adresse)

2022-04-20 10:35:32 x.x.x.x POST /api/v1/certificate/request - 443 SVC-ADCS x.x.x.x Java-SDK - 200 0 0 78
2022-04-20 10:35:32 x.x.x.x POST /api/v1/certificate/retrieve - 443 SVC-ADCS x.x.x.x Java-SDK - 200 0 0 31

Do you have any idea of why it's behaving like this?

Could it be firewall issues/routing issues? Cus my thoughts are there to be honest - something like it takes to long to respond sometimes and the config profile fails with the "Failed to inject.."

[UserTBD]

We are experiencing the same issue where it works about half the time, It looks like when Jamf Pro reaches our external firewall, the failed attempts are having SSL/TLS cert issues, and in these scenarios the connection fails. We are using a Sectigo/Comodo cert and I'm wondering if there is a Root cert trust issue on the Jamf side. 
Have you made any progress on the intermittent issues? 

[jhawkinson]

Make sure there is no cached copy of an old/incorrect cert on the Parent or Child AWS node of your Jamf Pro instance. This would contribute to the inconsistent behavior (whenever the node with cached cert tries to service the request). This is a known Product Issue: PI103922, where a child node caches an older certificate. :) 

[nadsad]

Actually we have gotten it to work every time now. The thing is that they made some configurations in the loadbalancer for us from our network team side.

"configure more advanced LB with SSL-offloading, which will inject X-Forwarded-For HTTP header."

But the documentation on this link is very helpful - i think it might help anyone having issues to figure out something :)

https://github.com/jamf/ol/tree/master/adcsc/doc - Jamf ADCSC Implementation notes.pdf 

[bwoods]

Seeing the same issue. Certificate install success is very sporadic. Sometimes it takes 30 seconds and sometimes it takes 3-4 days.

[djdavetrouble]

Hi guys, I was scratching my head on this one and realized the machines were not being renamed by the deployment team. They were getting the default name which contains an illegal character and / or too long, therefore a failed to inject error.

"Tom Jones's Macbook Pro"

[bwoods]

My issue turned out to be a firewall problem. Adjusting the firewall traffic resolved the issue. Even if the machine has a long name like "Brandon Wood's Macbook Pro", it still get the cert within seconds.

[varun1]

@bwoods we have an issue where the JAMF team is suspecting a firewall issue, like the certificate provided by jamf is getting dropped and in ADCS we are getting 403, can you please tell any what changes were made in firewall.

[bwoods]

@varun fixing this issue really depends on what type of relationship you have with your network team. I had to have three 4 hour sessions with my team. Luckily, we had the Jamf Infrastructure Manager configured and used it as a reference for how traffic should move through the firewall. You will need to send them Jamf's documentation and navigate through the firewall rules one by one.