Adding WPA2 Enterprise network but allowing users to supply credentials

Network Configuration Profile should be able to handle this... Just click the "Hidden Network" and after selecting the Security Type check the "Use as a Login Window configuration"

Thanks for the response! However, when I select "Use as a Login Window configuration", the box becomes unchecked as soon as I save the payload settings.

It looks to be a known bug starting in 10.0.0 i believe...

[PI-004491] The Use as a Login Window configuration checkbox fails to remain selected for computer configuration profiles with WPA2 Enterprise as security type.

think its fixed in 10.6

Thanks, all! I've scheduled an upgrade of our dev environment for tomorrow, so hopefully that resolves the issue. I'll report back once it's upgraded and I've had a chance to test it.

10.6 fixed the checkbox issue, but when I put the profile in Self Service and try installing it, I'm not actually prompted for credentials. System Prefs show that I did get the profile, but I don't connect to the network.

@DaK3ll3r Not that this helps with your question, but more food for thought...

It's been a while since I looked at WiFi security recommendations, but I thought that general consensus was that hidden SSIDs were now considered false security and not worth the trouble they caused. In my previous organization where we had a campus with over 1000 MacBook Airs the recommendation from Cisco and Apple was to broadcast the SSIDs to reduce connection time.

@DaK3ll3r I'm having the same issue right now, did you ever get around to fix this? Network preferences show the "disconnect" button which indicates that the computer knows that it's supposed to connect to my wifi but the popup for the login credentials is not showing.

@mathias.kuse We ended up using NoMAD (aka Jamf Connect) to deploy certs and an identity preference, which associates our corporate SSID with the cert. We then scope a policy that applies a configuration profile that tells the machine to auto-join using EAP-TLS. Together, NoMAD and the config profile deployed by Jamf make for a pretty smooth connection, though the user does have to allow the eapolclient to access the cert's key.

Hope that helps!

I am having the same issue - I see the Disconnect button and every few seconds it shows "Authenticating" but no prompt for username and password. I can sometimes click on Disconnect and then Connect. The login prompt then appears and I am able to log in and join the WPA2 Enterprise network.

@leojason sadly I still haven't found a solution and jamf is still analysing the issue. Will keep you posted.

@mathias.kuse +1 on this, please update us if you hear back regarding this issue. I'm deploying WPA2 Enterprise shortly, and would love to make it easier for the users through Jamf

@mathias.kuse +1, having the same issues here so would be very interested to hear if this gets solved somehow.

any update??? having the same issue.

@DaK3ll3r Can you share some more info about how you're doing this? Our ISE server requires AD user certs which is super unreliable and seems to be tying me to the bind. I've tried messing around with the Identity, Certificates, and AD configuration profiles but I haven't been able to get anything to work at all besides AD Certificate.

@DaK3ll3r are you able to expand on what you did to get this working with Jamf Connect?

What settings did you use to get the cert from the CA via JCS?

What does the Config Profile look like? Did you then PKG it up to install via a Policy? Why?

We actually moved away from JCSync, since it required already having access to the CA and that users retain the app on their machine in order to handle renewal. To get the cert in that original use-case, though, we did the following:
- configured the app to point to our Okta domain
- enabled the key to get a cert automatically
- then changed the Get Help menu item to read "Get Certificate"
- configured it to launch a self service policy. That policy would a) confirm connectivity to the CA, b) unload and reload the agent to obtain a cert, and c) touch an empty file against which the supplicant config was scoped. - That supplicant config included a network payload that told the machine to autojoin our corp network using TLS.

I hope that helps! We found that using ADCS was much more flexible (can be deployed outside the corporate network, the cert + supplicant were in one profile, and it auto-renews), and recently migrated to that. We still leverage Jamf Connect to authenticate a user, and then deploy ADCS certs once a user has authenticated. For new machines that go through Jamf Connect Login, certs are deployed automatically during splashbuddy, and for existing machines on which a user has never authenticated they through a similar JC Sync process as above but in which the "Get Certificate" menu command deploys the ADCS profile directly.