There is a lot of info over the years about 802.1x, and I'm not sure where I am going wrong. Some threads suggest that computer authentication with Casper is broken, others say you NEED an AD certificate, others say you don't. Could someone just verify what I should be doing to get this working? Currently we have a computer level configuration profile. Casper 9.97, Mac OSX 10.11 NETWORK Network Interface: Ethernet Use as a Login Window configuration - Enabled Protocols TTLS & PEAP Use Directory Authentication - Enabled Inner Authentication - MSCHAPv2 Trust - Both Certificate (Intermediate and Root) selected. Certificate Common Name:.ourdomain.com CERTIFICATE 2 Certificates added - Root and Intermediate That's it. It initially connects to Radius, does initial handshake, but the Macs stop responding when trying to do proper authentication as the computer account.
If I log into a device and have a look at the network settings, 802.1x just says 'connecting' for a very long time. If I stop and use my own credentials, all is fine. So I know it's an issue with the Mac passing the computer credentials. Suggestions very welcome:).
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. But we want the Mac to authenticate as a device at the computer level, before anyone logs in.
This is apparently supported. 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.
Thanks for all the replies. 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. 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. 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. 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.
I have been trying for some time to get PEAP (Microsoft's Protected EAP method) to work with Mac OS X 10.3. Today It finally worked, and it boils down to this:. Import the certificate for the root certificate authority (CA) that issued the certificate to your IAS box into your keychain. Make sure it goes into x509Anchors. If you have web enrollment enabled, you can go to that site and download it. In Internet Connect, select new 802.1x connection, enter the login ID (no domain) and password, then select the wireless network that's using PEAP.
From the Configuration list, pull down and select Edit Configurations. On the sheet that pulls down, select PEAP and then configure and enter your domain and loginid (Domainloginid) in the box marked 'Outer Identity.' .
Save your changes and connect to the network. It should ask you if you really want to trust the certificate. Examine it and if you do, (and you really do.) say yes.
If it dosn't connect the first time, try again and it should work.This solution was tested using Mac OS X 10.3.4 connecting through a D-Link DI-624 setup to use WPA. The Domain Controllers were Windows 2003 in Native 2000 mode. The RADIUS server is a Windows 2003 server with IAS (Internet Authentication Service), and the Certificates were issued using Windows 2003 Certificate Services. Question: when you got the.cer to import into your keychain, was it expired? I'm finding that my cert is expired by a couple minutes every time I download it. Is that normal?
Also, airport is not seeing the wireless network by default, I have to type it in. Was your machine seeing the wireless network? Also, I can't specify that I want to login using EnterpriseWAP in the 802.1x configuration. Does it just know this by default? When you pulled down edit configurations, was the login/pw already filled in? Should it be?
I'd like to just double check that the outer identity should be Domainloginid, no '/', no '@'. Does Domain need to be capitalized?
Did it matter? Thank you for this! (I'd post what our hardware/software is but I don't know. I'm an end user searching desperately for help).