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. (Again, our Windows machines work flawlessly with our PKI infrastructure – so I won’t mention them again...) At a high level, I’ll start with a quick blurb about
Our Environment, move on to
What We Found Works, and wrap up with
What We’re Investigating. I’ll sign off with
To Wrap Up.
Our EnvironmentWe’re running a 2003 domain functional level (native mode) on Server 2003 R2 SP2 domain controllers. Our MACs have been integrated into Active Directory, which is to say that they are domain members. Unfortunately, they’re still MACs – so no Group Policy is applied – and may other nice things...
I added an Enterprise Root CA running Server 2008 R2 Enterprise (which sits idle, doing nothing) and an Enterprise Subordinate CA running Server 2008 R2 Enterprise (which hands out all the certificates). The majority of our MACs are running OS 10.4, so we used this OS as a starting point for our tests.
What We Found WorksTo 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).
What We’re InvestigatingBy this time we started looking for a pre-packaged solution. We contacted HumanIT (
www.HumanIT.com), the company that assisted with our MAC integration into AD, and asked if they had a solution for us. Seems like they’ve done this for other clients already (which means they’ve already done the scripting), but only for OS 10.5 and above. HumanIT will check out a “custom” solution which will include support for 10.4; they feel confident they can deliver the solution. They just have to modify and vet their code against 10.4 (seems like 10.5 is a fair bit different under the hood).
The HumanIT solution deals with both the certificate integration with MAC clients and the generation/creation of the wireless/network/system profile needed to connect with EAP-TLS. We contacted Apple to see if they had any other partners that had a working solution which included OS 10.4, but their other partners were also providing solutions for OS 10.5 and above. We thought about upgrading our OSs, but that’s a lot of time and money (for licenses).
To Wrap UpIt will probably be a couple of weeks before we hammer out a statement of work with HumanIT, but I’ll post my findings if there is anything of interest. Tom, if you’re interested in contacting me, I sent you a message with my contact info to AirHeads (you should be able to pick it up in your messages folder). Anyone else that wants to contact me about this can send me a message (to AirHeads) with their contact info, but I don’t want to post my info publicly.
Tom, again, thanks for your guidance. This MAC thing is a beast.