× Welcome to the Centrify Community! We are rolling out product name changes — click here to learn more.

Re: [HOWTO] A checklist approach to enable 802.1x networking on OS X using your Windows Infrastructu

[HOWTO] A checklist approach to enable 802.1x networking on OS X using your Windows Infrastructure

By Centrify Guru I on ‎02-13-2015 05:04 PM - last edited ‎12-21-2015 02:13 AM

How easy is it to implement?


It is as easy as enabling one of the Centrify-provided GPOs for Mac OS X.  Specifically the "Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1x Settings" and you can pick your flavor:

OS X - Profile Wifi TLS.jpg

  • Enable Machine Ethernet Profile
  • Enable Machine Wi-Fi Profile
  • Enable User Ethernet Profile
  • Enable User Wi-Fi Profile

However, this entry would not be useful if I just show you that you can enable the GPO, perform a policy refresh and just like magic: network access.


What I've noticed from prospects or customers that are looking to test these capabilities is that they don't understand all the moving pieces that need to be in place in order for this to work. 


In this post we'll use a checklist to make sure that you understand what needs to be in place to be successful.  


Note:  If you already have 802.1x EAP-TLS running with your Windows infrastructure today, you are very well-positioned for success.




Building Blocks


Active Directory and Windows Services:  There are several ways to accomplish this goal, but in this particular instance, because our goal is to consolidate processes, knowledge and infrastructure, we are leveraging Windows capabilities like Active Directory, AD Certificate Services and the Network Policy Service.  AD Groups will be key to provide access controls;  OUs will determine the scope of GPOs to be used.


Public Key Infrastructure:  PKI is needed to provide the encryption, non-repudiation and authentication between the back-end infrastructure (Active Directory) and the client (Ethernet or Wifi).  The key here is the certificate life-cycle management, this is where Windows PKI uses Group Policy.

PKI Disclaimer:  PKI is not joke.  Any proper implementation needs to provide the assurances that PKI is aligned with your security policy.  If your organization does not have a policy for PKI (general assurances, handling of private keys, policies, templates,  Root and SubCAs) consult an expert.


A Policy/Configuration Management Engine:  Group Policy provides the rules and the enforcement for configuration items and even provides certificate auto-enrollment - a way to manage the certificate lifecycle (issuance, renewal, revocation, etc); in addition, GPOs will be the way that Centrify will provide the Apple profile information.


Network Policy Service: The NPS service on Windows provides the services like Remote Authentication Dial-in User Service (RADIUS) and the policy rules to enable 802.1x.  The NPS Service interacts with Active Directory to leverage groups and attributes.


802.1x-Capable Network Devices:  Any modern switch or access point supports 802.1x EAP and RADIUS.


Centrify Agent for Mac OS X:  This use case showcases the power of the Centrify agent.  Not only it leverages its ability to integrate with AD, but to use advanced services and perform this cohesively within the MacOS platform.  Key capabilities:  Certificate Auto-Enrollment, System Profiles, GPO Engine.


The Lab

 centrifying - user suite mod 802-1x.jpg


  • For AD and PKI:  Modified Microsoft Test Lab Guide:  Provides the corp.contoso.com domain with a running Microsoft CA.  The RootCA (corp-DC1-CA) certificates are deployed using GPOs.
    Translation:  A common Certificate Authorithy with the proper Certificate Revocation publication methods needs to be provisioned. I did not set APP1 as a SubCA.
  • For RADIUS and Policies:  I'm piggybacking on my APP2 Windows 2012 server
  • Network Devices:  I'm using Cisco small business (300 series) switch and a TPLink (TL-WA90x) Wireless Access Point.
  • Mac Client:  Old Macbook running 10.7 and Centrify 5.2.1


Basic Checklist

  •  OS X System is Centrified
  • Centrify agent is connected  (run adinfo -m)


PKI Checklist

  •  All Systems have a Root CA in their trust chain?
  • The Network Policy Server has a computer certificate?
  • A proper 802.1x certificate template was set up for Mac Systems?
  • The Mac Auto-Enrollment GPO has been properly deployed?
  • Was the computer Certificate on the Mac based on the proper template?
    You may need to look in the CA's Issued Certificates.
PKI - Principal-Template.jpg

8021x - PKI Trust Chain.jpg

With PKI it's all about consistency.  All systems trust the Enterprise CA; All Certs are Issued by the CA or SubCAs and Programs (like NPS) are using the same trust chain.



NPS/Network Device Checklist

  • RADIUS clients have been set up properly on the NPS Server
  • RADIUS servers are properly configured on the network devices
  • Is there connectivity between RADIUS clients and servers?

 NPS - Radius client and Server.jpg

  • Connection Request Policies are set up appropriately (Conditions/Settings)
  • Network Policies are set up to Allow access based on Conditions
  • Clients Meet the Conditions?
 NPS - Conditions.jpg

Any conditions added (like AD group membership) must be met in order to have successful connections.

802.1x Mac Group Policy

  • Is the Mac System Wifi-capable?
  • Wifi SSID is correct?
  • Template Name is correct?
 GPO - Template Name vs. Display.jpg

The template Display Name may be different than the template Name

  • Has the policy been refreshed?  (adgpupdate - remember replication!)
  • System Preferences > System > Profiles contains payload?
    OS X - Profile Wifi TLS.jpg
  • Connected?

OS X - Connected Wifi TLS.jpg


Video Playlist

By Paranoid_Marvin
on ‎03-14-2017 05:58 PM

Thanks for the blog and the videos.  Really helpful!


I'm trying to set up wifi access for Macs in our corporate AD environment.  We already have 802.X access set up for our Windows laptops so most of the prerequisites should have been met.  My environment is very similar to your lab environment with teh exception that we're using a Cisco ISE instead of Microsoft NPS.


I can see that the cert chain and private key is being delivered to the Mac OK, and the profiles are being created.  But when the Mac tried to authenticate the ISE looks up the computer name (FQDN) in AD and can't find it.  It's there though for sure.


Any ideas?

By Centrify Guru I
on ‎03-14-2017 06:18 PM



Welcome to Centrify and thank you for the feedback.


It has been ages since I wrote this article, I don't doubt that it may be a bit out of date.

I can tell you this, most of the time, the issues are with the Certificate Template.  However, if you're having a DNS resolution issue at the Cisco ISE level, I would resolve that first.


Unfortunately I am Cisco ISE illiterate Smiley Frustrated


You have several avenues here:

a) Work with support - if you are a commercial customer, you have those awesome benefits.

b) Review the Mac Admin guide.  It's absolutely possible that a new step may have been overlooked (after all, the product has changed).


Please update the thread once you find out the culprit.


This benefits other travelers



By Paranoid_Marvin
on ‎03-14-2017 06:36 PM



Thanks for the quick reply!


I don't think it's a DNS issue per se as lookups for Windows laptops are fine.


Re the cert templates though, I haven't set up a new cert template for the Mac.  It's getting the same one as the Windows clients.  Is there anything Mac specific in the cert template?


a) We have paid support for Linux clients but the Mac license I'm using in an eval one so commerical support not available to me :-(.

b) I worked through the Mac Admin Guide already (which got me as far as I am now).


By Centrify Guru I
on ‎03-14-2017 06:40 PM

The template cannot contain certain characters or spaces.

You are technically evaluating the product, so you should be able to get standard support.

By Paranoid_Marvin
on ‎03-20-2017 05:01 PM



Problem solved!  We hit a bug in macOS Sierra - https://www.reddit.com/r/sysadmin/comments/52mz6r/apple_sierra_breaks_ssl_w_blank_subject/


The fix is to manually set the cert to be "Always Trusted"

By Centrify Guru I
on ‎03-20-2017 05:15 PM

Kudos @Paranoid_Marvin!

Thanks for sharing this with the community.  I'h happy the checklist is still relevant.

Showing results for 
Search instead for 
Do you mean 

Community Control Panel