Skip to main content

Wondering if anyone else has seen the following behaviour and has a solution. I am requesting a system certificate from a Microsoft CA using the 'AD Certificate' payload within a configuration profile. The Mac is bound to AD and has the appropriate root trust certificates installed for the CA, however the request fails with the following error. This same profile works fine on our Mountain Lion clients so I am wondering is this a feature in Mavericks.



Dec 10 10:33:03[2580:1]:ADCertificatePayloadPlugin.credentialsForDomain domainname = ETF; username = <deleted>$
Dec 10 10:33:03[2580:1]:+ADCertificatePayloadPlugin.getCertificateFromServer
Dec 10 10:33:03[2580:1]:+GetCertificateFromCAServer credentials username = <deleted>$
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer gss_aapl_initial_cred status = 0
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer running as euid = 0
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer ca_name = <deleted>
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer servername = <deleted>
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer cert_template = <deleted>
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer csr length = 629
Dec 10 10:33:04[2580:1]:+Using RPC authn_level: 6
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer partial_string_binding = ncacn_ip_tcp:<deleted>[]
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer using principal name: host/<deleted>
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer dwFlags is ff
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer Calling CertServerRequest...
Dec 10 10:33:04[2580:1]:+GetCertificateFromCAServer CertServerRequest return pdwRequestId = 0
Dec 10 10:33:04[2580:1]::::::::::::::::: GetCertificateFromCAServer ERROR: CertServerRequest exception name : rpc_x_auth_method
Dec 10 10:33:04[2580:1]::::::::::::::::: GetCertificateFromCAServer ERROR: CertServerRequest 382312694
Dec 10 10:33:04[2580:1]:+ADCertificatePayloadPlugin.getCertificateFromServer server returned cert = FAILED
Dec 10 10:33:04[2580:1]:** AD certificate getCertificateFromServer failed
Dec 10 10:33:04[2580:1]:+:::::::::::::::: ADCertificatePayloadPlugin.pdp_pluginInstallPayload returning = -319

I had the exact same issue this morning. The problem was that the DNS name wasn't stored in the AD computer object.
The computer was bound via Casper.
I redid the binding manually, then it worked...



Edit: Out of curiosity, which Mavericks Build is that client running?

I checked the AD object and it has the DNS name set so it isn't that.



It is running 10.9 13A603

Solved it. I had to update the 'Certificate Server' field in my AD Certificate payload to the http address so:



http://<ca_url>/certsrv/



Also on researching this problem I also found that Mavericks will now handle renewing certs although it seems that the user is prompted to allow this - would be nice for this to happen in the background without user acknowledgement. Will test this out soon.



http://support.apple.com/kb/HT5984

Hey @nixonc85 where did you get those logs? I am trouble shooting why our AD Certificate profile is failing, but don't know where the logs I need to be looking at are.



Thanks



Dave

Hey @nixonc85 where did you get those logs? I am trouble shooting why our AD Certificate profile is failing, but don't know where the logs I need to be looking at are.



Thanks



Dave

Hi @dwest, you need to enable mobileconfig debug logging by running the following via terminal:



sudo defaults write /Library/Preferences/com.apple.MCXDebug debugOutput -2
sudo defaults write /Library/Preferences/com.apple.MCXDebug collateLogs 1



Log file is: /Library/Logs/ManagedClient/ManagedClient.log



You might find the following link helpful:



http://www.afp548.com/2012/11/20/802-1x-eaptls-machine-auth-mtlion-adcerts/

Got there, with the logs proved it was MS server issue and resolved that bit. Thanks!

nixonc85 you are a genius and http://<ca_url>/certsrv/ solved my problem! Certs installing all up in hurr!

Got there, with the logs proved it was MS server issue and resolved that bit. Thanks!



What was the MS server issue? We're running in to the same issue here and don't want to use the insecure http workaround over RPC.

What was the MS server issue? We're running in to the same issue here and don't want to use the insecure http workaround over RPC.


Turns out this was a bug in Big Sur 11.0.1. Updated to 11.6 and it worked straight away!

Terms & ConditionsCookie settings