User authentification for Wifi use 802.1x protocol.
To connect devices need a WPA supplicant such as SecureW2
Depending of the supplicant you use you will or not will be able to use do a SSO with the windows domain login/password.
iPhone and iPod touch have built in WPA supplicant. I don't know for PSP/BB. SecureW2 has a Windows Mobile version.
I'm sure that you could enable a captive portal for WiFi only without having to create to IP Network. You just need to put wireless access in a vlan and wired access in another vlan then put the portal between both vlan. This is like a transparent firewall.
802.1x need to have a supplicant on computers. If computers that need to use the Wifi are known you just have to setup the supplicant on them and it's a great solution. If you want to make your wireless access accessible by visitor or things like that it could be a nightmare because they need the supplicant etc..
A captive portal is a bit less secure and need user to authenticate manually each time they connect. It can be a bit borring.
A good solution from my point of view is too have both. A 802.1x access that give you the same as if you were wired on the lan and a captive portal that give you access to less things (access to internet port 80, limited access to local lan, ...)
You're going to want to stick with creating/ordering Network Policies to do what you're trying to do. Just use the one default Connection Request Policy that is wide open, and then secure via the NPs.
You can "divide the two" as you say, by limiting each Network Policy you've created with sufficient conditions, such that in combination, multiple conditions together achieve your objectives. It looks like you've specified only one condition on each policy - network group membership. As you've discovered, this won't work. When your RADIUS-enabled device asks your RADIUS server to authenticate your user, the RADIUS server forwards the users' credentials to AD, which successfully matches the credentials (cause they're vague at this point), and returns a positive to the RADIUS server, which in turn tells the device to allow the authentication. I'm forgetting all the proper RADIUS lingo here - but basically that's what's happening.
So, stack another condition (or more) onto your policy to get what you want. Sounds like you want the switch policy to work with users in the Domain\NetworkGroup, and only on your switches (these requests should never come from your ASA's IP, or some printer or user workstation or whatever). Under conditions, look under the RADIUS client section - ClientFriendlyName, or ClientIPv4Address, for example. If the conditions include that the request is coming only from one of your predefined switch IPs or names, it won't "authenticate" requests coming from your ASA IP.
Do the same for your vpn policy too. You should be good from there. You may want to start with clean Network Policies though. I don't think you're going to be able to use the settings to update non-compliant clients without some more work (and whole other policy type too).
Also, you can look at your RADIUS logs if you want more info on what its actually doing. I believe they're under system32\logfiles. You may have to enable it on your NPS server, if its not already. You can google for tools to help you read the log files, as they're not really user friendly. In a pinch, MS has an article that lists all the fields, in order. Look for the tools though (IASlogviewer? or something like that?).
Best Answer
You're nowhere near cause for concern. A typical RADIUS access server has a configurable timeout of several seconds (e.g. Brocade switches have a 3 second timeout, Cisco switches have a 5 second timeout, and they all allow you to change it).
Just keep your network connections terrestrial (that is, not over satellite) and you're not likely to run into any issues. If you need to increase the timeout, your existing switches should allow you to do that.