How can I get my server to authenticate with my domain controller (which is located behind a linksys router)?
September 19, 2007 2:53 PM Subscribe
I have a Windows 2000 server that is sitting in a public IP network. I can not figure out how I can get it to talk to my domain controller that is sitting in a private IP network with a linksys WRT54G sitting in between.
Will port mapping solve this? I have already tried putting the domain controller in the WRT54G's DMZ. That did not seem to work.
Err, sorry. I meant to say "you would want to forward ports 80 and 443 to your internal server, and this would only direct external requests on those ports to your server, not block Internet Web access to all other machines on your LAN." The reason for this is that port forwarding works in conjunction with, and is aware of NAT translations your router does. Requests from inside your LAN are mapped into the NAT substitution table normally, and will be redirected to the clients that created them, without respect to the port forwarding rules that direct external connections to your server.
posted by paulsc at 4:05 PM on September 19, 2007
posted by paulsc at 4:05 PM on September 19, 2007
Response by poster: I found this document: Active Directory in Networks Segmented by Firewalls. Google this document name and you will find it: ADSegment_IPSec_W2K.doc
On page 6 it says: Note
Active Directory functionality is not supported over a router that has Network Address Translation (NAT) enabled. The configuration recommendations in this paper apply only to non-NAT environments.
Has anyone actually configured their linksys router to forward ports successfully? My understanding is that port forwarding is NAT? Is this not correct?
posted by zzztimbo at 4:31 PM on September 19, 2007
On page 6 it says: Note
Active Directory functionality is not supported over a router that has Network Address Translation (NAT) enabled. The configuration recommendations in this paper apply only to non-NAT environments.
Has anyone actually configured their linksys router to forward ports successfully? My understanding is that port forwarding is NAT? Is this not correct?
posted by zzztimbo at 4:31 PM on September 19, 2007
"... My understanding is that port forwarding is NAT? Is this not correct?"
posted by zzztimbo at 7:31 PM on September 19
I've used port forwarding on LinkSys WRT54G and WRT54GL routers successfully, with various Linux/BSD servers. Never needed a Windows domain controller for my projects, but any failings of port forwarding for Windows would have less to do with port forwarding, and more to do with the hack of NetBIOS over Internet Protocol that Windows wants to use for various functions like Computer Browser.
Port forwarding is an addition to regular NAT functionality, that uses intelligence in the router to inspect arriving packets from outside the network, to determine how rules set up on the router should be applied in directing those packets. It is aware of NAT table entries, and requests from machines inside the network, will not be impeded by port forwarding. But, if there are services that require alternate TCP/IP connection initiations by first the outside machine, and then the inside machine, these may not be "symmetric" when port forwarding is being done, since NAT may be remapping internally initiated requests to different port numbers. Windows may not have the "smarts" to recognize this, when NetBIOS (which was never intended as a routable protocol) over IP is concerned.
There can be but a single port forwarded machine in any LinkSys LAN (this has more to do with the LinkSys implementation of port forwarding than with the concept in a general sense). Only explicitly listed ports will be forwarded (so you can't just direct all incoming connections to that single machine. This is done to conserve address space in the NAT table).
posted by paulsc at 5:04 PM on September 19, 2007
posted by zzztimbo at 7:31 PM on September 19
I've used port forwarding on LinkSys WRT54G and WRT54GL routers successfully, with various Linux/BSD servers. Never needed a Windows domain controller for my projects, but any failings of port forwarding for Windows would have less to do with port forwarding, and more to do with the hack of NetBIOS over Internet Protocol that Windows wants to use for various functions like Computer Browser.
Port forwarding is an addition to regular NAT functionality, that uses intelligence in the router to inspect arriving packets from outside the network, to determine how rules set up on the router should be applied in directing those packets. It is aware of NAT table entries, and requests from machines inside the network, will not be impeded by port forwarding. But, if there are services that require alternate TCP/IP connection initiations by first the outside machine, and then the inside machine, these may not be "symmetric" when port forwarding is being done, since NAT may be remapping internally initiated requests to different port numbers. Windows may not have the "smarts" to recognize this, when NetBIOS (which was never intended as a routable protocol) over IP is concerned.
There can be but a single port forwarded machine in any LinkSys LAN (this has more to do with the LinkSys implementation of port forwarding than with the concept in a general sense). Only explicitly listed ports will be forwarded (so you can't just direct all incoming connections to that single machine. This is done to conserve address space in the NAT table).
posted by paulsc at 5:04 PM on September 19, 2007
Putting the DC in the Linksys' DMZ is probably the best thing you can do. Port forwarding may also work.
It really depends what you are trying to do here. Are you trying to actually join this machine to the domain? You only mention that you are trying to get it to "talk". What kind of talking do you mean?
Things to consider:
When attempting to connect to the DC are you using the DC's private address or the outside (Public IP) that is assigned to the Linksys router in question?
Is the DC configured to accept connections from hosts outside of its LAN?
For security reasons, you may not want to do this in the first place, especially if you are attempting to join the host to the domain. I recommend that you establish a VPN connection to the DC's private LAN.
posted by doomtop at 6:11 PM on September 19, 2007
It really depends what you are trying to do here. Are you trying to actually join this machine to the domain? You only mention that you are trying to get it to "talk". What kind of talking do you mean?
Things to consider:
When attempting to connect to the DC are you using the DC's private address or the outside (Public IP) that is assigned to the Linksys router in question?
Is the DC configured to accept connections from hosts outside of its LAN?
For security reasons, you may not want to do this in the first place, especially if you are attempting to join the host to the domain. I recommend that you establish a VPN connection to the DC's private LAN.
posted by doomtop at 6:11 PM on September 19, 2007
seconding doomtop's vpn recommendation.
Placing the domain controller in your router's DMZ is a Very Bad Thing (tm). Doing so just makes the server a very prominent target to anyone or anything (viruses, malware, etc...) scanning your IP block looking for potential machines to compromise. I can say from experience that a company I once got conscripted to do support for had their domain controller compromised twice within as many months - they didn't listen when I told them the first time that their setup was (unnecessarily) vulnerable.
Not to mention that with most consumer-grade, home-office type routers, if you have an IP address in the DMZ, you cannot then do port forwarding as well - it's one or the other. Thus, in the future if you would need to forward a port to another machine on the internal network, and you already have the domain controller as the DMZ address, this will not work.
VPN eliminates these concerns, as the purpose of vpn is to allow a machine with a public address to participate securely within a private address space.
posted by namewithoutwords at 8:00 PM on September 19, 2007
Placing the domain controller in your router's DMZ is a Very Bad Thing (tm). Doing so just makes the server a very prominent target to anyone or anything (viruses, malware, etc...) scanning your IP block looking for potential machines to compromise. I can say from experience that a company I once got conscripted to do support for had their domain controller compromised twice within as many months - they didn't listen when I told them the first time that their setup was (unnecessarily) vulnerable.
Not to mention that with most consumer-grade, home-office type routers, if you have an IP address in the DMZ, you cannot then do port forwarding as well - it's one or the other. Thus, in the future if you would need to forward a port to another machine on the internal network, and you already have the domain controller as the DMZ address, this will not work.
VPN eliminates these concerns, as the purpose of vpn is to allow a machine with a public address to participate securely within a private address space.
posted by namewithoutwords at 8:00 PM on September 19, 2007
If the DC is physically located where you can do this, install a 2nd NIC in it, set the public IP on that address, and put the other NIC in the private LAN. Then turn on the windows firewall to block outbound netbios and RPC on the public-facing NIC.
If you can't physically do this, then you really do need a VPN. And it will be very, very slow.
I understand what you are trying to do, I can't see any reason your DC is in a public IP space. Could you explain why this is so?
posted by disclaimer at 4:51 AM on September 20, 2007
If you can't physically do this, then you really do need a VPN. And it will be very, very slow.
I understand what you are trying to do, I can't see any reason your DC is in a public IP space. Could you explain why this is so?
posted by disclaimer at 4:51 AM on September 20, 2007
Response by poster: We currently have the domain controller set up with two NICs. One NIC in the public IP space and the other in the private IP space. I would like to remove the public IP NIC and have the domain controller sit only in the private network.
The trouble is that we have web servers that have public IP addresses. I would still like to log in to these machines with my windows domain credentials.
Additionally there is a firewall that sits between the web servers and the internet. Here is a crude diagram:
internet
---------
firewall
--------
web servers
--------
linksys router
--------
domain controller
My objective is to be able to manage my web servers via windows remote desktop by logging in to my domain controller.
What must i do to the linksys router in order for this to happen? I was going to just do port forwarding on the ports mentioned in that document referenced above, before i read that statement about NAT.
posted by zzztimbo at 12:51 PM on September 20, 2007
The trouble is that we have web servers that have public IP addresses. I would still like to log in to these machines with my windows domain credentials.
Additionally there is a firewall that sits between the web servers and the internet. Here is a crude diagram:
internet
---------
firewall
--------
web servers
--------
linksys router
--------
domain controller
My objective is to be able to manage my web servers via windows remote desktop by logging in to my domain controller.
What must i do to the linksys router in order for this to happen? I was going to just do port forwarding on the ports mentioned in that document referenced above, before i read that statement about NAT.
posted by zzztimbo at 12:51 PM on September 20, 2007
I get it now.
Your best and easiest solution is a VPN but that might play hell with the rest of your world. So, getting AD data through the Linksys is the least intrusive way. One of the big issues you face is that RPC uses random ports - starting at 1024 and going to 65536 - to communicate AD data to the servers. That means the Linksys can't work because it can't forward that many ports. You can assign RPC to a static port, though, and since your web servers are behind a firewall, you're probably safe in doing this.
First, read this. It's all about ports used by Windows services.
Now see this, which is the article that deals with statically mapping RPC.
Finally, see this article about all the OTHER ports that will need to be mapped for the other AD traffic the servers will need in order to participate in the AD.
posted by disclaimer at 3:39 PM on September 20, 2007
Your best and easiest solution is a VPN but that might play hell with the rest of your world. So, getting AD data through the Linksys is the least intrusive way. One of the big issues you face is that RPC uses random ports - starting at 1024 and going to 65536 - to communicate AD data to the servers. That means the Linksys can't work because it can't forward that many ports. You can assign RPC to a static port, though, and since your web servers are behind a firewall, you're probably safe in doing this.
First, read this. It's all about ports used by Windows services.
Now see this, which is the article that deals with statically mapping RPC.
Finally, see this article about all the OTHER ports that will need to be mapped for the other AD traffic the servers will need in order to participate in the AD.
posted by disclaimer at 3:39 PM on September 20, 2007
...and the last sentence got chopped by my ignorance: Obviously, after all that reading, you should be able to set up port forwarding on the Linksys, provided you have a sufficient number of 'slots" in the Linksys interface to support the number of ports you need to forward.
posted by disclaimer at 3:41 PM on September 20, 2007
posted by disclaimer at 3:41 PM on September 20, 2007
« Older Point me in the right direction... | How much should my wife bid on a transcription job... Newer »
This thread is closed to new comments.
Depending on what you're trying to do, you'll need to forward some, but not all, ports on this list.
posted by paulsc at 3:57 PM on September 19, 2007