802.1x machine-based authentication - configuration

[mm10]

I'm trying to setup 802.1X Wireless using Configuration Profiles and machine-based auth using root CA certificates.

I decided to create a new Certificate Template in AD-CS based on the one we use for our Windows laptops, but this time with the ‘Service Principal Name’ option checked rather than ‘DNS Name’. I followed the advice here (see last post)

Clients receive a certificate just fine using the profile I created and I see an X509 cert in the Keychain. However, the system still doesn’t connect to our 802.1X network - when looking at the RADIUS server logs, I see connection rejections and suspect this might be because the user name presented is still in the form DOMAINhostname$, whereas I believe it should be host/fqdn, as that’s what I see on successful connections from Windows laptops.

I was hoping the new template would ensure the username is presented in the correct form, does anybody know what I'm missing?

[davidacland · Accepted solution]

I've had this before with Cisco ISE v1.3. I don't think there is a configuration change you can make on the client end so you'll probably be looking at making adjustments on the RADIUS, or finishing the connection manually on the devices.

[NickKoval]

If you are getting the X509 certificate, you are getting close. Hold down the option key and click on the WiFi menu and choose "Open Wireless Diagnostics ...". From the window menu choose "Logs ..." and enable the 802.1X log. This will let you see what the client is getting from and send to your RADIUS box allowing you to verify if the username is really the issue or if it's something else.

Also, look at the X509 Certificate's extensions and see what Subject Alternative Names are in the certificate. These are provided by your AD template and can be tweaked as necessary to tie in with what your RADIUS box is expecting.

[macbentosh]

There was a weird issue that we saw when using this. After login we had to have user go to System pref > Networks and re-auth the 802.1x profile and reboot before they would connect successfully. Not sure what the issue was but that's our workflow now.

[dan_kubley]

Between https://support.microsoft.com/en-us/kb/814394 and https://www.afp548.com/2012/11/20/802-1x-eaptls-machine-auth-mtlion-adcerts/, you will see that the Subject Alternative Name needs to be the UPN (user principal name) for 802.1x to work on Macs. This can be changed in the certificate template. Hope this helps.

[mks007]

We populate the username as host/$COMPUTERNAME.example.com, this option will appear after tick the TLS box

But we are using a NDES server to generate the certificate on the Mac, I have not tried AD-CS based but our Windows are getting the cert from the AD-CA and they are using the SPN (service principle name) in the machines AD object just the same

(ab319aba838245058d438b12a947fd47) ~[upload]

[ndelgrande]

I haven't gotten this completely automated yet, but I have been working on our own network access control project for almost 8 months now. Once the Mac has it's unique cert and all the certificates needed for the cert chain, when the user plugs in the ethernet cable, a pop-up shows up. They select default, then their cert, then save it to their keychain and they are good to go. We do have an issue with users not updating their certificate when prompted. So it does work, but I have yet to get it completely automated, mainly because only ethernet is protected right now through EAP-TLS and WiFi is using EAP-FAST.

[mm10]

@dan.kubley We did try that initially - UPN rather than SPN - but got the following error:

Profile installation failed. 

The ‘Active Directory Certificate’ payload could not be installed. The certificate request failed.

[dan_kubley]

@mm10 Hmm, if we look at that AFP548 article I linked above, they ran into the same error. Have you tried enabling the debug logging they mention? Sometimes that logging can give us the ID of the failed cert request, and then on the CA server we can find the exact reason why.

[NickKoval]

Because that error message is soooo informative, I typically enable mcx logging - see this afp548 article. The mcx log will tell you in explicit terms why the cert isn't being accepted. It will actually contain the html markup response from the ad certificate server.

[mm10]

Thanks for all the suggestions. We had our network guys update the RADIUS server configuration to automatically accept usernames from Macs in the form MYDOMAINcomputername$ and all now works swimmingly via TLS.