802.1x Machine Based Authentication

adhuston
Contributor

Hi Everyone,

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!!!

21 REPLIES 21

cbrewer
Valued Contributor II

The main thing you need to do here is put $COMPUTERNAME in the "Username" field in the profile. Then leave the password blank. You'll also need to make sure in your Network Policy Server that "Domain Computers" can authenticate to wireless.

external image link

adhuston
Contributor

Thanks! I'll give it a shot. We're doing a similar thing on the Windows side of the shop, so I'm pretty sure that domain computers are allowed to authenticate.

alexjdale
Valued Contributor III

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>

bentoms
Honored Contributor III
Honored Contributor III

@adhuston We use the same method as @cbrewer outlined.

But that does require the mac to be a domain member... Why the reluctance to AD bind?

adhuston
Contributor

Hmmm....That's what I was afraid of. I can't get into it to deeply, but our DNS causes AD bound Macs to have some issues when they are outside of the Network. We are supposed to be moving to a different DNS setup, but I'm not sure of the time frame.

alexjdale
Valued Contributor III

That's odd, I assume you are hard-coding your clients to use a specific DNS server rather than pushing it through DHCP?

jyauch
New Contributor III

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.

JPDyson
Valued Contributor

@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.

adhuston
Contributor

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.

jyauch
New Contributor III

@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.

bentoms
Honored Contributor III
Honored Contributor III

@adhuston does the following sound similar to the offline issues you're seeing?

http://macmule.com/2011/03/11/slow-login-for-ad-mobile-accounts-when-off-the-office-lan/

jyauch
New Contributor III

@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.

adhuston
Contributor

@bentoms

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.

bentoms
Honored Contributor III
Honored Contributor III

@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?

adhuston
Contributor

@jyauch

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.

jyauch
New Contributor III

@adhuston

Here are the commands being executed in the script.

#!/bin/bash
IFS=$' '
for i in `networksetup -listallnetworkservices|grep -v asterisk` do networksetup -setsearchdomains "${i}" add dns names here with spaces between each suffix
done

adhuston
Contributor

@bentoms

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.

adhuston
Contributor

@jyauch

Thanks! I'll do some experimenting!

bentoms
Honored Contributor III
Honored Contributor III

@adhuston what I was wondering was if your domain ended in a standard Top Level Domain like .com or a non-standard one like .global.

Previous employer had the issue & the FQDN of the domain was mycompany.global

Current employers domains FQDN is mycompany.com & doesn't have the issue.

lisacherie
Contributor II

@ jyauch

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.

wdeneys
New Contributor II

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.
0e937cda1bdd4d8d8a4210ab22c78fb1