Sierra 10.12.5 Upgrade breaking Corp Wifi

@bbot it all looks good, any clues on your NPS server?

We use Cisco ISE. Looking at the logs, it doesn't look like it's presenting a certificate. Not too helpful here...

Event 5400 Authentication failed Failure Reason 12521 EAP-TLS failed SSL/TLS handshake after a client alert  12521 EAP-TLS failed SSL/TLS handshake after a client alert  12507 EAP-TLS authentication failed  11504 Prepared EAP-Failure  11003 Returned RADIUS Access-Reject

Here's a successful one
12504 Extracted EAP-Response containing EAP-TLS challenge-response  
12571 ISE will continue to CRL verification if it is configured for specific CA - certificate for ############
 
12571 ISE will continue to CRL verification if it is configured for specific CA - certificate for #######
 
12811 Extracted TLS Certificate message containing client certificate  
12812 Extracted TLS ClientKeyExchange message  
12813 Extracted TLS CertificateVerify message  
12804 Extracted TLS Finished message

Same issue fo some of our users.

The solution so far has been, open Keychain, find the correct cert and select Trust Always, then manually reconnect to the Wifi using Join Other Network option and add int the correct details of

Network Name
WPA2 Enterprise
EAP-TLS
Select the cert just changed updated Username

Then authenticate as admin and you are good to go.

We pre-populate our certs into our profile. machine/login window. Just upgraded to 10.12.5. No wi-fi issues

I have built an entirely new Config Profile to test with 10.12.5.
1. General: basic name and description. Install Automatically. Computer Level.
2. Network: a. Ethernet. TLS. Trust: our 5 internal root and issuing and proxy certs. Allow Trust Exceptions
2b. WiFi, our SSID (not hidden), Auto Join. Proxy setup Automatic with the URL of our pac settings. WPA/WPA2 Enterprise. TLS. Trust is the same as ethernet. Allow Trust Exceptions
3. Certificate: I uploaded our 5 internal root and issuing and proxy certs
4. AD Certificate: basic name. our cert server address, Certificate Authority name, Cert template name, 15 days expiration notification. Allow access to all applicaitons.

On my test 10.12.5 Mac, I removed the computer from the separate already-existing scopes for 802.1x and certificates. I went into Keychain Access and cleaned up any remnants of com.apple.network.eap and any certs manually added. Rebooted and plugged it into a non-802.1x port. Then I added the computer to this new single config profile and let it push. After confirming that the profile pushed and the certs are all present, I plugged into an 802.1x port and rebooted. It appears to have worked on ethernet. I even crated a test Login trigger policy to say "hello" and it worked. After getting to the desktop I verified that Ethernet has a valid IP and shows 802.1x connected. However, it absolutely will not connect to WiFi. Even if I manually click Disconnect and then Connect in System Prefs > Network. The only error I get is the standard "The Wi-Fi network could not be joined." I can find no errors in Console relating to 802.1x or our SSID. Could this be the still troublesome JAMF/Apple bug with 802.1x?

I have achieved partial success using these steps. Maybe you'll have better luck with your network.

Still no luck here. I'm tried every possible combinations of checking the trust for sub, root, root and sub, typing in the certificate common name of the sub and root and wifi won't connect at all with those settings.

My original configuration profile without checking the box to trust any of the certs or typing the certificate common name allows our users to re-connect 100%. The only issue is that when user's update to OS X 10.12.5, they get disconnected from wifi and need to re-run my bash script that installs the profile from Self Service to get re-connected.

At this point, I'm thinking about just sending out communication to users who haven't updated and give them a heads up that they'll need to re-run the "connect to wifi" policy in Self Service.

Did some more testing. After updating to 10.12.5, i found that the com.apple.network.eap.user.identity.ssid.###### was completely missing on the user's login keychain. The com.apple.network.eap.system.identity.ssid.##### in the system keychain is there and has the correct certificate, but wifi wouldn't connect with just this.

After deleting the wifi profile from network preferences, re-connecting by choosing EAP-TLS and choosing the AD machine cert, it'll reconnect fine.

We got our Wifi cert working yesterday after trial and error. We can now use it with JSS 9.98 and 10.11 > 10.12.5.

Additional config added to the Configuration Profile included the certificate section, and then uploading the certificate we had configured in the AD Certificate section already, using the full file name including the .cer extension as the display name. Saved the profile and then went into the Network section of the Configuration Profile, clicked the trust tab half way down next to protocols and ticked the box.

Our configuration uses WPA/WPA Enterprise, TLS and a hidden SSID.

think my issue relates to this

https://www.reddit.com/r/sysadmin/comments/52mz6r/apple_sierra_breaks_ssl_w_blank_subject/

I can confirm that I changed the certificate template to include dns name instead of common name as the subject name. It now properly populates the subject name, and macOS Sierra clients are happy.

If i request a cert without a Common Name and trust it manually it works.

1. Remove your computer from any 802.1x config profile scopes.
2. Open Keychain Access
3. From the menu select Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority.

4. User Email Address: your email address
   Common Name: Leave Blank
   CA Email Address: Leave Blank
   Request is: Choose 'saved to disk'

5. A file named 'CertificateSigningRequest.certSigningRequest' should be generated

open that file with text edit

copy all of the text inside the file (including the ---beginning and ----end parts)

1. Logon to your Certificate Authority and select Request a certificate

2. click on 'advanced certificate request.'

3. Paste in the copied text into the 'Saved request:' box

4. Choose your Certificate template from the drop down box and click Submit

5. on the next page Download the certificate

6. Double click the certificate and it should be added to your login keychain

7. in the certificate's properties make sure EAP is set to Always trust.

8. Connect to your Corporate Wifi and select your certificate

any prompts that appear make sure to choose always allow and allow

@dprakash That is an interesting tidbit into this whole mess, but it is extremely labor intensive and not at all practical. :-

@AVmcclint thats the entire process certificate retrieval manually and if someone's desperate it may work

Just tested. We are using 802.1x Wi-Fi device certs, so far connections are fine. #knocksOnParticleBoard

We have some other team members testing as well, in LAB and field, to see if this is going to impact us.

Wifi and ethernet are no longer connecting. Have a case going :(

What are the benefits of having a wifi configuration profile installed at the computer level vs the user level?

@AVmcclint that's also entirely scriptable! I do all my certificate provisioning with that workflow, scripted. you can still use profiles with the certs to configure wifi, too.

@bbot machine wifi configurations can stay connected even when a user is not logged in. user configurations will log out of wifi if a user is not logged in.

I've found with computer configuration, the identity preference "com.apple.network.eap.system.identity.wlan.ssid.__ is created and assigned the appropriate certificate, but machines won't connect to wifi.

If I have a "com.apple.network.eap.user.identity.wlan.ssid._" then it'll work. Any idea why the configuration profile deployed via Self Service creates this entry, but pushing it through a policy does not?

I'm deploying through a script that utilizes "profiles -I -F"

@bbot

I think you are on to something. For my system level wired and wifi after upgrading to 10.12.5 the profiles seem to now be looking for a USER level keychain item and NOT the system level keychain like they should.

Here are the errors that are telling us that.

<WiFiAgent[880]> START USER MODE 802.1X USING KEYCHAIN request received

[CWWiFiClientDelegate __startUserMode8021XUsingKeychainWithSSID:interfaceWithName:error:]: Failed to find 802.1X credentials in the user keychain, returned error code -25300

-[CWXPCSubsystem associateToUserMode8021XWiFiNetworkUsingKeychain:remember:interfaceName:authorization:connection:error:]: User Mode 802.1X failed for network (WIFISSIDNAMEHERE) on interface en0, returned error Error Domain=com.apple.coreWLAN.EAPOL.error Code=-25300 "(null)"

Having the com.apple.network.eap.user.identity.wlan.ssid in either login or system keychain appears to work in my case. I've been trying to find ways to get this value created by running a bash script.

Hopefully someone can find what I'm doing useful and add to it. This is what I used when I first implemented 802.1x wifi a few weeks ago using machine AD certs. I pushed this script to all machines and this worked with over 90% success rate in an environment with 600 machines. The same script continues to work when deployed via Self Service 100% of the time. This works in 10.12.5, 10.11.6 and 10.10.5.

However, If I re-push the same script through a policy at recurring check-in, it'll cause the com.apple.network.eap.user.identity.wlan.ssid identity to lose the certificate and thus causing wifi to not connect. I need to be able to re-push the script for certificate renewal purposes. I commented out some of the commands I've tried to get it to re-assign the machine certificate to no avail. The two "security" commands not commented out is what I'm currently using that works in Self Service and first deployment.

If I delete all the profiles, and the identity preference in keychain, then re-push the script. It'll work again.

The config profile I use is as follows:
Computer level / install automatically
1 root and 1 intermediate certificate
1 AD certificate request (machine cert)
1 WiFi payload that uses EAP-TLS. No trust boxes are checked, no common name entered. Select to use AD Certificate (these creates and assigns com.apple.network.eap.system.identity.wlan.ssid into the system keychain. However this isn't enough for it to connect)

#!/bin/sh

#  Wifi Self Service.sh
#  Script to connect to LC-#
#  Brandon Wong 4/24/2017

function connectWifi (){
sudo /usr/bin/profiles -I -F /Library/LC/LC-#.mobileconfig #-U $currUser
    Cert="$compname.#"
    #su "$currUser" -c "security set-identity-preference -n -s com.apple.network.eap.user.identity.wlan.ssid.LC-#"
    #su "$currUser" -c "security set-identity-preference -c $Cert -s com.apple.network.eap.user.identity.wlan.ssid.LC-# /Library/Keychains/System.keychain"
    #security set-identity-preference -n -s "com.apple.network.eap.user.identity.wlan.ssid.LC-#" /Users/$currUser/Library/Keychains/login.keychain
    #security set-identity-preference -n -s "com.apple.network.eap.user.identity.wlan.ssid.LC-#" /Users/$currUser/Library/Keychains/login.keychain-db
    security set-identity-preference -n -s "com.apple.network.eap.user.identity.wlan.ssid.LC-#"
    #security set-identity-preference -c "$Cert" -s "com.apple.network.eap.user.identity.wlan.ssid.LC-#" /Users/$currUser/Library/Keychains/login.keychain /Library/Keychains/System.keychain
    #security set-identity-preference -c "$Cert" -s "com.apple.network.eap.user.identity.wlan.ssid.LC-#" /Users/$currUser/Library/Keychains/login.keychain-db /Library/Keychains/System.keychain
    security set-identity-preference -c "$Cert" -s "com.apple.network.eap.user.identity.wlan.ssid.LC-#" /Library/Keychains/System.keychain
wservice=`/usr/sbin/networksetup -listallnetworkservices | grep -Ei '(Wi-Fi|AirPort)'`
whwport=`networksetup -listallhardwareports | awk "/$wservice/,/Ethernet Address/" | awk 'NR==2' | cut -d " " -f 2`
hwports=`networksetup -listallhardwareports | awk '/Hardware Port: Wi-Fi/,/Ethernet/' | awk 'NR==2' | cut -d " " -f 2`
wirelessnw=`networksetup -getairportnetwork $hwports | cut -d " " -f 4`
    sleep 10
    if [[ $wirelessnw == "LC-#" ]]; then
    echo "Connected to LC-#"
    else
    echo "Machine is not connected to LC-Authorized. Checking identity preference"
    security get-identity-preference -s "com.apple.network.eap.user.identity.wlan.ssid.LC-#"
exit 1
    fi
}

function bindToDomain (){
#removed bind to domain script to shorten in jamf nation

    dependenciesCheck

}

function dependenciesCheck(){

# Check for an AD computer object
ad_computer_name=`dsconfigad -show | grep "Computer Account" | awk '{print $4}'`
compObj=`dscl /Active Directory/CORP/All Domains read /Computers/$ad_computer_name RecordName | awk '{print $2}'`

if [ $ad_computer_name = $compObj ]; then
    echo Matching AD object exists. Continue script...

    # Make sure mobileconfig exists
    file=/Library/LC/LC-#.mobileconfig

        if [ -f "$file" ]; then
            connectWifi
                else
                echo Profile missing. Downloading profile
                jamf policy -trigger LCAuthProfile
                    if [ -f "$file" ]; then
                    connectWifi
                        else
                        echo Cannot connect to LC-#. Mobileconfig is missing.
                        exit 1
        fi
                    fi
else    
    echo "Missing Domain Binding"
    bindToDomain
fi

}

# HARDCODED VALUES ARE SET HERE
Pass=""

# CHECK TO SEE IF VALUES WERE PASSED FOR $4, AND IF SO, ASSIGN THEM
if [ "$4" != "" ] && [ "$Pass" == "" ]; then 
Pass=$4
fi

# Check to make sure Pass variable was passed down from Casper
if [ "$Pass" == "" ]; then 
echo "Error: The parameter 'Pass' is blank. Please specify a value." 
exit 1 
fi

# Variables
currUser=`stat -f "%Su" /dev/console`
echo "Current user is $currUser"

    # Cleanup duplicate machine certificates
    compname=`dsconfigad -show | grep "Computer Account" | awk '{print $4}' | sed 's/.$//'`
    Certs="$compname.##"
    hashes=$(security find-certificate -c "$Certs" -a -Z|grep SHA-1|awk '{ print $NF }')
        for hash in $hashes; do
        echo deleting duplicate certs $hash
        sudo security delete-certificate -Z $hash
        done

# Check dependencies 
    dependenciesCheck

exit 0

@bbot are you on the macadmins slack channel by chance? If so, let me know and we can talk there.

@perrycj I'm not. Fairly new to the Mac scene. Can you send me where I can sign up?

Just go to slack.com and download the client for your mac, or whatever device you're using. Then sign in to the macadmins.slack.com team. You'll need to make a username, etc and then you're in. It's free.

@perrycj I'm in there under the username @brandobot

Just to note our issue was the DC certificates used for client authentication for 802.1x. Looks like after this update our clients are no longer able to validate our DC certificates even though our CA certificates are trusted. We are using certificate base authentication for all our systems. I'm going to do another test and push our DC certificates out through our configuration profile.