In the JNUC 2013 Using 802.1x with the Casper Suite session it was talked about that it's possible to use Machine based authentication rather than individual user credentials. Has anyone had any success in doing this, and if so would be willing to share their knowledge. I'm very interested in doing the same thing. I can get the profile working with standard username and password authentication hard coded in the profile, but would like to make a profile that could be deployed without user credentials. Also I would like to not have to bind these machines to AD, so if anyone can confirm that this works as well that'd be great! Thanks again to Hopkins Public Schools for the great session!!!
Edit: Nevermind, I see that you don't want to use Active Directory, so my post was not helpful. I'm not sure how you would do machine authentication without some sort of directory bind.
If you do want to use AD, here is how we do it: It just uses the system's credentials to authenticate.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <array> <dict> <key>AuthenticationMethod</key> <string>directory</string> <key>AutoJoin</key> <true/> <key>EAPClientConfiguration</key> <dict> <key>AcceptEAPTypes</key> <array> <integer>25</integer> </array> <key>OneTimeUserPassword</key> <false/> <key>SystemModeCredentialsSource</key> <string>ActiveDirectory</string> <key>TTLSInnerAuthentication</key> <string>MSCHAPv2</string> <key>UserName</key> <string></string> <key>UserPassword</key> <string></string> </dict> <key>EncryptionType</key> <string>Any</string> <key>HIDDEN_NETWORK</key> <false/> <key>Interface</key> <string>FirstActiveEthernet</string> <key>PayloadDisplayName</key> <string>Ethernet 1</string> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>com.company.wired8021xconf</string> <key>PayloadType</key> <string>com.apple.firstactiveethernet.managed</string> <key>PayloadUUID</key> <string>bcfc0490-c46e-012f-52da-442c030cc3db</string> <key>PayloadVersion</key> <integer>1</integer> <key>ProxyType</key> <string>None</string> <key>SetupModes</key> <array> <string>System</string> </array> </dict> </array> <key>PayloadDescription</key> <string>Wired 802.1x Profile for wired networks</string> <key>PayloadDisplayName</key> <string>Wired 802.1x</string> <key>PayloadIdentifier</key> <string>com.company.wired8021x</string> <key>PayloadOrganization</key> <string>Company, Inc.</string> <key>PayloadRemovalDisallowed</key> <false/> <key>PayloadScope</key> <string>System</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>8b825110-c46e-012f-52d8-442c030cc3db</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist>
Has anyone had success using EAP-TLS machine based authentication?
I am not able to push a profile with a Wi-Fi payload configured because it appears to choose the incorrect certificate for authentication. I am not sure if this is contributing to the incorrect user account being supplied as well.
My systems are joined to a Microsoft AD and am using SCEP to issue the device certificate.
@jyauch The profile you built for authentication needs a SCEP payload then, to my knowledge. Once you enable that, the Network payload will have an option to use that cert for authentication.
Also, with EAP-TLS, you have a checkbox options for "Use Directory Authentication" which may also work, provided you bind directly with Apple's AD plugin.
Currently we register the MAC address of the machine in a database, the DHCP hands out a static address to the wired clients, and registers them with our DNS. So clients always get the same IP while on the wired network. The DHCP hands out the DNS info along with the IP. So yes and no, we aren't hard coding them, but they are static...If that makes any sense.
@JPDyson I have all that configured in the profile.
My profile consists of the SCEP payload to issue the cert, the necessary intermediate certificates are loaded into the payload, and the Wi-Fi payload has the SCEP option selected. It seems that for some reason it always selects the first certificate in the list.
Sorting the certificates by name, the JAMF binary cert is the first one since it start numerically. Plus if I don't set it to auto-join and allow it to prompt for credentials, these are my only two choices for identity, the JAMF binary cert and the machine name cert.
@adhuston We have a similar issue as well. We assign by DHCP request, but do not assign reservations, and DNS is not handed to the Mac devices. When I did some research on this previously, I believe there are some manual scope/class options that can be typed in to provide information to the Mac devices.
What we did in our environment is run a script on the systems to populate the DNS suffix search list. If I recall correctly, systems bound to the domain will have that domain suffix added, but it will not process any additional.
As for your traveling/home users, it shouldn't cause an issue because it should read the DNS server information from the ISP.
Yep, exactly like it. I've seen it take as little as 10 minutes and as long as 30. We contemplated doing the script mentioned, but users complained that it was to much work to have to turn back on their airport when they were outside the network. We're moving to a new DHCP/DNS system in the near future, but my JSS will probably be long deployed by that time, so I was looking for more of a stop gap to get us there until I can make our AD bound Macs authenticate off network successfully.
@adhuston well, if your domain is something like mycompany.com & for some reason you don't have an external site... Register the DNS name & as long as the clients can resolve it your away!
If your AD is only a DC, you could possibly hack it with a HOSTS file. (Eughh...).
Tbh, I don't think changing DNS is going to help.
Can you give us a redacted example of your domain? Keeping the last bit intact?
Hmmm....Sounds like a good solution. I'll have to look into that until I can get our environment playing nice. I opened a AppleCare support ticket for the issue a while back, and it was somewhat fixed in 10.7, but reared it's head again in 10.8. Basically Apple claimed that they had changed the timeout for the Kerberos realms so the timeout would happen quicker.
Wish I could, but our DNS and DCs are managed by other groups. The only access I have is to make reservations and bind to the DCs. We did some testing and found that putting a firewall (A transparent firewall with Wireshark logging the traffic) in front of a client and if we blocked just the kerberos information provided by the DNS, life was good again and time outs took seconds. But we did the same experiment with a windows client, and blocking those kerberos ports make the windows clients go haywire. Since we have a larger population of windows clients we couldn't put it into production. We have an internal and external DNS, evidently the external is providing to much information. It shouldn't be returning any information on the DCs, but it does. So at this point it's kind of off the table for us to change the DNS/DHCP.
Yes to working with EAP-TLS
Macs are bound to AD at imaging
Configuration profile with network, certificate, and AD certificate payloads
Configuration scoped to smart group (bound to Active Directory)
Configure the Certificates payload first (Root, Issuing and other certs your org requires)
Next AD Certificate payload:
- For 10.8 and 10.9 clients use fqdn for certificate server and Certificate Authority is the Issuing CA.
- For 10.7 use URL for the certificate server, and leave Certificate authority blank
Next Network payload
- select TLS for protocols
Select "AD Certificate" for identity Certificate
On the trust tab select the certificates you added in the certificate payload.
We have a similar but different need - we do not bind Macs to AD, we 'bind' them to Jamf. So each Mac has a Jamf issued and signed certificate that we can use to authenticate for EAP-TLS. Works fine for an end user selecting the certificate in the wifi popup, but we want to push that policy from Jamf.