One of the greatest new enterprise features in OS X Mt. Lion is its support of the DCE/RPC protocol in combination with Active Directory (AD) for use with 802.1x machine or user based certificate authentication. In Lion, for AD certificate based authentication to function, a working Microsoft Active Directory Certificate Services Certificate Authority (CA) with Web Certificate Authority functionality enabled was required. Mt. Lion, through its native support and usage of the DCE/RPC protocol, eliminates that requirement. We recently began a project at my university to increase the security of our wireless networks through the use of Microsoft’s Network Policy Server (NPS) and dynamic VLAN assignments based on users and/or machines verified by AD certificates. Creating a configuration profile using Mt. Lion Server’s Profile Manager to enable this functionality is relatively straight forward, however there are a few intricacies that aren’t well documented in a single place. I’ve detailed below how to configure a Mt. Lion client machine for 802.1x EAP-TLS machine authentication using an AD certificate, as well as some useful debugging information and solutions to problems that we faced during our initial testing.
Building the Profile
Apple has a fairly detailed kbase article on how to build a configuration profile using Profile Manager in Mt. Lion Server to request an AD certificate, so I won’t detail all of the steps. In summary though, you’ll need to configure the following payloads within the profile. I’ve listed them in the logical order in which they should be configured.
This contains the general information about the profile, such as its distribution method and description.
2.) AD Certificate
The AD Certificate payload has a line for “Certificate Template”. This is not simply a descriptive field. This name must match the name of a certificate template that is available for use within the AD certificate store. Apple says within Profile Manager that Usually “Machine” or “User” will work, but we found that those templates did not contain the correct settings for the subject alternative name field of the certificate. More on that in a bit.
Unless you’re including the necessary certificates in another profile that is installed prior to your 802.1x profile, you’ll need to include every certificate that will need to be trusted for the certificate that will be generated by Active Directory to be trusted. You’ll also need to include any certificates that will be used in the TLS negotiation between the client and the RADIUS server. These certificates will often be different than the ones issuing the machine certificate from Active Directory.
This is where you actually configure the network settings. Assuming you configured the payloads in the order I’ve listed them here, you will be able to select the identity certificate after selecting TLS as the EAP type.
This pane is also where you configure the trust settings. You should see your certificates listed and available to be checked for trust. Check the certificates that need to be trusted (most likely all of them), and then enter the FQDN of the RADIUS server that the clients should expect to see during the TLS negotiation.
Installing and Troubleshooting the Profile Installation and AD Certificate Acquisition
To install the profile, you can use a variety of methods. System Preferences is the easiest way (for testing), but if you’re planning on using the ‘profiles’ command line utility, be sure to read the caveats section in the man page, particularly the section shown below. Basically, use sudo when installing a device/system profile.
Certain configuration profiles may be marked as a device profile (system) using the PayloadScope key. However, the profiles tool will ignore the PayloadScope key and install the profile based on how the profile is installed; either a user profile if installed from a user, or a device profile if installed from root (or sudo).
During our first few attempts, the certificate acquisition was failing with the following error:
The 'Active Directory Certificate' payload could not be installed. The certificate request failed.
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.
In the ManagedClient log, we saw the following very helpful entry:
Nov 16 09:14:32:+:::::::::::::::: GetCertificateFromCAServer Failed. Check Failed Requests with request ID 185 in the CA for the reason why
Checking the requests on the CA, particularly request 185, we were able to see the reason. I had originally configured an incorrect certificate template name.
The requested certificate template is not supported by this CA. 0x80094800 (-2146875392) Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy.
After I corrected the profile payload’s certificate template name to be simply “Machine” (I had originally blindly copied the kbase article), the request was successful. The Mac received a certificate generated from Active Directory and was trusted by the system. However, the machine was still unable to connect to the network. There were two reasons, both of which I’ve detailed below.
Troubleshooting EAP-TLS Connections
Fortunately, like most processes on OS X, the process responsible for the EAP TLS negotiation (eapolclient) logs useful error messages to /var/log/system.log. You can also enable more verbose logging by using the following defaults command:
sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.eapolclient LogFlags -int -1
The log(s) will be written to /var/log/eapolclient.[interface].log. To disable the verbose logging, simply change the value to 0. As mentioned above, after I changed the profile to include a working certificate template name, the machine was still unable to connect. eapolclient was logging the following error:
eaptls_handshake: SSLHandshake failed, errSSLPeerAccessDenied
Remember that I also mentioned above that the trust settings payload of the profile must include all necessary certificates that will be needed for the negotiation. I had originally only included the certificates that were needed for the AD-issued machine certificate to be trusted and had mistakenly forgotten to include the RADIUS server’s SSL certificate. I modified the profile to include this additional certificate, and eapolclient stopped logging the handshake error. However, the machine was still not connecting. We discovered the reason to be that the subject alternative name field in the certificate being issued by Active Directory was incorrect. The log on the NPS server read:
Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.
Microsoft has a great document available titled, “Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS“. One of the bullet points under client certificate states, “The Subject Alternative Name (SubjectAltName) extension in the certificate contains the user principal name (UPN) of the user.” By default, the standard “Machine” certificate template in Active Directory is not configured this way. Apple does not have this documented in a kbase article anywhere, but rather on page 34 of its 802.1x whitepaper (for OS X Lion). It reads:
However, it’s possible that the issued certificate won’t have a user or computer name in a form that is acceptable during the initial negotiation. (It’s common to have a required format of “host/ client.domain.com” or “DOMAIN\computername.”) To resolve this issue, you can either specify a user name to be used in the Network payload that is inserted prior to the profile installed, or issue a new template that populates a usable user name.
Because Profile Manager does not allow the entering of a username at all when selecting TLS at the EAP type, let alone something like %AD_ComputerID%, we chose Apple’s second recommendation and made a new certificate template within Active Directory. We duplicated the already existing “Machine” template and titled the duplicate “Mac_Computer”. See this screenshot of the modified settings for the “Mac_Computer” certificate template. Notice that the subject alternative name setting is set to “User Principal Name (UPN)” to match the requirement outline by Microsoft. After I modified the certificate template name setting in the profile to match our new certificate template name within Active Directory, the machine was able to connect to the network. The Subject Alternative Name in the AD-issued certificate when using the default “Machine” template was:
After the change, the Subject Alternative Name in the AD-issued certificate became:
This is an important notable difference; initially the name was the FQDN of the machine, and afterwards it became the user principal name (UPN) of the machine as required according to the Microsoft documentation. If you’re not familiar with the UPN format, it’s different from the FQDN in that it identifies an account to authenticate at/against a particular domain or directory. In reality in Active Directory, computers are users too; special users whose names always contain a dollar sign at the end. So in the case of my test MacBook Pro, rmu-it-mbp-test$ is the computer account authenticating @ (at/against) ad.school.edu (a pretend Active Directory environment).
In closing, Apple’s addition and support of the DCE/RPC protocol in Mt. Lion is a great enterprise addition. It allows for almost seamless functional comparison to Windows when using EAP-TLS with Active Directory generated certificates and does not require the AD CA to be web enabled. Requirements aren’t necessarily well documented in one single place (except hopefully now here), but it’s important that they’re all met. All certificates required to trust the AD machine certificate and any and all certificates that will be presented during the TLS negotiation need to be included in your configuration profile and need to be marked as trusted. The Certificate Template Name in your profile payload must match an available certificate template in Active Directory that populates the Subject Alternative Name field with the User Principal Name. Apple has very verbose logging built into OS X to aid you in troubleshooting issues both with profiles and EAP secured connections. When all of the pieces are configured correctly, they combine to allow for an easy and repeatable process for joining your Macs to an 802.1x EAP-TLS secured network using AD generated machine certificates.