Wireless prelogon/single signon Windows XP ms client

By ·
Ideally I would like to be able to centrally manage wireless clients with Group Policy. Using win2k3 server, winxp clients. Using PEAP authentication will allow GP to be used. Would like to use the Microsoft wireless client for our wireless connection. However, prelogon, or single-signon is not an option with XP and the MS wireless client. It is a new feature in Vista, but we cannot upgrade to Vista until all 400 apps have been tested. Without the prelogon, drives won't map and logon scripts won't run because the mobile devices aren't authenticating to the domain. Other than using another wireless client, is there a script or other method to use to get a prelogon? or addin for the ms wireless client?

This conversation is currently closed to new comments.

10 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Answers

Collapse -


I haven't yet tried this, but I'm in the same boat. I'm going to use the MS utility to install a new bogus service (SrvAny) with the wireless card's driver exe and see if that works. That way, the software is up and running prior to logon, the remote logons and GPO's would be applied during service loads.

Collapse -

One minor fix you can make with group policy, one off-the-wall idea

by robo_dev In reply to Idea

group policy that forces the computer to wait till the network is up, also helps..see this thread:

While I commend your 'bogus service' idea, I think that would be a big security flaw if that would work. This would allow unauthenticated users on your WLAN.

Here's another wacky thought:

The **big issue** with Wireless clients booting slowly is that the wlan adapter has no IP address.

So all network-dependent servics wait...up to two minutes. Then they all start trying to load at the same time (and pegging the processor) when the IP is assigned after login.

If you give the (non connected) WLAN adapter a static IP address, then more services can start and be happy.

Now the wacky part would be by scripting using netsh comands the interface to load with a static IP, then goto DHCP when it needs to.

Collapse -


Now, the PC wouldn't auto-logon, just the needed service. As it would be still locked, it would be as a wired connection to the network. As long as you have a PC plugged in, the computer is connected. But the workstation is still pre-logon so logon scripts would still run upon logon. That service could even be run as a local account or a dedicated logon account in the domain.

The network dependents are still running, but the client side software used to connect to the wireless network is not. Even waiting for the services applied by GP wouldn't work becouse all network services are running. Just the wireless network service isn't configured until client logon.

I don't know about the static IP helping any as that would be configured, but the wireless service wouldn't be connected (according to the drivers made by the card manufactuer). Hence the servcie running the client side software that connects to the WLAN so that upon client logon the scripts and GP objects would be applied, but there isn't any un-athenticated users on the net at that time.

Collapse -

The issue, I believe, is the design of the Windows wireless supplicant

by robo_dev In reply to Clarify

And it's not really a criticism of it, it's just that the establishment of the link is 100% reliant on authentication.

Therefore, if the service could 'act like a user' and get the encryption key/IP address from the server, then the service is on the network, as a regular user.

The problem I see is what happens when the actual user login happens? I belive the answer is that the prior conncection drops, and the WLAN authentication & DHCP request process starts all over again.

The whole policy suggestion is really a performance-enhancer, since many services cannot start unless they see that the interface is up. So by 'fooling' these services, you can manage the speed of the user login a bit.

Collapse -

It works, just need to find the right Technet Artical

Ok, I finaly found how to do this.

<a href = ""></a>

See the above link for this. By disabeling the software that came with my wireless cards and using the MS Wireless Zero Configuration with all MS built in software (available in SP2 and later) this all works fine. My domain policies work, my logon scripts run, all is happy and smooth.

I had to do a little digging to get all of the configurations, but basicly just needed to tell the system to not use the provided Linksys configuration utility (Though Linksys TS said that I couldn't get this to work at all) and then enable the wireless pre-athentication (In the Advanced tab in the network settings for a wireless card).

Hopefuly, someone will be able to use this info to by-pass all my headachs getting this up and running.

Happy computing!

Collapse -

radius server

by jxu68 In reply to It works, just need to fi ...

Hi John,
Thank you for your infomation.
We have a small network, a MS sbs2003 server ia used for domain authentication, application and file server. We do not have RADIUS server installed. Recetly I configured two laptop, with Intel(R)wireless 3945ABG installed. I configured "Single Sign On" but it didn't work.
If use MS Zero Wireless Configuration, do have to set a RADIUS server in our network?

Collapse -


by john_heidelberg@hotmail. In reply to radius server

No, I didn't set one myself. I was using some Linksys cards and had to do a bit of configuring with them. I turned off the Linksys drivers, then configured the MS Zero Wireless networking. However, I noticed that after about two hours the client would dis-connect from the network. So I re-enabled the Linksys driver and everything ran great after that.

Collapse -


That was an addin by MS for XP, and that is included with SP2 for XP. Under the advanced wireless card configuration, as long as the driver software supports it, you have the option to enable the single signon. Thus remote administration, logon scripts etc is available. I too am using 2k3 and xp, though for a diffrenct reason.</p>
According to the following MS documents, see related parigraphs:<br>
<a href = "">
Designing and Deploying Wireless LAN Connectivity</a>
<br />

<b style="margin-left: 10px">Wireless Clients Running Windows XP</b><br>
<p style="margin-left: 10px">
The operating system platform for wireless clients at Microsoft is Microsoft Windows XP, which includes built-in support for 802.11 and 802.1X. A wireless client user uses the Windows XP Zero Configuration service to connect to the Microsoft corporate wireless network. Default settings enable WEP encryption, the use of 802.1X authentication, and the EAP-TLS authentication method using a registry-based certificate. All wireless network adapters used at Microsoft support the Windows XP Zero Configuration service.
<p style="margin-left: 10px">
If a Microsoft user has a wireless network at home, the Windows XP Zero Configuration service allows the user to have both wireless networks in their list of preferred wireless networks: the Microsoft corporate wireless network and their home wireless network. While at work, their wireless laptop connects to the Microsoft corporate network. While at home, their wireless laptop connects to their home wireless network. Each wireless network can have it own configuration, including wireless network type (infrastructure vs. ad hoc) and authentication and encryption settings.
<b>see also from Technet the following articals:
<a href="">Wireless Network Policies Extension Technical Reference</a> <br><br>
<a href="">Wireless Client Update for Windows XP with Service Pack 2</a>
And this was the artical that finaly got me set up with my network:<br />
<a href = "">Wireless Deployment Technology and Component Overview</a>
<br>Note the following exerts from the above link:<p style="margin-left:10">
Authenticate as computer when computer information is available This check box specifies whether the computer will attempt to authenticate using computer credentials (such as a computer certificate), without the user logging on.

Authenticate as guest when user or computer information is unavailable This check box specifies whether the computer will attempt to authenticate as a guest when either user or computer credentials are not available.

<p style="margin-left: 10px">
<strong>IEEE 802.1X and Computer Configuration Group Policy</strong></p>
<p style="margin-left: 10px">
Updates to Computer Configuration Group Policy occur when the computer starts, achieves
network connectivity, and locates a domain controller. The computer attempts to
download the latest Computer Configuration Group Policy based on the computer's
membership in a domain system container.</p>
<p style="margin-left: 10px">
If a Windows wireless client configured to use EAP-TLS authentication does not have
a computer certificate installed, it cannot authenticate to a wireless AP to obtain
wireless LAN network connectivity. Therefore, the attempt to locate a domain controller
and download the latest Computer Configuration Group Policy fails. This event is
recorded in the event log.
<p style="margin-left: 10px">
The solution to this problem is to install a computer certificate on the Windows
wireless client so that wireless LAN network connectivity is present during the
location of the domain controller and the download of the Computer Configuration
Group Policy.</p>
<p style="margin-left: 10px">
<strong>IEEE 802.1X and User Configuration Group Policy</strong></p>
<p style="margin-left: 10px">
Updates to User Configuration Group Policy occur when a user supplies correct credentials
and logs on to the domain. If a computer certificate is not installed (and the computer
has not authenticated itself against the wireless AP), the logon uses cached credentials.
After the user certificate in the user's certificate store becomes available, the
Windows wireless client configured to use EAP-TLS authentication attempts to authenticate
against the wireless AP. Depending on how long the wireless authentication takes,
the download of the User Configuration Group Policy might also fail. This event
is recorded in the event log.
<p style="margin-left: 10px">
The solution to this problem is to install a computer certificate on the Windows
wireless client. With an installed computer certificate, the Windows wireless client
has wireless LAN network connectivity during the entire logon process, and therefore
should always be able to download the latest User Configuration Group Policy.</p>
<p style="margin-left: 10px">
<b>Note</b> Computer authentication with PEAP-MS-CHAP v2 is done using the account
name and password associated with the computer account for the computer, which is
automatically assigned when the computer account is created. The credentials for
computer authentication are always available and are used during the computer startup
process to obtain access to the wireless network. User authentication with PEAP-MS-CHAP
v2 is done using an account name and password associated with the user of the computer.
By default, the user's logon credentials (username and password) are automatically
used to perform user authentication after the client successfully logs on to the
computer. The automatic use of the user logon credentials can be configured from
the properties of the MS-CHAP v2 PEAP type.</p>

Collapse -

Try this for your pre-logon or single-logon..

Allowing Network Access with Blank Passwords
Although you can log in locally without a password, by default, WindowsXP Pro does not allow network users to access the computer without a password. Typically you will receive an Unknown error 31 if this is the case.
To change this setting:
1.Run gpedit.msc
2.Go to Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options
3.Double click on Accounts: Limit local account use of blank passwords to console login only
4.Disable this option

Please post back if you have any more problems or questions.

Back to Networks Forum
10 total posts (Page 1 of 1)  

Related Discussions

Related Forums