It sounds like what you're trying to do is to disable cached credentials, requiring that credentials be validated by an LDAP server in order to basically enforce some additional protections. The most direct way to enforce this is to not allow locally cached (mobile) accounts on login. You could also script a LaunchAgent that automatically logs out someone that is logging in if there isn't a valid network connection.
However, there are a couple things you'll need to make sure you consider with all of this. The first is that, if you use FileVault encryption, there isn't any network connection at the encryption screen so it will be using cached credentials and I think that you have to have mobile account enabled to enable that account for FileVault.
The second is that you are requiring WiFi, which implies you are requiring this on laptop machines. I would feel much more comfortable requiring a network connection if it was a desktop machine that was on a wired ethernet connection and never left the building. On a laptop, you could run into situations where a user is completely unable to log into the machine: WiFi turned off before restart/logout, machine needs an SMC reset to get WiFi working again, WiFi network unavailable or interference prevents connection, or laptop just isn't in the building. Any of these things happening will completely prevent a user from logging in.
I'm not sure exactly what you are trying to accomplish in the end. Just be cognizant of the impact you will potentially have on your user population, and the feedback you are likely to get back due to unintended consequences, by enforcing something like this.
Thanks for the input. The issue I am seeing is that with the MacBook Airs the first time someone goes to log in. They enter the username and password before the wireless gets an ip address and the login fails. Once credentials are cached we have no issues.
Ok, so you're more interested in delaying the login window until the network is available just for the initial login, when there are no mobile accounts on the machine.
I don't know of any good way to do this via a technical solution. It might be easier to write instructions that tell the user to either connect via a wired connection, or verify that the wireless connection has connected, prior to attempting to log in the first time.
Yeah, this is just something you'll have to deal with I think, I wouldn't try to implement a technical solution (which adds complexity and opportunities for harder-to-diagnose issues). The impact of users waiting for a few moments (or just trying again when the first attempt fails) is pretty minimal.
You need a wireless profile that authenticates against your wireless before login, based on the user who uses the device.
We have a profile which will authenticate their wifi with their login credentials, but for the most part this can be difficult, because each user will have a personal password.
With our students, we used a generic password for them all, and allowed them to change their password once they are logged in. Which combined with a NPS server, will then require them to update their wifi password on next login.
Messy but works most of the time.
That's...really strange! Can't say a space in an SSID causing issues is something I've seen before, though I have seen spaces in LDAP usernames cause issues.
But, hey, a win is a win, right?
I know you had a case open with your TAM on this, and I'll pass this along just to make sure he's aware of what fixed it.
JAMF Software Support