3

I've got several domain-member laptops which commonly roam to places where there aren't any network ports available. Occasionally, during these times, the laptop may be used by someone who has not logged into it previously - therefore, they cannot rely on cached credentials to allow them onto the system.

We also have a fairly ubiquitous wireless network that allows us to connect using our domain accounts for 802.1X authentication. Under this configuration, the Dell WLAN Card Utility has a feature which allows the system to connect to the wireless network at logon (after the user has entered their credentials) prior to attempting authentication to the domain for local system access.

Here's the option in the configuration screen:

enter image description here

Here's the feature in action, just after submitting user credentials at the login screen. This occurs before allowing the user local access to the system. The computer initializes the wireless adapter, searches for the wireless network, authenticates to the wireless network (presumably with the supplied user credentials), grabs an IP address, and then searches for a Domain Controller. Once the Domain Controller is found, the user (if authenticated) is then logged in to the local system.

enter image description here

The above screenshots are from Server 2003, but I'm upgrading the laptops to Server 2008 and would rather not install the vendor-specific utility if it is not needed. Is this a feature that is built-in to newer versions of Windows? If so, how do I enable it without having to use the vendor-specific configuration utility? Could the configuration be pushed through a GPO?

Iszi
  • 2,376
  • 8
  • 25
  • 33

4 Answers4

3

Try this (on the client computer):

  1. Login locally using a user with administrator privileges.

  2. Connect to your office's wireless network, save the credentials, and then make sure you check the "Connect automatically" checkbox.

  3. Open a command prompt window and type the following command to find the profile name of your wireless network: netsh wlan show profiles

    netsh wlan show profile

  4. Let's say the profile to use in the example is "office-network". Open regedit and look for the key HKLM\Software\Microsoft\Windows\CurrentVersion\Run

  5. Create a new String Value (REG_SZ) at that location, and name it anything you want (i.e. WIFI_Connect), and enter the following command string: %comspec% /c netsh wlan connect name="<profile name>" where profile name in our example would be "office-network".

  6. Reboot the laptop for this to take effect.

  7. If it still doesn't work or fails to connect to your office network at pre-logon, try enabling the following Local Group Policy (using gpedit.msc): Computer Configuration\Policies\Administrative templates\System\Logon\Always wait for the network at computer startup and logon. A full description of what this policy does is present on the dialog when you edit it. (It's too long to paste here).

  8. If it still says it cannot find a valid domain, it could be a DNS issue. Make sure that the wireless router providing you the connection is setup to provide the proper DNS servers over DHCP, and that the domain can be resolved with them.

If not of that works, I don't know what is wrong, but it's nothing obvious. Every KB I've read so far point to this solution, and it seems to work well for others.

Yanick Girouard
  • 2,385
  • 1
  • 18
  • 19
  • This looks useful. Could you add some actual meat to the answer though, instead of just a link? – Iszi Mar 29 '12 at 19:24
  • The link is all the meat I have short of transcribing the article literally. What "meat" do you want exactly? It's pretty straight forward from what I can tell. – Yanick Girouard Mar 29 '12 at 19:29
  • No matter. Tried and failed. – Iszi Mar 29 '12 at 19:59
  • Apparently the site I linked to is in maintenance now, but the KB was precisely to do what you wanted. What part is not working for you exactly? – Yanick Girouard Mar 29 '12 at 23:29
  • I've edited my answer to transcribe all the details of the KB I had linked, and more... I would appreciate if you could upvote to remove the negative votes, as this was a valid answer. You didn't need to vote it down just because it didn't work the first time for you. – Yanick Girouard Mar 30 '12 at 00:26
  • 1
    This is indeed a valid answer, I have used this method before -- there are just better more efficient ways of doing this. – Shadow00Caster Mar 30 '12 at 16:56
  • I've still got some problems with this, in regards to Steps 7 & 8. I still need the systems to be able to allow login when the DC is unreachable. Will this policy prevent that (reading it on an XP system, it doesn't say)? Also, the description says that this is the default behavior for servers. So, that's not my issue. DNS is also not the problem, since the feature works when using the WLAN card vendor's software. – Iszi Mar 30 '12 at 18:47
  • I've re-read the description several times and it says it is NOT enabled by default. "By default, on client computers, Group Policy processing is not synchronous; client computers typically do not wait for the network to be fully initialized at startup and logon. Existing users are logged on using cached credentials, which results in shorter logon times. Group Policy is applied in the background after the network becomes available.". Did I miss something? Note: This has to be changed on the client computer, not the server. – Yanick Girouard Mar 30 '12 at 19:16
  • I believe it also means that it will not log you on with cached credentials automatically, but will check to see if there's a network connection first, and then apply the GPOs. It doesn't say it will wait forever for it and prevent you from loging in if the network is not available. I guess you'd have to test it to be 100% sure though. – Yanick Girouard Mar 30 '12 at 19:18
  • Okay, perhaps I should be more clear: I *am* doing this on a *server OS*. I have laptops running Server 2008 that need to do this. This is spelled out in my question also. (P.S.: Removed down-vote, since the question does now have some useful information other than just a hyperlink. Thanks.) – Iszi Mar 30 '12 at 19:38
  • Ohhhhh! This was not clear enough I guess. I just noticed that you wrote you're upgrading your laptops to Windows Server 2008. It's a little unusual to say the least. – Yanick Girouard Mar 30 '12 at 19:41
  • @YanickGirouard Your confusion is understandable. I'd love to run these on Windows 7, but the software that we need on them requires a Server OS and some other services that just aren't meant to be run on anything less. (P.S. Substitute "answer" for "question" in my previous P.S.) – Iszi Mar 30 '12 at 19:43
2

I've setup this exact scenario except I do not use any 3rd party wireless utilities such as the Dell one, I simply let Windows do it's thing.

I set this up on 7 but should be the same for Vista and actually XP. Since I hate doing things redundantly and repetitively, I simply use the GPO Computer Config > Policies > Windows Settings > Security Settings > Wireless Network (IEEE 802.11) Policies. You can create a Vista+ and XP policy in there that gets the job done.

Also good idea to enable "Always wait for the network at computer start-up and logon" (Computer Config > Policies > Administrative Templates > System/Logon).

When the SSID is in range, the machine will connect to it using the credentials supplied at logon (SSO), connect then auth. Also, if the credentials supplied to not allow the machine to connect, I have it set to the user can be prompted to enter credentials again for wireless (not necessary with SSO but in some cases it's useful).

Here are some screenshots from my setup: http://www.reborndigital.com/pubfiles/wifi_gp_ss/

Hope that helps!

Shadow00Caster
  • 384
  • 1
  • 4
  • 15
  • I haven't gotten to test any of this, but I'm curious as to how much of these settings are actually required for my desired functionality, and how much of it is specific to your own network's configuration and/or administrative preferences? I'm especially interested in clarification of screenshots 24 & 25. If you could give more specifics about this, and perhaps include inline screenshots of the *absolutely necessary* configurations, that would be wonderful. It would also help the answer survive if your screenshot links ever die. Thanks again for the information! – Iszi Mar 30 '12 at 19:56
0

Sounds like you need this:

How to enable computer-only authentication for an 802.1X-based network in Windows Vista, in Windows Server 2008, and in Windows XP Service Pack 3
http://support.microsoft.com/kb/929847

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
  • I'm not sure "computer-only authentication" is appropriate here. Though I'm not very familiar with what our RADIUS servers allow regarding this, I'm fairly certain we still need the user credentials to connect. Also, please provide actual *content* with your answer - not just a headline and link. – Iszi Mar 29 '12 at 18:55
  • @Iszi so you don't computer authentication but you do want user authentication? – Jim B Mar 29 '12 at 19:11
  • @JimB I'm not sure what the computer authentication situation is here in terms of the wireless network, so I'd like to presume we can only authenticate users. – Iszi Mar 29 '12 at 19:23
  • I think the article explains the differences pretty well - is there a part in the article you are confused about? – Jim B Mar 29 '12 at 19:32
  • The article explains the differences just fine. However, I believe that the "computer-only authentication" is something that has to be supported by the RADIUS server. For example, I cannot connect to the wireless network when I am logged in with a local account unless I provide my domain credentials. If computer-only authentication was allowed by the network, wouldn't this be possible? Or, is this possibly because it is disabled by default on the client side? – Iszi Mar 29 '12 at 20:05
  • I just checked the configuration per the directions in your linked article. The current authmode is "machineOrUser". Therefore, if I'm reading the descriptions correctly, it is not a matter of setting the system to computer-only authentication because it should already be attempting computer authentication when the user is not logged in. The problem (regardless of whether computer authentication will work or not) is getting the system to join the wireless network before trying log the user in locally, so that the computer can bounce the user's credentials off the domain controller. – Iszi Mar 29 '12 at 20:17
0

I didn't see it posted but we are running a wireless network using 802.1x user authentication against AD. We were having issues with the shared devices receiving "No login server available to service logon request" The issue was resolved by enabling single sign on under the 802.1x settings.

WJB
  • 1