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.
@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.
@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 ##
@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 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.
@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.
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.
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.
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.."
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?
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. :)
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
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"
@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.