Articles,OS X November 20, 2012 at 7:00 am

802.1x EAP-TLS Machine Authentication in Mt. Lion with AD Certificates

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.

1.) General

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.

3.) Certificates

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.

4.) Network

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[19406]:+:::::::::::::::: 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:

rmu-it-mbp-test.ad.school.edu

After the change, the Subject Alternative Name in the AD-issued certificate became:

[email protected]

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).

Summary

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.

Mike Boylan

Mike Boylan is a recent graduate of Robert Morris University in Pittsburgh, PA where he received his Master’s of Science in Competitive Intelligence Systems. Mike is a senior systems engineer for the University focusing on core University server infrastructure and telephony. He also still administers and manages all of the University’s Macs. He’s been doing Mac systems administration for over eight years, having worked previously for Fox Chapel Area School District in Pittsburgh, PA. Fox Chapel holds one of the largest Mac deployments in the Pittsburgh area. When not at work or in class, Mike enjoys spending time with friends and exploring new restaurants. He’s also active in and passionate about Pittsburgh politics. He proudly volunteered for the Bill Peduto for Mayor campaign in 2012/2013. He’s on Twitter at @mboylan.

More Posts - Website

Follow Me:
Twitter

12 Comments

  • Hi Mike,
    I ran across this article when searching for some information about using machine authentication with Active Directory and wireless Mountain Lion clients. I seem to recall seeing some posts from you elsewhere saying that you never really had the chance to implement this, because some other projects came up. I was wondering if you’d ever had the opportunity since then, and if so, if you’d be willing to share some insights with me? I’m having a heck of a time getting it going. Part of my problem is that I’m fairly clueless when it comes to certificates, so I’m kind of taking shots in the dark. I *think* I have it set up correctly, but my wireless Mac Mini refuses to authenticate. I’m using a Meru Identity Manager (IDM) virtual appliance, which works GREAT with my Windows machines, but I’m not having much luck with the Macs.

    I’ll be happy to provide more details if you’d like to know.

    Thanks!

  • Hi. I’m actually trying to follow carefully your post but I’m stuck with the creation of the new template. I select the “Computer” template > Duplicate Template > Windows Server 2008 Enterprise ; in the “Subject Name” tab, I choose Subject name format : Common name and I check the two checkboxes “DNS name” and “User principal name (UPN)” as described in the screenshot. The template is named “MacComputer”. But when I use this template in the profile (instead of “Machine”), the request fails. Is there any other setting to apply to the duplicated template ? Best regards.

  • Very useful post … we have followed your tips for 802.1x troubleshootings (PEAP/MSCHAPv2) under OS X 10.7-10.8 in the last few weeks.

    Under Mavericks, however, the command:

    sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.eapolclient LogFlags -int -1

    SEEMS to enable the verbose logging:

    04/11/13 10:46:41,673 eapolclient[535]: Verbose mode enabled (LogFlags 0xffffffff)

    BUT there are no eapolclient.en0.log and eapolclient.en1.log files in /var/log/ … do you have any ideas?

  • If the CA is Server 2012 or 2012 R2 it needs addtitional setting

    certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST

    as per http://technet.microsoft.com/en-us/library/hh831373.aspx#BKMK_Security

    Also .mobileconfig was installed as user, at which point it CA issued certificate to the user (even template is copy of Computer one)

    That does not connect me to wireless network, with NPS server erroring:

    Authentication Details:
    Connection Request Policy Name: NAP 802.1X (Wireless)
    Network Policy Name: –
    Authentication Provider: Windows
    Authentication Server: NPS server DNS name here
    Authentication Type: EAP
    EAP Type: Microsoft: Smart Card or other certificate
    Account Session Identifier: –
    Logging Results: Accounting information was written to the local log file.
    Reason Code: 23
    Reason: An error occurred during the Network Policy Server use of the Extensible Authentication Protocol (EAP). Check EAP log files for EAP errors.

  • If the profile is installed with “sudo profiles” then it does enroll computer.
    And the certificates are imported to System keychain (per machine)

    But my RootCA certificate (which is part of the profile) does NOT get installed into any keychain).
    I can ofcourse install it by hand (not ideal!). But even with this I still can not connect to wireless with NPS refusing access with same error as above

  • Is there any specific NPS Network Policy setup needed for Mac?
    Via NPS I currently get my Windows PC & iOS devices connecting fine, but Mac fails

    Thanks

    sebus

  • Noticed that certificate in profile must be in DER format (that way it does get installed) Base-64 did not work for me

  • It all works perfectly fine. One issue was that Profile can NOT have any entry in:

    Network/Trust/Trusted Server Certificate Names (this field has to be empty)

    Then NPS server authenticates request

    sebus

  • While it works, it is unusable! Why?

    Because Wi-Fi (even profile is installed for MACHINE with sudo) does NOT connect till user is actually logged in & selects machine certificate from the popup box.
    Which means that user can NOT authenticate against network (AD) accounts, as at the login prompt wireless is NOT active!

  • Forgive me if this is a silly question…long time Windows guy here.

    Do these steps allow for the machine to be connected wirelessly at the login screen?

    I’m having an issue where after joining a MBP to our domain, then logging out, domain users are unable to login unless we connect an ethernet cable. It seems the machine is disconnecting from the wireless network and it’s impossible to join again at the login screen.

  • Great! Thank

Leave a reply

You must be logged in to post a comment.