Re: Is wireless viable on and SBS network?
From: Jeff Middleton [SBS-MVP] (jeff_at_cfisolutions.com)
Date: 02/11/04
- Next message: Jeff Middleton [SBS-MVP]: "Re: << Security bulletin 04-007 - Critical >>>"
- Previous message: Jeff Middleton [SBS-MVP]: "Re: Where to put the server"
- In reply to: Theo: "Re: Is wireless viable on and SBS network?"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 10 Feb 2004 18:51:04 -0600
I have trouble believing the point you are suggesting that the wireless
adapters not engaging early enough to provide normal support. Let me say
that I have several offices that include substantial installations of WAP
connected PCs using D-Link hardware and they don't have a problem with this.
In fact, these machines are using USB connected NICs, which if anything
would be where I could anticipate there being a delay if the USB hub didn't
activate to make the NIC even show up.
However, my expectation is that you see the network services on any PC fire
up way before you see most of the rest of the GUI and environment fire. This
is easily seen in SBS when you have a NIC malfunction and it takes forever
to startup. The network services are core to everything in the OS.
Obviously the system can startup with the loopback address and no NICs, but
the point of the machine being in a domain is that you are supposed to get
authenticated, it's supposed to come over the wire, and so it makes no sense
that you wouldn't see it work correctly with a wireless adapters.
What I have seen, with wired or wireless, is that with XP there's an option
for "quick logon" that will allow policy loading to be bypassed for up to 3
logons. I disable this feature using Group Policy, force a refresh at the
workstation, and the issue is resolved from then.
I've seen machines that don't have proper time sync ignore policy and logon
situations, but I think you mentioned earlier that you have covered the SMB
signing stuff.
Roaming profiles work fine over a VPN, all assuming you are not either too
low on bandwidth to wait on the Roaming Profile, or that you have ensured
that you don't have Group Policy settings that determine that you lack the
threshold bandwidth and it skips loading as a result.
Roaming Profiles and Redirected Profiles are actually three different
things. You can Roam, you can redirect, and you and Roam and
Redirect...effectively caching the profile at both ends. All can work over
the VPN provided that you perform "logon with Dialup Connction".
However, if you are setting up in this logon with VPN situation, this does
point out a scenario in which your original problem with computer policies
will be quite irritating. This is because if you are doing User logon with
VPN, unless the VPN is intended to improve security over a connection that
is already available for link to the DC anyway, you have a problem.
Let's assume that you have a laptop, rather than being on wireless, make
this more familiar as a traveling PC using the web to reach the office. As
such, you first boot the machine to get to a logon prompt in a situation
that due to firewalls on each end, you can't actually reach your DC to
authenticate without a VPN. In this situation, you can't have received the
Computer (machine) policies when it started....because that sync occurs
before the logon screen arrives...or at least it attempts to happen. If you
now perform a logon via VPN, you will see the logon session first initiate
the VPN Dialup connection, connect, then initiate the user authentication.
At this point, the user session can obtain the policies, but you missed the
computer policies....right?
Moving forward in time, if the laptop stays connected long enough for a
policy refresh period to occur, then the machine policies will wander over
to the computer to update it. You can also use a forced refresh with script
of manual commands. Those policies will take affect in one of the next
several reboot cycles.
AFAIK, the only obvious way to get machine policies passed to a computer
during boot up is to make the machine either use a Dial on Demand routing
connection (which I'm not sure you can configure with workstation OS) or you
have to provide connectivity without firewall to the DC during the network
binding period of the startup.
Returning to your scenario, if the WAP is not secured outside in a DMZ,
rather if it's on you LAN, I see no reason you shouldn't get normal
behavior. If you are outside the LAN so that only after VPN connection can
you see the DC, then I think you will have issues with the Computer
Policies, but not necessarily the User policies. Most computer policies are
applied at startup of the computer not at logon of the user.
Regarding your last question, while I would debate the need to go to more
expensive hardware to solve this problem, I can say that the functionality
of higher-end devices like Orinco and Cisco is intended to make the systems
more robust in integrated LANs with other equipment from that maker, or
compatible infrastructure. For instance, you would find that you can get
more robust roaming from WAP to WAP with such products.
"Theo" <theo@makingitwork.co.uk> wrote in message
news:eVuVwKy7DHA.2812@TK2MSFTNGP11.phx.gbl...
> Hi Jeff
> The set up looks standard - which is to say that it uses the wireless
> suppliers utility (D-Link Extreme) to manage the wireless connections
rather
> than Windows. The windows firewall option is unticked and there are no
> others that I am aware of.
> It has been suggested to me that the cheaper wireless devices are not
> designed for domains in that the their drivers start up too late to enable
> the PC to join the domain properly. Part of the advice was to put the
> wireless PCs into a workgroup, not into the domain, and then to run a
login
> script at logon to the local PC but for that to work the computer names,
> local user names and passwords have to match the domain names and
passwords.
> Your VPN approach looks much cleaner.
> One or two questions still to sort out are:
> Is there anyway I can deal with roaming profiles and use the VPN approach?
> Is it true that the upper range (in price) wireless hardware does not have
> this issue?
> Thanks
> Theo
> "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
> news:OEOYKaN7DHA.2480@TK2MSFTNGP10.phx.gbl...
> > You should be able to use the wireless as transparently as a physical
> cable,
> > there are no special conditions to be addresses. If you have problem
with
> > the wireless that isn't present in the wired configuration, look first
to
> > see if you have firewall feature enabled on the wireless NICs or WAPs
> > themselves.
> >
> > A common problem when using wireless on laptops is that, as a System
> > Administrator, you really would like to have your roadwarriors work with
> > WiFi in the office with the security disabled, and with WiFi on the road
> > enabled. SBS 2003 accomplishes this trick at logon with a policy
> adjustment.
> > As I'm typing this, it occurs to me that it's possible that this policy
> > itself could produce conditions that resemble yours, but not because of
> the
> > reasons one might think. XP and some 3rd party products allow for
> detecting
> > and tuning the firewall features based upon the WAP you are connecting
to.
> > Another option is to use a VPN at logon even if you are in the office.
In
> > fact, using IPSEC tunneling to make a VPN is probably the most secure
way
> > you can handle connectivity to your WAP inside your office by placing
the
> > WAP outside your trusted LAN with a firewall between the WAP and the
LAN.
> In
> > this way, anyone wardriving outside your building can't hijack onto your
> WAP
> > and gain access to see your LAN traffic flying in the air. The IPSEC
> tunnel
> > encrypts your own traffic, passes beyond the WAP and through the VPN
> gateway
> > before becoming decrypted on the LAN.
> >
> > So, I've tossed some ideas out about options to make your situation more
> > complicated, but I think you need to first make it work! :)
> >
> > Take a look to see if your laptops have the correct time
synchronization,
> > and ensure that they are able to pass policies at logon with a wired
> network
> > to ensure that the machine itself is properly configured, then go back
to
> > the wireless setup and double check for firewall filtering somewhere.
> >
> >
> >
> >
> >
> >
> > "Theo" <theo@makingitwork.co.uk> wrote in message
> > news:eRUh%23VB7DHA.2524@TK2MSFTNGP11.phx.gbl...
> > > Hi
> > > We have just installed a D-Link WAP to provide a connection for two XP
> Pro
> > > portables to a LAN to avoid adding additional cabling. Unfortunately
we
> > are
> > > encountering problems at log in with the portables not finding the
> domain.
> > > We get an event in the application log (Userenv ID 1054 and
> AutoEnrollment
> > > ID 15) even though the potables have been given static IPs and the
> server
> > IP
> > > is entered in the DNS server setting.
> > > I wondered if the wireless device is active early enough in the
startup
> to
> > > deal with the negotiation that goes on between the server and the PC?
> > > We have spoken to D-Link and done everything that they suggest without
> > > success.
> > > A few other bits of information:
> > > We have encryption on (there is another WAP in the vicinity so we have
> > > changed the SSID and the connection channel) and only the two
portables
> > are
> > > allowed to connect to our WAP (by using MAC filtering). We are using
> the
> > > D-Link utility to manage the Wireless connection not the inbuilt
Windows
> > XP
> > > utility.
> > > Any ideas?
> > > Thanks
> > > Theo
> > >
> > >
> >
> >
>
>
- Next message: Jeff Middleton [SBS-MVP]: "Re: << Security bulletin 04-007 - Critical >>>"
- Previous message: Jeff Middleton [SBS-MVP]: "Re: Where to put the server"
- In reply to: Theo: "Re: Is wireless viable on and SBS network?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
