802.1x Wifi Profile, I created a mess

[skeb1ns]

Hi,

I've recently discovered that I accidentally left the credentials of a specific machine filled in the Username and Password fields used for testing in my 802.1x Wifi Profile payload for machine authentication while checking the box to use directory authentication:

As a result, every machine has now the 802.1x entry for our company Wifi network filled with that credentials instead of the unique device credentials:

So the macbook losx-04595 has suddenly become very important since deleting that device from our AD would result in a loss of wireless connection for every managed device... cringe

Any idea what the best way would be to fix this? I already corrected the Configuration Profile so new devices don't have this problem but there are still 200+ macs that have this issue at the moment.

A few things I already thought about:

• Reapplying the profile: There is currently no way test this individually and I don't want to do this in a big bang. I could exclude 1 machine from the policy and the add it back again but Casper would then first delete the 'old profile' resulting in network loss and failure in reapplying the profile.

• Creating a new profile and remove the old one: Pushing the new profile isn't the issue, but a soon as I removed the old profile, the BOLNL-MW entry would also be deleted because both profiles use that same entry, resulting in an applied profile with no 802.1x entry in the System keychain and of course no network.

One solution would be to somehow create the new profile and use a different name for the 802.1x entry instead of the SSID name which apparently is a default thing. I then could deploy the profile divided into phases and be able to remove the 'old' profile without possibly killing everyone's Wifi.

Does anyone has an idea? Your help would be greatly appreciated!

[skeb1ns]

Anyone?

[plawrence]

@skeb1ns

I dont envy your position, I think you have 'profiled' yourself into a corner that is practically impossible to get out of :( Have you tested if a machine can have two wireless profiles installed? If so, you could consider creating a second SSID with a different name, this would change the 'name' of the Keychain entry, then:
- rollout a profile to your machines so they can connect the new SSID
- remove the original profile
- rollout the fixed original profile
- remove the new SSID profile
This process has the benefit of being able to be tested on a single machine first, as long as you can create another SSID.

If a machine cant handle two wireless profiles, then I think your only solutions are going to be manual ones.

[Sanchi]

Thats a tough one. Like you say @skeb1ns if you remove the working profile it takes the machine off the network so a new/updated one can't be pushed.

I would ask your network guys to create a hidden SSID - (lets call it tempSSID) thats a duplicate of the current one in terms of its config, but with a different name (lets call it realSSID). Then create a profile pointing to tempSSID and push it.

When pushing it you can use this script to set the SSID order on the Macs to have tempSSID at the top of the list so thats the one the Mac joins first:

Reorder SSIDs script

Then when you're happy your Macs are good with tempSSID do the reverse - thats to say send out the the updated realSSID profile and an updated version of the SSID recording script.

I think the overlap of another working SSID should do the trick and people using the machine probably won't notice a slight name change. For me that would be the last disruptive method vs making your users plug in to ethernet (like pulling teeth I imagine). Your network guy may be reluctant but if its necessary for the business, its necessary. The alternative.... well you know better than us what the alternative is in your environment and it probably isn't going to be fun.

Just saw you post and I've had lengthly issues with setting up 802.1x in the past so thats my best suggestion.

An alternative is manually pushing out a new profile inside a PKG. Obviously that would require network access (to push that) but in theory it could be possible to say execute/install the PKG when not network is detected. That way when you remove the profile from scope in the JSS, the updated profile automatically installs on the persons Macs. That would involve bit more scripting but in theory....