Skip to main content

When deploying a Configuration Profile to request an Active Directory device Certificate from our Microsoft 2008 Certificate Authority, the profile installs successfully and the certificate appears in Keychain Access.



When deploying a Configuration Profile to request an Active Directory device Certificate from our Microsoft 2012 Certificate Authority, the profile installs successfully but the certificate fails to appear in Keychain Access.



We migrated all of the existing certificates, configurations, templates and settings from our Microsoft 2008 Certificate Authority to a separate Microsoft 2012 Certificate Authority, so I'm assured nothing has changed there.



The only lead I have managed to locate may possibly be related to the enhanced security being enabled by default on Microsoft Server 2012 (http://technet.microsoft.com/en-us/library/hh831373.aspx#BKMK_Security).



Has anyone else experienced this issue with Microsoft Server 2012 and ultimately what was the solution? We could disable the enhanced security on the Certificate Authority, but don't really want to unless it's absolutely necessary.

@kish.jayson try the following:



sudo defaults write /Library/Preferences/com.apple.MCX.plist ADCertAuthLevel connect



See below for the different authentication settings that can be used (not sure if OS X supports all of them):
http://msdn.microsoft.com/en-us/library/windows/desktop/ms678509(v=vs.85).aspx



Also make sure you are at OS X 10.9.3 as the managed client code in previous versions is broken and leads to profiles not installing correctly.



Hope this help! Chris

sudo defaults write /Library/Preferences/com.apple.MCX.plist ADCertAuthLevel connect


I tried requesting the certificate after issuing this command on the client but it did not resolve the issue. Is there a way one can determine what keys are available for a particular property list and what values would be considered valid?



For example, how did you determine that ADCertAuthLevel was a key that could be entered into com.apple.MCX.plist and how would I be able to tell what I would put in it?

So as far as I can tell it isn't documented anywhere in the public domain. I got that information from Apple support after experiencing a similar issue. Suggest if you have Apple OS support that you get in touch with them.



It helps to enable debugging of the managed client which might give you more information on what is going wrong, you can do that with (taken from http://www.afp548.com/2012/11/20/802-1x-eaptls-machine-auth-mtlion-adcerts/):



Debug logging for profiles can be enabled with the following commands:



sudo defaults write /Library/Preferences/com.apple.MCXDebug debugOutput -2
sudo defaults write /Library/Preferences/com.apple.MCXDebug collateLogs 1
After logging out and logging back in, very verbose logging will begin being dumped into /Library/Logs/ManagedClient/ManagedClient.log. To disable debug logging, delete the /Library/Preferences/com.apple.MCXDebug.plist file and log out and log back in once more.

Follow up on this topic:



OS X Mavericks does supports the Enhanced Security of Server 2012 right out of the box (helps is you client is bound to the correct AD domain, as was our issue).



OS X Mountain Lion does not support this Enhanced Security, so the feature should need disabled on the server.

Old thread resurrection!



Is this still needed, I noticed we are still running this but all our users are Sierra 10.12.6 or HS 10.13.3

Terms & ConditionsCookie settings