Automate eap-tls and identity selection

cprimero
New Contributor III

Backstory:
We are switching from a peap network to a SCEP eap-tls network. I have created a script that clears out the old certs as well as the config profile associated with it. The script then runs recon to update jamf.

The new SCEP config profile excludes users with the given certificate name of the old Peap configuration. So when the script runs recon it will then show that it no longer has the old cert and will take down the new SCEP config profile.

Currently, when attempting to connect to the network a box appears asking to select EAP-TLS and the proper identity associated with it. Is there a way to automate this?

I have tried everything under

/usr/bin/networksetup

security set-identity-preference -s com.apple.network.eap.user.identity.wlan.ssid.wifi_network -Z $cert

(wifi_network is generic, real ssid will be here)
``

5 REPLIES 5

mm2270
Legendary Contributor II

The approach you're using is correct (with one possible exception - see below), but the security set-identity-preference command must be run as the logged in user. If that's running in a script called by a Jamf Pro policy, it will be running as root and won't add the identity preference into the correct keychain.

You can try this-

#!/bin/bash

LOGGED_IN_USER=$(stat -f%Su /dev/console)
LOGGED_IN_UID=$(id -u "$LOGGED_IN_USER")

/bin/launchctl asuser "$LOGGED_IN_UID" sudo -iu "$LOGGED_IN_USER" /bin/security set-identity-preference -c $certname -s com.apple.network.eap.user.identity.wlan.ssid.wifi_network

That should run the set-identity-preference command as the current user, not as root, which means it will add it into the correct keychain, and hopefully work after that.

Note that I'm using the -c option to point to the common name of the certificate, which you will need to code in your script to detect in some way. I haven't used the -Z option since that requires a SHA-1 hash of the cert. If that option works for you, then by all means use it. But if you continue to have any problems when doing it that way, try pointing to the common name of the cert instead to see if that helps.

dmueller
Contributor

If the certificate is individually named per computer and uses either the computername or a portion of your domain name, you might be able to use something like this to capture it into a variable that reflects the common name.

security find-certificate -a /Library/Keychains/System.keychain | awk -F'"' '/alis/{print $4}' | grep "*part of the common cert name*"

It will help to have some common elements for this to work for more than one system, but a lot will depend on how your certificates are set up.

I like the idea of checking for its existence and then setting the up the identity preference. This could make things easier for our users when the certificate refreshes....

Edited as reduce the possible responses you might return.

patgmac
Contributor III

Since you are using (device level) profiles, have you considered also delivering a user level profile? It'll still be a machine cert, but it would deliver a 2nd cert into the users keychain along with a com.apple.network.eap.user.identity.wlan.ssid.wifi_network in the users keychain already. Then you'll have both areas covered without having to script.

mwilkerson
New Contributor III

@patgmac Could you elaborate on this? I keep getting prompted for admin credentials to allow macOS to access the System Keychain for my machine cert, even though it is set to allow all apps to have access to it. Would what you're describing above eliminate the need for admin credentials prompt?

patgmac
Contributor III

@mwilkerson the prompt I'm referring to is the one to select a cert from a list. I'm not sure why you would get an admin prompt.