Mobile Domain Controller?

[anonim1]

I am part of a traveling course which sets up a wireless network on site and provides students with about a dozen laptops to access a web-based application on a laptop-server in the local network.

In order to facilitate performing upgrades and other maintenance on the laptops, I would like to upgrade the laptop-server to a domain controller, then join the other laptops to the domain.

Now.. some of the faculty and staff at the site like to have internet access to check e-mail, etc, through the same wireless network. As a result, I get one wired internet connection at the site and connect it to the wireless access point, thereby allowing my wireless network to access the internet.

This has not been a problem so far because the laptop-server is just a web server, and the laptops are configured under a workgroup (not domain) setting.

I would like to know the consequences of plugging in a domain controller to a wireless access point, which is connected to the internal network of the facility we're in.

My guess is that it will wreak havoc on the existing network and its DCs, but maybe I'm wrong? Thanks.

 

[WhoKilledKenny]

Are you trying to push software via GPO? If not I don't see the benfit of going through all the work of adding and removing laptops from your domain.

If you have a directory with all your maintenace and upgrade files in it, Just share it with the local guest account.

As far as your AD questions:
Should not be a problem as there's no trust between the location domain and the domian on your laptop. Just a lot of pre-work (putting the workstations on your domain) and post work (removing the workstations from your domain). The workstations would have to point to your DNS to authenticate and you would either have to set up a DNS forwarder (pointing to the facilities DNS) or enter there DNS address (on the clients) for internet resolution.

Since the laptops are in workgroups, no issue with breaking local domain memebership. As, long as the local IT staff does not have any issues with your procedure.

 

[anonim1]

Thanks for your reply WhoKilledKenny.

That's precisely correct, I plan to use GPO and WSUS from the laptop-server to push down software, updates, and configuration down to the client laptops.

All of the machines belong to us; therefore, I will only need to join the laptops to my domain one time and will not need to disjoin them ever. Good point about DNS - another option I have is to permanently enter the IP addresses from OpenDNS into the laptop-server's DNS as forwarders.

My main concern is over creating problems at the host site (let's call it network A). I want to be certain that bringing my network of one domain controller and 10-15 domain client laptops (call it network B) and physically connecting it to network A will allow both networks to remain fully operational without any problems, hiccups, etc.

Out of curiosity.. what sort of logs would be generated on any of network A's machines indicating that another domain network (my network) is attached to their physical network layout? Would they even know?

 

[WhoKilledKenny]

My main concern is over creating problems at the host site (let's call it network A). I want to be certain that bringing my network of one domain controller and 10-15 domain client laptops (call it network B) and physically connecting it to network A will allow both networks to remain fully operational without any problems, hiccups, etc.

the domains are seperate boundaries, there would be no conflict. Even if they were on the same physical wire (subnet).

Out of curiosity.. what sort of logs would be generated on any of network A's machines indicating that another domain network (my network) is attached to their physical network layout? Would they even know?

Good question, I checked the logs on my DC (as I have a test domain on the same network). I am not seeing anything to indicate another domain.

I could see if you had a DHCP server giving out addresses, that could cause a problem with machines in the same VLAN or possible others if DHCP broadcasts are allowed to traverse the router.

 

[anonim1]

Hmm that's a great point you bring up about DHCP.

Although I will not be running a DHCP server on the domain controller, the wireless access point must be able to issue local IP addresses (192.168.0.x) to the machines in the room, regardless of if they're on my domain or not (some users bring their own laptops).

Besides configuring all the laptops to use static addresses (which really is not an option), is there anything I can do to prevent any conflicts?

Thanks..

 

[WhoKilledKenny]

Ok wireless, that brings up some more challenges.

Not sure how the access point (DHCP) would react if you statically assinged an address that is part of its IP Pool. I know an MS DHCP Server would not assign the address if it is in use, so it would prevent an IP conflict. It would flag it as a bad address in the DHCP database.

Besides configuring all the laptops to use static addresses (which really is not an option)

If you are not managing the DHCP server, you are going to have to assign a static IP for your domain controller and DNS addresses on each of the clients. Clients need to point to your lab domain (as I'll call it) to authenticate.

If you are managing the DHCP access point and you assign scope options for your Lab Domain, this could cause issues with wireless clients that are on the production domain. Say they boot up in range of your wireless access point and the DHCP server assigns them the wrong IP and scope option for the wrong domain...

If managing the access point along with the lab environment, my suggestion would be to set up access lists that allow only certain machines (via MAC address). This should keep you from disrupting service to other wirless devices that may be in the area.

You will still have to do manual setups for those who bring in their own laptops....

 

[anonim1]

Thanks for your suggestions.. Here are my comments.

Not sure how the access point (DHCP) would react if you statically assinged an address that is part of its IP Pool. I know an MS DHCP Server would not assign the address if it is in use, so it would prevent an IP conflict. It would flag it as a bad address in the DHCP database.

I can restrict the IP pool by range, i.e. AP: 192.168.0.1, Server Laptop: 192.168.0.2, DHCP Range: 192.168.0.3 - 192.168.0.20 (or however many IPs I need).

If you are not managing the DHCP server, you are going to have to assign a static IP for your domain controller and DNS addresses on each of the clients. Clients need to point to your lab domain (as I'll call it) to authenticate.

I do not have any management over the built-in LAN or its DHCP server. My idea is to run the access point in NAT mode rather than bridge mode, and assign private IPs (192.168.x.x) to all of my wireless client machines. I will, like you suggest, assign a static IP to the server laptop, which will serve as the DC and DNS server.

If you are managing the DHCP access point and you assign scope options for your Lab Domain, this could cause issues with wireless clients that are on the production domain. Say they boot up in range of your wireless access point and the DHCP server assigns them the wrong IP and scope option for the wrong domain...

I see your concern, but wireless clients not part of our training class will connect to the production wireless AP via its own SSID. I can even restrict access to my AP using WPA, etc. This way, those clients will never be establish a connection to my AP and will avoid any interaction with the AP's DHCP server.

If managing the access point along with the lab environment, my suggestion would be to set up access lists that allow only certain machines (via MAC address). This should keep you from disrupting service to other wirless devices that may be in the area.

Unfortunately not an option.

You will still have to do manual setups for those who bring in their own laptops....

These machines will pull private IPs from the AP's DHCP service. I don't need them to authenticate with my DC, so there's no need for them to use the DC as a DNS server either.

I found the following information online:

Running a NAT instead of as a bridge is more likely to interfere with the operation of the campus network in the following ways: by acting as a DHCP server on the campus network, by announcing IP routing to the campus network, by leaking private-network traffic to the campus network, by incorrectly forwarding traffic received via its campus interface, by responding inappropriately to IP broadcast or multicast traffic, or by responding inappropriately to ICMP error messages.

These are the kinds of things I was worried about.. Any input about that?

Thanks very much for all your help.

 

[kmcferrin]

If instead of using a wireless AP you used a wireless gateway router, then you could have it passing out DHCP addresses on the wireless side (you would see that as an internal interface), but it would take a DHCP address from the external interface (your customer's network) and not pass out IPs to machines on that side.

 

[anonim1]

kmcferrin, that's precisely what I was referring to when I said I would run the wireless device in NAT mode rather than bridge mode. NAT mode will issue out DHCP addresses to only the clients that are connected internally. The wireless device itself will have an IP address issued to it from the external interface. Outgoing connections from the internal clients will appear to have come from the IP address of the wireless device because of network address translation.