Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. Join us in person at the ninth annual Jamf Nation User Conference (JNUC) this November for three days of learning, laughter and IT love.

Sierra 10.12.5 Upgrade breaking Corp Wifi

With the release of 10.12.5 today, I immediately upgraded one of my test systems. Everything was working fine on said system before the upgrade. After the upgrade Wifi fails to connect. Have attempted to re-configure wifi in order to see if it just corrupted, but no dice.

I've opened a support ticket with Apple, but I'm curious if anyone else is seeing something similar.

Like Comment
Order by:
SOLVED Posted: by chisox1

I have had the same issue..

Like
SOLVED Posted: by isradame

Having the same issue on some of my test Macs.

Like
SOLVED Posted: by chisox1

Let us know what Apple responds... debating on opening a ticket myself

Like
SOLVED Posted: by Sdwick

Same issues here... You guys using WPA2 enterprise I am guessing?

Like
SOLVED Posted: by kquan

What model computers are you guys trying on?

So far I've tried a 15" late 2013, 13" late 16 non touchbar, and a 13" late 16 touchbar all updated to 10.12.5 and was able to sucessfully connect

https://support.apple.com/en-us/HT207797

802.1X Available for: macOS Sierra 10.12.4 Impact: A malicious network with 802.1X authentication may be able to capture user network credentials Description: A certificate validation issue existed in EAP-TLS when a certificate changed. This issue was addressed through improved certificate validation. CVE-2017-6988: Tim Cappalli of Aruba, a Hewlett Packard Enterprise company

I did get a "Verify Certificate" before continuing to connect to my internal network here. Once I confirmed, I was on our internal network without any issues

Like
SOLVED Posted: by nwiseman

Well...that makes me both happy I'm not the only one and extremely sad that it seem's like a bigger problem.

So far Apple has asked me to send it Wifi logs and SysDiagnostics. While they're looking at them, i've been doing some looking at logs as well. What I've found is that when it attempts to do a matchAndJoinSSID: it says it's "temporarily disabled, next"

Will report back anything I hear from Apple.

Like
SOLVED Posted: by nwiseman

So...I found our issue before Apple did. Maybe it will be the same for all of you.

Our root and chain certs were not be accepted even though they showed up as validated. I had to go in and set the EAP Trust setting to "Always Trust". Once I did that and restarted wifi everything kicked in immediately.

Now to go back and figure out configuring that trust setting.

Like
SOLVED Posted: by bbot

How is your wifi authentication configured? Ours requires a root + intermediate cert to request a machine cert, then uses the machine cert to authenticate to wifi.

We deploy root + intermediate certs, AD cert request, and wifi config all through a configuration profile. On one machine, I was prompted for my login password to allow a change to the keychain.
On another test machine, my machine was kicked off the wifi. In the keychain, I found the com.apple.network.eap.user.identity.wlan.ssid.WIFINAMEHERE had a red X and that the preferred certificate was set to None.

Like
SOLVED Posted: by aporlebeke

No issues here. We have profile-based Wifi logon to accomplish a machine-auth type deal on our Macs, so nothing with certs (we're an AD shop).

Upgraded from 10.12.4 to 10.12.5 on test machine

Like
SOLVED Posted: by alexjdale

I was working with nwiseman on this and to clarify, it appeared to only be an issue when the root/chain certs were imported using a configuration profile. At my company we import them directly to the keychain using the security command with appropriate trust options. Other than that our environments were the same, but his wasn't working and mine was.

Like
SOLVED Posted: by AVmcclint

It has broken both our 802.1x Wifi and Ethernet connections. This is really really really bad. I EVENTUALLY got a prompt to validate a cert, but it requires Admin credentials to do so. There is absolutely no way this is going to work.

Like
SOLVED Posted: by Retrac

Same for me. Updated to 10.12.5 from 10.12.4 or built from scratch with an AutoDMG restore and Our 802.1X Wifi now does't connect.

Like
SOLVED Posted: by dprakash

802.1x Machine based Wifi here and working fine on 10.12.5

Like
SOLVED Posted: by CasperSally
Notes or Updates Since Initial Image Was Released

We're good here, too.

Like
SOLVED Posted: by AVmcclint

After I got back on the network, I restarted the computer and found that reconnecting to the network is all wonky now. WiFi won't even try to connect until after completely logged in and at the desktop (which means any Login triggers won't happen), Ethernet gets stuck in an infinite loop and never connects on its own. It gets a self assigned IP for a few seconds then falls back to "not connected" and then gets a self assigned IP... wash, rinse, repeat. The only way I can connect via Ethernet now is to click on Disconnect, wait a few seconds then click Connect. Then I get a valid IP.

Like
SOLVED Posted: by jasonaswell

Same problem for us. Just submitted an enterprise case (100194327871). Only workaround that works for us is to manually go into the system keychain and set issuing and wireless certs to "always trust" (the root is already set to always trust). Doesn't seem to be a good way to script this since the certs are deployed via config profile and already in the system keychain (so we can't really leverage a security add-trusted-cert command)

Anyone having any luck setting the update to be ignored? I can't get sudo softwareupdate --ignore "macOS Sierra Update-10.12.5" to actually ignore the update. I've also tried "macOSSierraUpdate-10.12.5" "Mac OS Sierra Update (10.12.5)" "10.12.5" and "macOS Sierra Update" to no avail.

We have update scheduled to push to clients this weekend but looks like I'm going to have to reschedule until this is fixed cause this is BAD.

Like
SOLVED Posted: by seann

@jasonaswell Not an immediate solution, but I'd suggest setting up reposado or another SUS so that you can control distribution

Like
SOLVED Posted: by jasonaswell

We recently moved away from using a SUS to instead lean on caching server since Apple is sunsetting their SUS - this also makes it easier for users not on site to keep up to date. We've got a blacklist script that we run to ignore problematic updates, but unfortunately I can't find a phrasing for this update to successfully ignore it. This is the direction Apple has been moving in, so we were trying to skate to where the puck was heading, but unfortunately between the directory auth lockout issue in 10.12.2 and earlier, and now this - it's clear that we need to rethink that since Apple is failing to consistently test critical enterprise level functionality.

Like
SOLVED Posted: by StoneMagnet

FYI, my test machines running El Capitan 10.11.6 experience the same issue after installing Security Update 2017-002 Ignore that comment. Further investigation revealed AD binding issues with test machines were the actual problem, and Security Update 2017-002 has not impeded the ability of our 10.11.6 systems to authenticate via 802.1x for WiFi.

Like
SOLVED Posted: by jasonaswell

FYI, ignoring "macOS Sierra Update" does actually work for anyone who is managing updates via the software update command.

Like
SOLVED Posted: by kendalljjohnson

To second @jasonaswell, I had to sudo the ignore command to get the update to be ignored (wouldn't need to do so from a JAMF script).

Here's my output from terminal in testing to see how it can be done:

bash-3.2$ softwareupdate -l Software Update Tool Finding available software Software Update found the following new or updated software: macOS Sierra Update-10.12.5 macOS Sierra Update (10.12.5), 873261K [recommended] [restart] iTunesXPatch-12.6.1 iTunes (12.6.1), 191180K [recommended] bash-3.2$ sudo softwareupdate --ignore "macOS Sierra Update" Ignored updates: ( "macOS Sierra Update" ) bash-3.2$ softwareupdate -l Software Update Tool Finding available software Software Update found the following new or updated software: * iTunesXPatch-12.6.1 iTunes (12.6.1), 191180K [recommended]
Like
SOLVED Posted: by tdurdan

Same issue here. Intermediate Certs are deployed via config profile and configured with Use System Defaults. Roots are set to always trust.

Like
SOLVED Posted: by perrycj

No issues here on 10.12.5 and a fresh 10.11.6 Mac with the latest Security update from yesterday. Full 802.1x on wired and wireless.

For those have issues, in the trust section of your configuration profiles delivering your payloads are you trusting by common name or by exact certificate name?

If you're trusting by common name, that's probably what the issue is. Make sure that box is unchecked and check to trust exact certificate and see if it's resolved.

Like
SOLVED Posted: by bbot

@perrycj Our trust section in the config profile is blank. For the trust section, would this be the certificate required to connect to wifi? In our case, we use machine certificates requested from AD. How do I specify the exact certificate name in a configuration profile when all the certificate names are different?

Like
SOLVED Posted: by mbezzo

dumb question? Where's the "Trust" section? It must be right in front of me, but I can't find it!

Thanks!

Like
SOLVED Posted: by bbot

@mbezzo It's in the wifi payload of the configuration profile. Scroll to the bottom and click the Trust tab.

Like
SOLVED Posted: by mbezzo

@bbot - ahhhh, thank you. :)

Like
SOLVED Posted: by jasonaswell

@perrycj are you including all of your certs in the cert chain in that same configuration profile and then selecting those? We deploy the root and intermediary certs in a separate profile, so I'm attempting to use their common name (and leaving the exceptions box unchecked) but it's not making a difference. I'm waiting on the engineer working our case to send us further suggestions - but I was just curious about whether or not you have your certs all within the same profile or split apart multiple profiles like we do.

Like
SOLVED Posted: by chisox1

Adding our intermediate cert as a trusted certificate seemed to fix it for our organization.

Like
SOLVED Posted: by bbot

@chisox1 just to confirm, you checked the box for the intermediate cert under Trusted Certificates Certificates trusted/expected for authentication

then redeployed the configuration profile, updated to 10.12.5 and confirmed the wifi stayed connected?

Like
SOLVED Posted: by chisox1

Correct! How I will deploy it to everyone without breaking them is a different story.

Like
SOLVED Posted: by bbot

@chisox1 Are you using AD certificates for wifi? How are you currently deploying the profile?

Like
SOLVED Posted: by perrycj

@jasonaswell All the certs we use are deployed with our wifi payload and in that trust section, I check off our Root CA as the trusted cert. You can check whichever cert is appropriate for your environment. Our ethernet profile has no certs in it at all because the trust is established with the certs from the wifi profile.

I think if you just avoid using the common name at all and just check off the cert name as the trusted cert, you should be good.

Like
SOLVED Posted: by perrycj

@bbot its just the trust that gets redeployed.. meaning you don't have to worry about having to generate another machine cert from AD (although it will happen automatically when you redeploy the configuration profile anyway). if you select to use either your intermediate or root CA as the trusted cert, not use the common name and redeploy that profile, it should work fine. Does that make sense?

Like
SOLVED Posted: by bbot

@perrycj Makes sense. The part where I'm stuck is that I have a separate config profile that has the root + intermediate certificates. We deployed the certificates before we rolled out 802.1x wifi. (this is still active)

Now we have a separate profile that includes both root + intermediate certs, AD cert request and wifi config. I'll need to do some testing, but I think making the trust setting in this wifi config and re-deploying should resolve it.

Like
SOLVED Posted: by perrycj

@bbot sure that's fine too. In that certs profile, just make sure to check off the box for the cert you want to trust and uncheck the box from common name trust and you should be fine.

Like
SOLVED Posted: by bbot

@perrycj In the certs profile, I don't think there's an option to check the box to trust. It'll have to be in the wifi configuration profile. The cert profile I have only deploys the root and intermediate certificates

Like
SOLVED Posted: by perrycj

@bbot Yes sorry.. I meant on the connection having the issues with 10.12.5.. so if it's wifi, then in the trust section there. It has to be defined somewhere so it should be in your wifi profile under trust.

Like
SOLVED Posted: by scheb

So it appears the change is that we must explicitly tell the supplicant (via network payload trust tab) what radius server(s) it is authorized to provide the cert to (either by trusting the radius server's CA or inputting server names). Before it worked without this. You will probably have to add that cert to your certificate payload if the radius server's cert is signed by a different CA than your client cert.

Like
SOLVED Posted: by chisox1

Our official response from Apple was as follows
"You can think of the authentication process as a two step process; first it will check to see if the certificates are in the keychain and trusted, then it will check to see if trust has been anchored in the Wi-Fi profile. If it meets these two criteria it will connect.
If trust isn’t anchored in the profile then it will check to see if there is a trusted server certificate name in the profile. If there is, and it is the domain used to sign the certificates, then the machine will successfully authenticate."

@bbot Our current setup is deploying AD certs through the config profile. We also have a Root Cert profile. In my very limited testing so far, having a profile that deploys all certs and having a duplicate "trust" certificate in the wireless profile has not broken anything. We are pushing the profiles via MDM.

Like
SOLVED Posted: by dpratl

Hi all,

We encounter the same problem, no connection to our WiFi possible.
The WiFi network is cert based.

What seems to be working: (suggested by @nwiseman )
Set in the Trust Section of that certificate EAP to "Always trust"

I tried to handle that inside the Configuration Profile, but that wasn't working at all (it even disabled the Workaround). What am I doing wrong here?

Thank you very much
BR
Daniel

Like
SOLVED Posted: by jason_d

@dpratl I deploy my root and intermediate certs as a part of the same profile and they show up under Trusted Certificates and allow me to check them as trusted.

Like
SOLVED Posted: by bbot

Still running into some issues here. On my test machines, I am unable to connect to WiFi completely after checking the Trust box for the intermediate certificate.

Can someone review my config? This is getting installed on the computer level. AD certificate is requesting for a machine certificate to authenticate. Certificates are requesting properly, it creates the com.apple.network.eap.user.identity.wlan.ssid in keychain and assigns the appropriate certificate.

On 10.12.5, I can have the user re-install the current configuration profile (without the intermediate box trust checked), and it'll re-connect to wifi fine. It's just that the wifi disconnects after updating to 10.12.5.

I also have a separate configuration profile that deploys just the root + intermediate certificates to the system keychain. (these have been on the Mac prior to the wifi config profile being deployed)

Like
SOLVED Posted: by jason_d

@bbot you need to trust the root and sub, also I'm trusting by exact cert name where you have 'root' and 'sub' and it's working here.

Like
SOLVED Posted: by bbot

No dice. I've tried trusting both certificates, and adding the common names into the trust.
I've tried going into keychain, right clicking the certificates and setting the trust to "Always Trust" and it still won't connect to wifi... so I'm not sure if the issue is with the intermediate and root.

Like
SOLVED Posted: by dgreening

We trust both the root and the sub (which are included in the profile) in the Network payload and it has been working fine for us on our 10.12.5 testers.

Like
SOLVED Posted: by jason_d

@bbot are the certs getting installed and marked as trusted?

Like
SOLVED Posted: by bbot

@jason.desveaux the root is marked as Always Trust all the way down the list. The Intermediate is marked as valid, trust is set to use system defaults and no value specified. This is after marking them both as trusted in the configuration profile.

The messed up part is even after manually trusting the intermediate, it still won't connect.

The only way I can get it to connect to wifi is if none of the boxes are checked in the configuration profile.

Like
SOLVED Posted: by jason_d

@bbot strange... is your identity preference in the keychain pointing at a trusted cert?

Like
SOLVED Posted: by bbot

Looks fine to me. I have both system and login keychain.

Like
SOLVED Posted: by jason_d

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

Like
SOLVED Posted: by bbot

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

Like
SOLVED Posted: by MatG

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.

Like
SOLVED Posted: by Nix4Life

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

Like
SOLVED Posted: by AVmcclint

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.

Like
SOLVED Posted: by bbot

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.

Like
SOLVED Posted: by bbot

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.

Like
SOLVED Posted: by Retrac

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.

Like
SOLVED Posted: by dprakash

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.
Like
SOLVED Posted: by dprakash

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

Like
SOLVED Posted: by AVmcclint

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

Like
SOLVED Posted: by dprakash

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

Like
SOLVED Posted: by donmontalvo

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.

Like
SOLVED Posted: by ClassicII

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

Like
SOLVED Posted: by bbot

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

Like
SOLVED Posted: by nkalister

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

Like
SOLVED Posted: by nkalister

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

Like
SOLVED Posted: by bbot

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"

Like
SOLVED Posted: by ClassicII

@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)"

Like
SOLVED Posted: by bbot

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
Like
SOLVED Posted: by perrycj

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

Like
SOLVED Posted: by bbot

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

Like
SOLVED Posted: by perrycj

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.

Like
SOLVED Posted: by bbot

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

Like
SOLVED Posted: by juttmartin

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.

Like
SOLVED Posted: by juttmartin

After testing it looks like pushing these certs out through a configuration profile are not being trusted. So I just packaged them up to install them that way. Looks to be working fine authenticating through 802.1x. I'm just going to create a policy to publish out this package install. Here is a the the security command that can be used to import and trust the certs:

security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain /tmp/PATH_TO_CERTIFICATE
Like
SOLVED Posted: by MatG

The reply I got from Apple

To resolve this on your end, make sure that you anchor trust to the appropriate Intermediate or Root certificate in the Network payload or your configuration profile. In the profile, this will create a key for “PayloadCertificateAnchorUUID".
Like
SOLVED Posted: by AVmcclint

@MatG What exactly does "anchor trust" mean and how do we do that in the context of using JAMF Pro?

Like
SOLVED Posted: by MatG

I was posting to hope someone else would answer that!

Like
SOLVED Posted: by Jedberg

We have been working with Apple on this and the fix is to put your Certs into your 802.1X Profile as a separate Payload. Once the Certs have been added you need to Trust them in the Profile. Go back into the Network Payload, click the Trust tab and select the Certs you added in the Certificates Payload. You MUST include the whole Cert chain from Root down. Good luck!

Like
SOLVED Posted: by bbot

I'm wondering if there's something funky with my environment. I've tried combinations of separate profiles with just the certs. Tried trusting just the root, just the intermediate, or both. I've also tried typing in the common name, with combination of checking the boxes and without. The only way I got my wifi to connect was having nothing checked and nothing typed in for common name.

Like
SOLVED Posted: by dpratl

I tried to create a new Configuration Profil including the certificates, the network payload with the suggested settings and the AD Certificate Payload which I think I need for the network payload (Identity Certificate)

But this just failed to install on my MacBook
"The 'Active Directory Certificate' payload could not be installed. The certificate request failed."

But if I switch back to the standard AD Cert & Certificate Payload Conf Profile it is immediately installed, but in this Profile is not the network payload, so I cannot trust the certs. The settings are absolute the same.

Any ideas why?

EDIT: I found the problem.
There was a blank in front of the Certificate Server Address. (noob error - sorry for bothering you)

Now it is working with the Configuration Profile like a charm. Thank you very much JAMFnation! :)

BR
Daniel

Like
SOLVED Posted: by clem

I've lost all bonjour printers ( over wifi )when upgrading to 10.12.5 , If i patch the ethernet in. Then the bonjour printers re-appear. 10.12.5 with wifi connection to network you can only see bonjour shared printers and then the drivers fail. Very strange. This has happened on a number of macs, 10.12.4 was fine.

Like
SOLVED Posted: by Leeks

I'm having the same problem and this fixed it immediately. Hope this helps other people.

How to Fix SSL certificate problem

Click on the Wi-Fi icon on your Mac’s menu bar
Select Open Network Preferences..
Click Advanced and then choose the current network that you’re connecting to
Select the Subtract sign next to the addition sign and click Ok
Stay on the same Network Preferences… page and click on Wi-Fi on the left side
And click the subtract sign at the bottom > Apply
Now, click the addition sign and choose Wi-Fi under Interface and Service name
Click Apply to save all your changes
Re-connect to the Wi-Fi network that you were having trouble with earlier. This will help you fix the SSL error in Google Chrome.

Like
SOLVED Posted: by dprakash

Thought I'd post an update about my 10.12.5 and certificates woes with wifi, we hadn't updated the version of ios on our Cisco wireless LAN controller in nearly 2 years, we updated them last week to the latest, without changing my configuration profile it connects instantly and super fast too and also resolved this intermittent problem we had with connecting to smb shares over wifi.

Like
SOLVED Posted: by jweitzel

Redacting. Wrong place.

Like
SOLVED Posted: by Samdy

Anyone have file wifi.mobileconfig that using PEAP EAP-TLS authentication with certificate on Mac OS 10.12.6 ?
Help me plz Thanks,

Like