WiFi during Mac deployment

[Jan_H]

Hi! 

We are looking for a way to enable our user to enroll new macs onsite with our corporate wifi.

WiFi is a SSID Hidden WPA2-Enterprise, so users have to use their AD credentials to connect.

During Zero-Touch-Setup when the mac setup is prompting the user to connect to a wifi, majority of them are not able to connect a hidden ssid wifi with ad login on top, macOS prompts for the password which user have to leave blank, press enter and then gets asked for their AD Credentials.

Or we have issues with the wifi after Initial deployment when the user made it to the wifi and the macs are terminating the connection right before Jamf Connect.

How do you guys handle this? A separate "Setup Wifi" and pushing the right corporate wifi after setup with an config profile? Seems not ideal, so we are open for inspiration :)

[AJPinto]

JAMF cannot place any configuration profiles on a device until after the MDM profile has been installed. There is no way to have WiFi setup before a device enrolls. As far as Wi-Fi dropping at JAMF Connect if manually connected during setup. JAMF Connect does get itself in the WiFi stack of things, raise a ticket with JAMF on that one.

Probably the simplest solution for enrollment, is to have an enrollment only network enabled that does not use 802.1x and can only access JAMF and Apple's necessary bits to complete enrollment.

[steve_summers · Accepted solution]

@Jan_H ...you are treading down a road I just travelled and it was not fun.  The exact same ask, use our corporate 802.1x wifi for staging devices.  Let me tell you what I found.  Maybe it will help you.

-During Setup, when you are prompted to chose which wifi and you enter credentials, they are used to make that initial connection to Jamf and pull down the pre-stage settings/profiles.  When complete, that wifi connection is dropped since there is no end-user based keychain (yet) to store credentials.  

-Jamf Connect (in our case) comes up and since there is no keychain and no network connection at this point, it displays errors since we are operating as the "mbsetupUser" account...not yet as an end user

-Here, at this Jamf Connect screen, Apple has the OS configured where you cannot chose the corp wifi and enter and store a user name and pw for wifi unless the Mac is domain joined (and who wants to do that anymore).  

-Jamf has informed me that there is a feature request submitted to Apple asking to allow credentials to be input in that screen, but they've not allowed it to date.

-A way around this is to use certificate based, device authentication to get on the wifi network at the Jamf Connect screen but that could create a lot of re-architecting a network.  

-Apple DID say that the best practice maneuver is to have a "staging wifi", open to the internet and once the device has been configured, that connection can be removed (so to speak) and the device join the corporate wifi.

That's where we left it....we have an open wifi network for staging devices, and I'm presently preparing a script to run removing the open network from the list of networks and adding our corp wifi as the top listed network.  

That was a lot.  Hope it didn't confuse you.  

[pbenware1]

Several years ago we moved to a network registration model, requiring users to register devices using their AD user name and password.  This broke our ability to allow devices to connect to wireless networks during initial enrollment, or during a wipe/reinstall, due to the certificate requirements, etc.

Like others, we ended up with both an open wifi network with limited access to the necessary services that is available to field techs in limited areas or giving the them pre-registered USB ethernet dongles.

We also have a small facility (a workbench in what is effectively a large closet) that we use as a production line for unboxing /configuring multiple computers at once where we had the network group install a switch that was filtered to allow access to all necessary internal and external services so we did not need to deal with wifi or pre-registered e-net adapters.

None of these solutions is ideal; all are subject to to some degree of misuse, but we are able to do the work we need to do and keep the security people happy.