Certificate Services and Mac OS X clients - Whats the best way to get certs on a Mac?
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 onetimeonly 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' WPA2Enterprise 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 PEAPTLS, 802.1x machine certificate authentication. Due to compatibility restrictions on the Mac client side, we have had to resort to the less preferable EAPTLS (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 EAPTLS 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=SCAT001234.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 plaintext CSR into the clipboard and paste into the 'Saved request' textbox. Step 1d Define the Subject Alternative Name; enter "san:dns=SCAT001234.your.full.domain.name" (without the quotes). Step 1e Click 'Submit'. NOTE: All Step 2 parts are performed on the Microsoft Standalone 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', rightclick 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 EAPTLS 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 WPA2Enterpise 802.1x EAPTLS '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 onetimeonly 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 standalone 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 standalone CAs in conjunction with the aforementioned inhouse 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.
March 19th, 2010 10:57pm

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
Free Windows Admin Tool Kit Click here and download it now
May 5th, 2010 10:29pm

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.
August 3rd, 2010 6:52pm

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.
Free Windows Admin Tool Kit Click here and download it now
August 9th, 2010 2:36am

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.
September 13th, 2010 7:47pm

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.
Free Windows Admin Tool Kit Click here and download it now
October 26th, 2010 11:59am

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?
November 5th, 2010 4:34pm

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
Free Windows Admin Tool Kit Click here and download it now
December 2nd, 2010 5:27pm

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=SCAT001234.your.full.domain.name" (without the quotes). Thanks for any reply. Regards Ole
February 22nd, 2011 4:20pm

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!!!!!!!!!
Free Windows Admin Tool Kit Click here and download it now
May 5th, 2011 8:43pm

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
August 10th, 2011 6:34am

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
Free Windows Admin Tool Kit Click here and download it now
August 10th, 2011 7:04am

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
September 1st, 2011 9:30am

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.
Free Windows Admin Tool Kit Click here and download it now
September 1st, 2011 11:02am

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
September 2nd, 2011 4:01am

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...
Free Windows Admin Tool Kit Click here and download it now
September 6th, 2011 8:58am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics