none
Certificate Services and Mac OS X clients - Whats the best way to get certs on a Mac?

    General discussion

  • I’m trying to understand how we can get certificates, based on the Computer template, onto our Macintosh OS 10.5.8 workstations (the Windows workstations are no problem).  We are going to use Cisco’s ACS to control which wireless workstations can access our Intranet.  Workstations with a “Computer” certificate issued by our CA will have access to our Intranet; workstations without a “Computer” certificate issued by our CA will be segregated onto a VLAN that can only access the Internet.  (We’re going to be doing something similar with our wired workstations shortly, but my immediate focus is wireless clients.)  The certificate we need is based on the Computer template.

     

    While researching our options, I came across a discussion forum entry, MacOSX and Windows CA, from Tom Ranson (available at https://airheads.arubanetworks.com/vBulletin/archive/index.php/t-1437.html).  There may be another solution available (other than the one presented in the MacOSX and Windows CA discussion forum entry), so feel free to suggest alternatives.  I’m going to include an edited/formatted version (for readability) of the discussion forum posts at the end of this post.  There are three posts in the MacOSX and Windows CA discussion forum entry that apply specifically to my situation:

    ·         Tom Ranson’s initial post on the MacOSX and Windows CA discussion

    ·         Joe Fonte’s questions

    ·         Tom Ranson’s reply to Joe Fonte’s questions

     

    I’m going to be doing a few more tests, but I welcome any suggestions that might simplify the process.  Perhaps scripting for the initial certificate request or the renewal request or anything else that we can explore?

     

    Some background information that may prove useful (the last two bulleted points make more sense after reading the MacOSX and Windows CA discussion forum entry):

    ·         We’re using AD CS on two Server 2008 R2 Enterprise boxes.  We have an Enterprise Root CA and an Enterprise Subordinate CA (used for issuing certificates).  We have about 50K Windows workstations and about 10K Macintosh workstations.

    ·         We have the wireless access working with Windows workstations.  Active Directory and Certificate Services are working as expected.

    ·         As a test, before trying to follow any of Tom’s procedures, I issued a certificate to an XP virtual machine, exported it and installed it on a Mac (our Root CA was added to the Mac previously – so the certificate initially issued to the XP virtual machine would be trusted).  The Mac wasn’t able to connect; the ACS reported that there was a problem with the certificate (the DNS entry in the certificate didn’t match the Mac’s name).  (Our Mac workstations are domain members.)

    ·         Next I removed the Mac from the domain, renamed my XP virtual machine to the Mac’s name (based on our naming standard), got the certificate issued to the XP virtual machine and exported it and installed it on the Mac, removed the XP virtual machine from the domain and added the Mac back onto to domain.  Wireless worked.  Based on this – I’m wondering if the 5 certutil command line entries (in the one‑time‑only modifications section – prior to Step 1a), Step 2a, Step 2b, and Step 2C are actually needed.


     

    Tom Ranson’s initial post on the MacOSX and Windows CA discussion

     

    Funnily enough, I tackled this issue only last week.  We have a large user base of corporate Mac's (OS X 10.5.8 +) which required access to our 'Trusted Devices' WPA2‑Enterprise wireless network.  It was desired that we treat them in the same manner as our existing much larger Windows XP Professional client base - that being with PEAP‑TLS, 802.1x machine certificate authentication.  Due to compatibility restrictions on the Mac client side, we have had to resort to the less preferable EAP‑TLS (i.e. no PEAP tunnel) for these devices - it’s a risk we're willing to take.

     

    It was a real headache to break the back of it; however I can provide you with these notes which should help you.  We are yet to 'polish' the procedure... the client side CSR generation isn't pretty, but it works - and it’s easy for all IT staff to work with.

     

    Our environment consists of a Microsoft PKI; Root CA with 3x Enterprise subordinates (automatic issuing of computer certificates to Windows clients) and now 2x new stand-alone subordinate CA's to handle non-domain integrated clients (i.e. Mac's and Linux machines).  In short, these instructions demonstrate how to enrol and configure machine certificates for an Apple Mac client (tested with 10.5.8 +) and a Microsoft stand-alone CA environment.

     

    This documentation assumes you are working on a fully-patched out-of-the-box client and Windows 2003 R2 Enterprise Edition CA configuration (as of 1st September 2009).  These notes do not cover the implementation of a Microsoft based PKI nor do they address the important considerations which one must take when doing so, so as to avoid common PKI mistakes (which can cause you a really, really big headache in a few years time(!)).

     

    I would like to point out that I am neither an Apple nor a Microsoft engineer, but a Network Engineer by trade ;-)  Anyone please feel free to comment or point out how this could be achieved more simply/cleanly/'just plain better'...

     

    The following one-time-only modifications are required on the Microsoft Standalone CA to enable manual modification of various certificate extension attributes

     

    # To allow the 'Application Policy' of 'Client Authentication' extension in certificate requests (on the standalone CA).

    certutil -setreg policy\EnableRequestExtensionList +1.3.6.1.4.1.311.21.10

     

    # To allow the 'Enhanced Key Usage' extension in certificate requests (on the standalone CA).

    certutil -setreg policy\EnableRequestExtensionList +2.5.29.37

     

    # To allow the 'Client Authentication' extension in certificate requests (on the standalone CA).

    certutil -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.3.2

     

    # To allow the 'Key Usage = Digital Signature, Key Encipherment' extension in certificate requests (on the standalone CA) (*** Believed to be included in the CA policy configuration by default (?) ***).

    certutil -setreg policy\EnableRequestExtensionList +2.5.29.15

     

    # To allow the 'Subject Alternative Name' attribute to be included in the issued certificate.

    certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

     

    Process to request and install an 802.1x EAP‑TLS capable client machine certificate on an Apple Mac OS X 10.5.8+ client

     

    ### Pre-requisite: Mac OS X 10.5.8+ client must be bound to the LDAP domain (Active Directory) and thus will have a computer object in an AD OU/container; we use an asset number for client hostnames/binds etc. therefore this value, for simplicity, must be used here and within the critical fields of the certificate (i.e. the Subject Alternative Name (SAN)).  In our environment (and for the remainder of these instructions) this would be i.e. SCAT-001234, where 001234 is the client ID number.  The Subject Alternative Name must match the FQDN of the computer object within AD ###

     

    Step 1a

    Generate the client CSR using the Mac OS X Certificate Assistant GUI with the CN=SCAT‑001234.your.full.domain.name (and email address = whatever@you.want; perhaps helpdesk@..... etc.).  The certificate 'Subject' value is not important; however it is wise to use a sensible standard convention here to ease certificate tracking.

     

    Step 1b

    Navigate to the web-interface URL of the MS Standalone CA; select 'Request a certificate', followed by 'advanced certificate request'.

     

    Step 1c

    Copy the plain‑text CSR into the clipboard and paste into the 'Saved request' textbox.

     

    Step 1d

    Define the Subject Alternative Name; enter "san:dns=SCAT‑001234.your.full.domain.name" (without the quotes).

     

    Step 1e

    Click 'Submit'.

     

    NOTE:  All Step 2 parts are performed on the Microsoft Stand‑alone CA from the command line.

     

    Step 2a

    After submitting the client CSR, use the following command to add the 'Client Authentication' EKU to the certificate request, prior to approving it.  Note: The contents of the file 'EKU_Client_Authentation.txt' are: "30 0a 06 08 2b 06 01 05 05 07 03 02" (without the quotes) - this is the BLOB string for 'Client Authentication'.

    certutil -v -setextension <RequestID> 2.5.29.37 0 @C:\EKU_Client_Authentication.txt

    Replace <RequestID> with the certificate request ID (found in the 'Pending Requests' section of the appropriate Certificate Authority MMC snap-in).

     

    Step 2b

    After submitting the client CSR, use the following command to add the 'Client Authentication' Application Policy to the certificate request, prior to approving it.  Note: The contents of the file 'Application_Policies_Client_Authentation.txt' are: "30 0c 30 0a 06 08 2b 06 01 05 05 07 03 02" (without the quotes) - this is the BLOB string for 'Policy Identifier=Client Authentication'.

    certutil -v -setextension <RequestID> 1.3.6.1.4.1.311.21.10 0 @C:\Application_Policies_Client_Authentication.txt

    Replace <RequestID> with the certificate request ID (found in the 'Pending Requests' section of the appropriate Certificate Authority MMC snap-in).

     

    Step 2c

    After submitting the client CSR, use the following command to add the 'Key Usage = Digital Signature, Key Encipherment' extension to the certificate request, prior to approving it.  Note: The contents of the file 'Key_Usage.txt.txt' are: "03 02 05 a0" (without the quotes) - this is the BLOB string for 'Key Usage = Digital Signature, Key Encipherment'.

    certutil -v -setextension <RequestID> 2.5.29.15 0 @C:\Key_Usage.txt

    Replace <RequestID> with the certificate request ID (found in the 'Pending Requests' section of the appropriate Certificate Authority MMC snap-in).

     

    Step 3

    Check that the above attributes have been added to the CSR; from within the Certificate Services MMC, select the CSR under 'Pending Requests', right‑click and select 'All tasks' and select 'View Attributes/Extensions').  Steps 2a, 2b, and 2c add a total of 3x necessary *extensions* to the CSR to allow the client certificate to be used for 802.1x EAP‑TLS authentication, and Step 1d adds a total of 1x *attribute* to the CSR (the SAN value) which (in our case) Microsoft IAS/NPS uses to match the client certificate to the computer object within Active Directory.  Once happy, issue the client certificate via the Certificate Authority MMC snap-in.

     

    Step 4

    From the Mac client, retrieve the issued certificate from the CA; choose the 'certificate chain' option (*.p7b).  Open this file with the Keychain Manager application (default) and install the client certificate into to the Mac OS X (10.5.8 or greater) 'System' keychain.  Now, using the Keychain Manager, manually move the client public and private keys (generated by the Certificate Assistant in Step 1a) from the 'login' keychain (of the user who generated the CSR on the Mac) to the 'System' keychain.

    In order for the 802.1x EAP-TLS authentication to function on the client, the *System* keychain must contain:

    ·         The client certificate (issued by the CA)

    ·         The client public key (generated in this case by the Certificate Assistant application; must be manually moved from the 'login' keychain)

    ·         The client private key (generated in this case by the Certificate Assistant application; must be manually moved from the 'login' keychain)

    ·         The 'Root CA' certificate

    ·         The 'Issuing CA' certificate (for the CA which issued the cert; if applicable, all of the CA certs in the certificate signing chain)

     

    Step 5

    Delete all references to these certificates/keys from the *login* keychain - they should only be present in the *System* keychain.

     

    Step 6

    Copy the 'Root CA' certificate to the 'X509Anchors' keychain; our experience has shown that this Keychain may not be 'present' in the Keychain Manager by default (you can locate and 'add' it).

     

     

    At this point, you should have a usable client certificate within your client's System keychain (plus all of the associated parts of a working certificate installation within the System and X509 Anchors keychains).

     

    We have deployed our Mac's with a WPA2‑Enterpise 802.1x EAP‑TLS 'System Profile' defined within the client network preferences; this provides machine-authentication based connectivity regardless of whether or not a user is logged onto the client.


     

    Joe Fonte’s questions

     

    We're looking at the same scenario as Tom.  Cisco ACS will be used to control which wireless clients get access to our intranet (those with a "computer" certificate) issued by our 2008 R2 Enterprise CA.  Non Domain member machines without a "computer" certificate (like personal laptops) will only be allowed Internet access.

     

    So, based on Tom's process, we're going to make a copy of the Computer template, call it something like WindowsComputer for issuing (autoenrollment) to PCs.  Domain member computers will be able to get attributes directly from Active Directory (AD) and everything will (and does - we've tested it) work fine.

     

    In order to get a "Computer" certificate to show up on the Web page (CertSrv), we need to disable getting the attributes from AD and enable supply the attributes in the request (on the certificate template).  (This was based on a Microsoft technician’s response to "why isn't my Computer template showing up in the drop down list on CertSrv".)  I copy the Computer template, name it MacComputer, and configure it to get attributes from the request.

     

    So I'm going through Tom's procedure and I'm wondering...

     

    Are the 5 certutil command line entries (in the one‑time‑only modifications section – prior to Step 1a) needed, and if so, what impact might they have on certificates that might be requested/issued in the future?

     

    Will the MACs be able to automatically renew the certificate when they are getting close to expiring?


     

    Tom Ranson’s reply to Joe Fonte’s questions

     

    The reasoning behind the 5x certutil 'prerequisites' is that we are using stand‑alone CAs to provide computer certificates to Apple Mac (well, any non-Enterprise integrated) clients which are suitable for use in the 802.1x authentication process.  The issued certificates must contain certain attributes to be used for 802.1x (on an Enterprise CA, these attributes would be determined from the certificate template used to issue the certificate, whereas stand-alone CAs do not use certificate templates and thus the information must be included in the CSR 'manually').

     

    # To allow the 'Application Policy' of 'Client Authentication' extension in certificate requests (on the standalone CA).

    certutil -setreg policy\EnableRequestExtensionList +1.3.6.1.4.1.311.21.10

     

    # To allow the 'Enhanced Key Usage' extension in certificate requests (on the standalone CA).

    certutil -setreg policy\EnableRequestExtensionList +2.5.29.37

     

    # To allow the 'Client Authentication' extension in certificate requests (on the standalone CA).

    certutil -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.3.2

     

    # To allow the 'Key Usage = Digital Signature, Key Encipherment' extension in certificate requests (on the standalone CA) (*** Believed to be included in the CA policy configuration by default (?) ***).

    certutil -setreg policy\EnableRequestExtensionList +2.5.29.15

     

    # To allow the 'Subject Alternative Name' attribute to be included in the issued certificate.

    certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

     

    The above 5x certutil commands change the CA policy to allow CSRs to include these additional extension attributes which are required to be present in a computer certificate which is used for 802.1x authentication - by default, these extensions are not permitted by the CA policy.

     

    Note that all we have done here is permit these extensions in certificates which the CA will ultimately issue - we have not yet populated these extensions with the required values (populating the values is handled in Steps 2a, 2b and 2c - this we handle in practice with a short (and very badly written!) script which we run on the CA, providing the CSR ID to modify - if you'd like a copy please just let me know).

     

    I'll be interested to hear about your findings with issuing computer certificates for Apple Mac clients from an Enterprise CA...  Our research concluded that the only way we could achieve this was by using stand‑alone CAs in conjunction with the aforementioned in‑house documentation.

     

    One of the limitations of this approach is that the Apple Mac has no way (that we know of) of performing autoenrollment (which Group Policy does a good job of handling for Windows domain member clients); we must complete this manual process for each Apple Mac client - and also that we must manually renew these client certificates every 2 years.

    Friday, March 19, 2010 7:57 PM

All replies

  • Ladies and Gentlemen,

     

    I have a new quirk which seems easier than your earlier posts, however I could not have gotten there without your advice.


    First I decided against using a computer account to do the certificate and decided to create certificates based on user accounts, these can be created by any user with AD access, but here is the good thing, they work seemlessly on both MAC and PC.

     

    Using User authentication for mac's negates the X509 keychain business making less work for you.

     

    You can use the computer only version for PC's with autoenrollment, I do like that method for PC, but for MAC user based auth is better :) if you like but you would just need two policies in IAS.

     

    As for the Certificate server you can add a new Template within the CA under templates by right clicking and then choosing Authenticated Session if you like.

    This would negate the script. As the the Authenticated session then appears in the WEB GUI interface for the users when they log in.

     

    For more information I am writing a Cisco White Paper detailing all my work which I will add a link to when complete.

     

    Many thanks to all here, you helped me discover what I wanted and I will share my knowledge with you all when the document is complete

    Stay tuned....

     

    Keith Baldwin

    Consultant Systems Engineer

     


    Wednesday, May 05, 2010 7:29 PM
  • Hi Keith,

    This seems like a good solution for user level authentication, but we need the machine to have network access before a user logs in.  We need to be able to push out software, patches, fixes and also have remote control of the machine prior to user login.

    If I'm reading your (Keith's) reply correctly, network connectivity will be established at user login.  Prior to that, no network connectivity???

    Thanks, Joe.

    Tuesday, August 03, 2010 3:52 PM
  • Hi All,

    we are looking for Auto Enrollment of Computer Certificates on Apple MAC clients...could anyone please provide the best procedures for this... Thanks in Advance.

     

     

     

    Sunday, August 08, 2010 11:36 PM
  • Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end.

    I have duplicated the template we have used for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config.

    Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA

    and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile.

    bye

    LH

    PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request.

    Monday, September 13, 2010 4:47 PM
  • Hi all,

    engaged in similar project to include MACOS in our certificate based authenticated WIFI network, I read with a lot of interest the various posts above and I ended up with the following question.

    Indeed if you allow certifcate to be exportable, how do you make sure the machine you are accepting on your network is really the one which it's supposed to be (and you manage as a corporate asset) and NOT an unmanaged machine where someone would have imported the certificate of legitimate asset.

    To keep confidence shouldn't we have unexportable certificates ?  

    Thanks in advance for your help.

    Tuesday, October 26, 2010 8:59 AM
  • Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end.

    I have duplicated the template we have used for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config.

    Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA

    and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile.

    bye

    LH

    PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request.


    Hi LH,

    This thread has possibly too deep for my needs!  But your post has been really helpful for me to know that Mac devices can pickup certs from a Microsoft CA.  So thanks for that :)

    My next query is whether or not iOS devices like the iPad can support autoenrollment of certs over Wi-Fi.  Manually cert provisioning is not scalable for enterprise.

    I'm thinking that they probably dont have this feature support natively but it oculd be achieved through an app?

    Friday, November 05, 2010 1:34 PM
  • Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end.

    I have duplicated the template we have used for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config.

    Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA

    and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile.

    bye

    LH

    PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request.


    Hello LH!

     

    im testing 802.1x with EAP-TLS & Client Certificates with MAC OS X Snow Leopard.

    I'm using an Windows 2008 Enterprise Enterprise Issuing PKI with MS NPS 2008 R2.

     

    I followed your advise but i can't get things working, NPS always reports "Reason Code: 8" "Reason: The specified user account does not exist.".

     

    I don't know whats wrong with my config, are there any additional steps to do?

     

    Thank you very much for advice,

     

    Greetz

    Seb

    Thursday, December 02, 2010 2:27 PM
  • Hi,

    Im trying to get my mac to work, and it following this guide. But im stuck at Step 1d, I dont see anywhere to type the Subject Alternative Name. I have done the one-time-only modifications but with no difference. Im using CA Enterprise.

     

    Step 1d

    Define the Subject Alternative Name; enter "san:dns=SCAT‑001234.your.full.domain.name" (without the quotes).

     

    Thanks for any reply.

     

    Regards

    Ole

    Tuesday, February 22, 2011 1:20 PM
  • Hi all, I have had a hard time to get it working with Enterprise CA, but I have been succesfull in the end.

    I have duplicated the template we have used for windows clients since beginning. Added the SAN in the CertSrv web interface as additional attribute, but never realized that the SAN was ommited by the CA because of it's default config.

    Running following command "certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2" and restarting CA svc enabled SAN on the CA

    and since then I am able to enroll the correct certs and connect with macs to our corporate WiFi using the system EAP-TLS profile.

    bye

    LH

    PS: I forgot to mention, I have used the syntax "host/computerFQDN" for the CN in the request.


    Hello LH!

     

    im testing 802.1x with EAP-TLS & Client Certificates with MAC OS X Snow Leopard.

    I'm using an Windows 2008 Enterprise Enterprise Issuing PKI with MS NPS 2008 R2.

     

    I followed your advise but i can't get things working, NPS always reports "Reason Code: 8" "Reason: The specified user account does not exist.".

     

    I don't know whats wrong with my config, are there any additional steps to do?

     

    Thank you very much for advice,

     

    Greetz

    Seb


    I'm having the same issue, and it appears that the certificate is representing itself as a User, not a Computer certificate. Upon further research it seems that after checking the cert before and after steps 2a-c, nothing has changed. I've run the initial scripts and have been beating my head against this for 3 weeks.  HELP!!!!!!!!!
    Thursday, May 05, 2011 5:43 PM
  • Would you mind pointing me to the documentation on how to set up eap-tls where it uses just the computer cert and does not require the user cert? All docs I've found only show setup with the user cert.

    Thank you,

    NegBit

    Wednesday, August 10, 2011 3:34 AM
  • Would you mind pointing me to the documentation on how to set up eap-tls where it uses just the computer cert and does not require the user cert? All docs I've found only show setup with the user cert.

    Thank you,

    NegBit

    You need to adjust two policies/configurations:

    First you need to configured the authentication server IAS/NPS to only accept computer authentication. Normally configured using security groups in the access policy. Check the "Checklist: Configure NPS for Secure Wireless Access" http://technet.microsoft.com/en-us/library/cc771696(WS.10).aspx for more details.

    Secondly configure the client to only use computer authentication. check this TechNet article on how to configure 802.1x in general http://technet.microsoft.com/en-us/library/cc778073(WS.10).aspx and check the Computer Only in the notes section for disabling user authentication on the client side.

    /Hasain

    Wednesday, August 10, 2011 11:03 AM
  • Hi,

    We have a Microsoft CA structure from wich we issued several user certificates that our mac users use to connect to our wireless network, EAP-TLS.
    The problem we have now is how to renew those certificates. The Mac computers are not member of any domain. Do we have to issue new certificates and remove the old ones?

    /Magnus

    Thursday, September 01, 2011 1:28 PM
  • My apologies for not replying sooner. You know how life gets busy...

    Three of us (me for PKI/Certificate Services, Ernesto for Cisco ACS/wireless networking, and Jack as our MAC specialist) have been doing some testing with the MACs, certificates, and connecting to our wireless network with EAP-TLS.

    We’ve managed to go through a manual process to get the wireless working for the MACs using Tom’s procedure as a framework – thanks for the guidance Tom.

    What We Found Works

    To start with, we wanted to see if we could get a MAC that already had a Computer certificate on it to access our wireless network using EAP-TLS. We did get it to work by doing the following:


    We created a copy (2003 - v2) of the Computer template and called it WirelessComputer
    We configured WirelessComputer to be exportable (private key) and to use AD attributes (DNS name) to populate both the Subject Name (SN) and the Subject Alternate Name (SAN) – I’m guessing either SN or SAN would have worked fine (probably don’t need both SN & SAN – but there’s no harm in having them both)
    We removed the MAC from the domain
    We added a Windows virtual machine to the domain with the same name (and therefore the same DNS name) as the MAC – the Windows machine was issued a WirelessComputer certificate (based on Security settings of the WirelessComputer template and Group Policy being configured for Auto Enrolment)
    We exported the WirelessComputer certificate, including the chain, to a USB stick
    We removed the Windows virtual machine from the domain
    We added the MAC back on to the domain with its original name
    We imported the WirelessComputer certificate, from the USB stick, on to the MAC
    We moved the WirelessComputer certificate and our Root CA certificate to the System keychain – essentially following Tom’s procedure (Step 4) – Step 5 & 6 wasn’t necessary (but remember this is OS 10.4)
    We created the System Profile, using EAP-TLS, and we were good for machine level wireless access

    Cumbersome but it worked. Next, we wanted to try issuing certificates directly to the MACs without running the five certutil commands, outlined in Tom’s post under the heading, “The following one-time-only modifications are required on the Microsoft Standalone CA to enable manual modification of various certificate extension attributes.”

    We thought we could just make a copy of the WirelessComputer template, call it WirelessMacComputer, and configure it to have the SN supplied in the request. This would make the WirelessMacComputer certificate available on the CertSrv web page of our Enterprise Subordinate CA. We were hoping our MACs could hit the web page, request the WirelessMacComputer certificate and go from there. Unfortunately, when we hit the CertSrv web page with the MAC, we couldn’t modify the key length (it defaulted to 512 and Cisco’s requirement was 1024). So, we did the following to get the WirelessMacComputer certificate onto the MAC:


    We used the MAC to generate a request and saved it to a file on a USB stick
    We took the request generated by the MAC (from the USB stick) and using a Windows machine hit the CertSrv web page
    We requested the WirelessMacComputer certificate (Advanced request) and used the FQDN of the MAC for the friendly name – nothing else (we didn’t defined the SAN) – strangely (for I don’t understand why) the SN contained the friendly name we gave the certificate
    The rest was like the above procedure, we exported the WirelessMacComputer certificate from the Windows machine and imported it on the MAC – we picked up the rest from there

    Better, but still cumbersome – and it still doesn’t address certificate renewal when they expire. (Sure you can configure your PKI for 50 years so that renewal isn’t a “real” issue, but management may not approve...)

    We were going to look at creating a scripted solution, based on our findings above, which could be accomplished with a few Windows and MAC scripts. Just to cover the basics, like certificate issuance, revoking, renewal – just for our MACs (we have several thousand MACs and a green user base, any manual procedures are out of the question – our solution needs be totally transparent to the user).

     

    Our current state involves a scripted solution from the MAC end.  It essentially hits the CertSrv site and requests the Certificate and then moves it to the appropriate locations.

    We're still working on the renewal piece, but I'm sure that will involve more scripting on the MAC side.

    Thursday, September 01, 2011 3:00 PM
  • Thanks for the post Joe! We are looking at the exactly same problem as you are. We are going to look into and test to follow Toms guide, hopefully we will get the same result as you. 

    One question... Do the Mac have to be a member of the domain? What i know (was not involved in this before, so please correct me) When the mac becomes a member of the domain i´ve been told that we need to change the ACLs on shared disks. Mac users will get full control of the shared folders where the Creator Owner exists. If this is correct we have a huge work ahead of us to change this if the mac needs to join the domain.

    /Magnus

    Friday, September 02, 2011 8:00 AM
  • Hello Magnus.  I didn't work on the ACLing portion of our MACs, but I know our team that looks after accounts had a heck of a time with setting permissions.  Seems like the behaviour (in terms of file share access for shares hosted on Windows File Servers) between Windows, MAC OS 9, and MAC OSX machines proved to be quite a challenge.  We have several folders that are used for students and staff (for assignments and such) that required specific permissions and trying to set the ACLs on the folders for the 3 OSs proved to be a pain.  The best we could do was get the ACLs to work for any 2 of the three OSs, but then trying to duplicate the user experience for the third OS broke the user experience for the other two OSs (we need to have the end users experience the same regardless of the OS they log in to - since this is a school board, users can log in to many different machines/OSs).  In the end, we had to settle for a "best fit" that the 3 OSs would word with.

    And Yes.  Our MACs are domain members.  The network team has set up the Intranet machine wireless authentication to require domain membership.  The machine must have a valid certificate (which is its DNS entry) and the machine must be a domain member.  This allows us to grant Intranet access to our (trusted/controlled) machines.  We have another wireless network (public) which we tunnel directly to our external switch (i.e. no access to our Intranet) so that we can offer wireless access to students on their our (untrusted/uncontrolled) devices.  This "public" network only requires that the person log in with a valid domain account.

    Sorry I can't help any more with your query...

    Tuesday, September 06, 2011 12:56 PM
  • I'm very close to getting this working in my environment. However, the last gap appears to be the biggest one.

    Our config is based on this Cisco document.

    The primary differentiation was that to ensure rogue devices with valid AD credentials didn't get on the network, ACS is configured to require a machine authentication before allowing a user to authenticate. This is where our autoenrolled machine certificates play their part on Windows - however, I can't get the "machine authentication" side of things to work on OS X. I'm at the point right now where a Mac client is performing the appropriate request to the SSID, and the ACS logs show everything is fine until it does the machine authentication check, at which points it boots the device saying it hasn't been able to verify the machine is authenticated.

    I'm doubly confused because most of the time as I mess about with this, when I try to choose TLS from the 802.1X screen, it tells me I don't have a valid certificate installed on the machine for this purpose. However, somehow I magically made this exact same certificate work earlier today and I was able to do some testing with TLS. I've gone and ruined it now after removing and re-adding the certificate a few more times, and I'm back to the point where I cannot get it to allow me to setup the TLS configuration. Really confusing.

    So, any clues on getting the machine authenticated?



    Wednesday, October 05, 2011 12:58 AM
  • I hate to be one that says "me too", but I'm in a very similar position as D. Mark Douglas.  We had a PKI that only allowed Windows-based computers joined to the domain to connect to wireless through our IAS, and the policy required both the computer and the user to have valid certificates (both auto-enrolled based on AD group memberships).  The request is to expand this to allow Mac's, and eventually mobile devices (iOS, Blackberry, Android).  This discussion seems to be the only one I've found even remotely relevant to our situation (and still being actively updated), but I feel I'm missing a couple of key points.

    Right now, I cannot choose TLS from the 802.1X screen, even though I followed the steps and have a Root CA, Issuing CA (from a newly created standalone CA for this purpose), private/public key pair, and a machine CA in the System Keychain, and the Root CA added to X509Anchors.  The machine is joined to the domain through OD, but obviously something else is missing.

    In the end, since we're also looking to add corporate-controlled mobile devices to the wireless, it seems like this "solution" may have to be reworked yet again, and it all feels very manual.  I'm hoping Joe Fonte can provide more insight to his solution, and I'd love to get in touch with him, since I'm in the same city.  We don't have as large of an infrastructure as the TDSB, but it shares the same complexity.

     

    Tuesday, October 18, 2011 6:38 PM
  • Apple Lion has a ADCertificatePayloadPlugin 

    I am trying to get it working has any one tried it yet it may solve the renewal process if it works

    Description from web page:

    OS X Lion's Profile management feature and the ADCertificatePayload Plugin provide the ability to easily request and retrieve a digital certificate from a Microsoft Active Directory Certificate Services Certificate Authority. For a Lion system bound to Active Directory, this feature greatly simplifies the process of obtaining a digital identity for a computer or user account.

    see

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


    Friday, December 02, 2011 11:40 PM
  • Anyone try this:

    http://blogs.technet.com/b/askds/archive/2010/11/22/ipad-iphone-certificate-issuance.aspx

    Lion client supports SCEP and I'm wondering if Cisco AnyConnect for Mac (which supports SCEP) can help Snow Leopard clients.

    Wednesday, January 25, 2012 10:42 PM
  • We have tried to work through all of this as well with OS X SL but could never get it to work. With OS X Lion server we are using profile manager to distribute a profile w a SCEP payload to OS X Lion clients. We have AD PKI w NDES on W2K8 R2. After a week of troubleshooting we have gotten this to work to authenticate to Cisco ACS wireless w EAP-TLS WP2 Enterprise using the cert. We can also auth to our Juniper SSL VPN with the same cert. Killed two birds w one stone.

    HOWEVER - big gotcha is that even though the cert is marked as NON-EXPORTABLE on the template, from OS X Lion client I can go in to Keychain, right-click on the device cert and export it!!

    This is a show stopper from our InfoSec team. Anyone can then export the cert and "enable" any device to our wireless. Our for that matter, have our cert chain. Not sure how you others are comfortable with having exportable device certs roaming around ...

    Does anyone know why it isnt honoring the template settings??

    TIA - Chris


    Exchange Lover | @ntpro

    Monday, March 05, 2012 2:34 PM
  • @Chris Haaker

    I've never used device certs on OSX before, but I have used user certificates.

    Is the device certificate installed under the login or system keychain? By my reckoning, it should be under the latter.

    Then, standard users shouldn't be able to export the certificate or private key (as they don't know the administrator password required to access the system keychain).

    Also, keep in mind that certificate chains are generally 'public' information. The technical risk of key compromise is minimal. That said, the details of your internal hostnames might be something that IT Security would prefer not to release - if you're paranoid, then some DLP infrastructure may assist you in restricting data flow outside of the organisation. However, normally this is best handled by policy and training (security awareness).

    Wednesday, June 06, 2012 4:08 AM
  • Hi

    i followed the instructions of this post and got the same result . My MAC is unable to connect to my EAP-TLS Wifi.

    It was rejected by the RADIUS server with the followin error : "

    The message received was unexpected or badly formatted

    On Mac side i filled the usernae box with "host/fqdn_of_my_computer" and the 

    User:
    Security ID: Domain\computername$
    Account Name: host/computername.fqdn
    Account Domain: Domain
    Fully Qualified Account Name: Domain\computername$

    What could be wrong ?


    Monday, February 04, 2013 5:31 PM