802.1x PEAP Ethernet AD settings

Is the client bound to a domain? If so do normal AD logins work?
This is often due to a protocol mismatch between the profile and what radius expects to receive. Have you tried other protocols besides PEAP?

@psliequ Yes, all bound to domain, normal logins work, user 802.1x works too. We are only set up for PEAP.

You may need to include the certs from the ACS server. Can your networking guy look to see if there are errors on his end?

Also, I'm confused, is this for wifi authentication?

@seann Root and intermediate certs are included and seem to be doing their part.
This is for ethernet only, not wifi.

The only errors we see on the networking end is a timeout from the Mac. Communication is fine, but the Mac is not responding to the challenge provided - it's not supplying it's computer name and computer password.

"12937 Supplicant stopped responding to ISE after sending it the first inner EAP-MSCHAPv2 message"
Basically it's asking for the computer authentication, and the Mac is not responding to the request.

12305 Prepared EAP-Request with another PEAP challenge 11006 Returned RADIUS Access-Challenge 12937 Supplicant stopped responding to ISE after sending it the first inner EAP-MSCHAPv2 message (Step latency=120000 ms) 5411 Supplicant stopped responding to ISE

I had to set it to user level to have it work properly with directory auth.

@grepoli But we want the Mac to authenticate as a device at the computer level, before anyone logs in. This is apparently supported.

http://training.apple.com/pdf/WP_8021X_Authentication.pdf

Page 7

The OS X supplicant operates in three modes: User Mode, System Mode, and Login Window Mode. ... It’s possible to use System Mode and Login Window Mode together.

As a side note, if I supply a service account username/password, it works at both computer level (when the computer starts as the service account) and user level (when a user logs in, as that user). Our security guys say no service account allowed and, to be fair, it shouldn't be needed according to Apple - it should use the computername and password that matches AD.

Thanks for the help so far everyone. :(

I would have the network guys check the ISE logs; in our case the RADIUS server (admittedly, Server 2003 IAS!) didn't have a rule to support a Mac and they were going to add "Domain Computers" as an option to enable this.

In my configuration, we had ONLY TLS (no PEAP) selected in Protocols, and WPA2 Enterprise as the Security Type. I see you're using Cisco ISE; again may need an additional rule there to trust either Domain Computers group or "Authenticated Users" (which contains both user and computer accounts).

Are you issuing the certificate as part of the profile, or uploading an existing .pfx file exported from ADCS? You have to select it in the "Identity Certificate" field as well.

@CCNapier Can you confirm the Mac is hitting the CA to get the machine cert?

I too have a user profile to get it to work.

When doing a system profile I was experiencing the same issues you were.

@CCNapier Yeah, followed that as well, which led me to the same frustrations. I'm not too sure why it fails to properly connect at the computer level, even when directory credentials is left blank. As soon as I switched it to user level; just to try everything, I was able to connect successfully after supplying.

You could possibly try computer level + checking the use login window authentication option?

Thanks for all the replies.

@KSchroeder The rule should be working successfully - all Windows PCs successfully authenticate using the "Domain Computers" rule, AFAIK, but I'll double check that Mac's are definitely getting into that group (no reason they shouldn't be) or the Authenticated Users group. As we are on ethernet, there's no WPA2 option and PEAP is the way we require to go for now.

@LSinNY Is this referring to AD Certs? I don't think we create AD certs for computers as we don't have PKI anymore, AFAIK. I'll double check... or are you referring to other certs? Do you think AD certs are a requirement for 802.1x on OSX?

I would at least expect an error to be returned other than a timeout waiting for any response from the Mac. Surely if everything is setup correctly on the Mac, it would try to send something to ISE which ISE would then complain about (if it's not in the right group, or doesn't have a matching cert), but ISE simply says "you've sent nothing at all, I'm done waiting".

Just to confirm, is anyone actually using a Casper config profile for Ethernet with PEAP and device authentication? I am curious if the mobileconfig is being setup correctly by Casper (I've read issues in the past, and not sure if they've been resolved). I've seen previous mobileconfigs for Lion, but they are a bit different now when comparing to mine.

@CCNapier We have machine authentication working for wifi

@CCNapier I used the guide here by Mike Boylan, that seems to cover machine authentication I am using a Casper created config. I have not worked with ISE, however most of what I read requires an additional AD cert template for mac OS machine, as the built-in machine template does not properly populate the device name.I re-imaged a machine yesterday with 10.12.4 to test our image and confirmed the machine did pickup the cert. If you search the forums you should find an example of a Jamf Pro config,

Running into something similar... @CCNapier, were you able to find what was causing the issue?

So just an update for anyone else looking:
There seems to be a product issue.
When I create the exact same settings in Apple Configurator 2, and deploy that manually - everything works.
If I import that into Casper (or copy the settings and use the GUI) it does NOT work.

JAMF has agreed the workaround of pushing the exported mobileconfig from Configurator is working for now.
I package it up, and install it with a script once deployed.

@CCNapier,

Seeing the same thing here. EAP-PEAP with MSCHAPv2, profile deployed via our MDM either immediately fails or will prompt for User Name and Identity as if it's using EAP-TLS. We do not see this issue if we manually deploy a profile created in Apple Configurator. This issue is not limited to Jamf Pro, as it occurs on our AirWatch-managed iOS 11 devices as well. Additionally, it appears that for some reason, if I bundle the radius certificate with the profile and trust it, many devices get the User Name and Password fields as expected. This does not appear to work for all devices, however.

@CCNapier,

Forgive me if this posts twice, but it didn't seem to go through. You said you had configured the profile using Apple Config 2 (When I create the exact same settings in Apple Configurator 2, and deploy that manually ). I don't see a payload for Network where you could use a wired ethernet. Maybe you were using wifi in this example? Or is there something I'm missing from Apple Config 2.

@CCNapier It's been over a month since the last response so I don't know if you've made any more progress on this.
From my own university, we have recently started looking into 802.1x and we were failing to get machine certificates.
Verify you are getting those first. If not, it is possible that the ICertPassage protocol is disabled on the certificate authority.
Once we enabled this with certutil.exe, the machines would then get the proper certificates to be used at the computer level with 802.1x via configuration profile.
I also think but am not sure that the AD Certificate payload and the network settings payload have to be in the same profile. I might be wrong on that however.

EDIT: Also, shouldn't the username and password fields be blank. I don't think the username field should even be populated with the variable. At least, it's not needed in my environment.