Skip to main content
Question

EAP-TLS Authentication - Possible to use both computer and user certificates?

P
Forum|alt.badge.img+3

Hi All,

We're trying to get 802.1X working with EAP-TLS and AD certificate services working at a client site. We've had success getting OS X devices connect with just a computer certificate (works at the login screen and beyond) and also with just a user certificate once a user logs in. Trying to do both is causing some erratic results, however.

The ideal of the client is to have each device be connected with a computer certificate until login, and then with the user certificate after login. (Windows does this).

Currently we're pushing two configuration profiles, one at the computer level, which has an AD certificate payload using a computer certificate template, and the other at the user level, which has an AD certificate payload using a user certificate template. These profiles seem to have trouble coexisting. Is using two seperate profiles the correct approach or is there a better way to accomplish this goal?

The behaviour we're seeing at the moment is as follows:

  1. Both profiles are pushed to a newly imaged device. The computer level configuration profile correctly obtains a certificate from the windows server and we can see the computer joining the wireless network properly using the computer certificate.

  2. Logging in as a user causes the user level configuration profile to be applied, at which point the user certificate is obtained correctly from the windows server, and both the ethernet and wireless networks re-authenticate and show as being connected with the user certificate.

Perfect right?

  1. Logging out back to the user prompt or rebooting causes both networks to disconnect (the computer level profile is no longer in effect). Logging back in to the already cached (mobile) account causes both networks to reconnect using the user certificate as expected.

  2. Making a subtle naming change to the computer level profile to cause it to be redistributed to the devices fixes the wireless connection at the login screen. It once again connects with the computer certificate, but this time after logging in and out, the connection continues to work at the login screen.

The wired connection on the other hand will now sporadically connect successfully at the login prompt using the computer certificate, but when it does connect successfully it won't properly re-authenticate with the user certificate after login.

Question is:

-Is the goal of the client possible? Can we have both computer and user certificates working on a Mac in this manner?

-Is anyone else doing this successfully, and if so do you have any pointers or suggestions that you could share?

Best regards,
Neil

    6 replies

    B
    Forum|alt.badge.img+8
    • BOBW
    • Valued Contributor
    • 126 replies
    • June 2, 2016

    HI Neil,

    I have been looking at this for a while now and have had no luck, been having similar issues with wired 8021x Machine/user based auth. Although there is a 8021x document by apple which states

    It’s possible to use System Mode and Login Window Mode together. For detailed information about the settings related to these modes

    page 7
    http://training.apple.com.au/pdf/WP_8021X_Authentication.pdf

    But then again I see other Apple docs which state you cannot use both and it is either one or the other.

    davidacland
    Forum|alt.badge.img+18
    • davidacland
    • Valued Contributor
    • 1811 replies
    • June 2, 2016

    I've looked at this a couple of times at clients sites with no success. I just stick to one or the other now (normally computer certificate).

    M
    Forum|alt.badge.img+7

    As far as I know, OS X doesn't support EAP chaining for 2 factor auth. Not sure if this is what you are looking for. In Windows, you can have the machine cert be auth form 1 and ad login as auth form 2.
    What I've seen In my environment is if there is an identity preference in both system keychain and login keychain, it doesn't know which to choose and bombs out.

    K
    Forum|alt.badge.img+13
    • Kumarasinghe
    • Contributor
    • 400 replies
    • August 16, 2016

    We have a Radiator setup and machine auth > user auth working fine as Wi-Fi will switch to their VLANS according to their group. Testing on NPS and found that it is not reliable.

    Initially we thought NPS settings might be the issue but we found that WLAN controllers having delays in DHCP assignment to OS X devices.

    Did some tcpdumps and working together with network engineers to get it resolved.

    L
    Forum|alt.badge.img+3
    • luke_gorham
    • New Contributor
    • 4 replies
    • December 14, 2017

    At best I could get a Machine cert on for the system for pre login authentication and then PEAP as a loginwindow configuration for user auth to work. This is still just two seperate auth attempts thought. Also if someone pulls out their cable and plugs it back in it will just re-auth using the machine certificate.

    So not really possible in a real world scenario at the moment, even harder if you have FileVault enabled. Id imaging that may make the above workflow bomb out with the machine certificate if you have the machines set to auto login after being decrypted with user creds.

    I
    Forum|alt.badge.img+1
    • infosec13
    • New Contributor
    • 7 replies
    • February 27, 2018

    Does any gentle soul have any other clues as to how can one, at the same time:

    1. Allow only company assets connect to the network ?
    2. Allocate users dynamically to an appropriate VLAN ?

    My initial instinct was to have machine + user authentication going, but apparently this is still impossible in Mac OS. Best compromise I can think of at this point is to assign computers to role-based security groups in AD and have distinct NPS policies assign them in the appropriate VLAN.

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings