• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 487
  • Last Modified:

login to NT domain server behind a firewall

We want to restrict access to a server with medical data, and are thinking doing it with a second firewall in our network between the LAN and this server.

something like the fig. under:

internet <-- 3com secure router --> lan with win98 PC's  <--- firewall 2 --> medical server/also domain ctrl.

The problem is probably that this server also is the domain controller.

We have tried to use booth another 3com secure router and a Dlink 504, and we manage to conect shares and other resources, but not to login to the domain. The domain server is on an other subnet (192.168.2.x instead of 192.168.1.x), so that's the reason i guess? I tried to define 1.x adresses on both the wan and lan side of the firewall, but that did'nt work at all.

Is there a way to route domain queries from the 1.x subnet to the server on the 2.x subnet through the firewall?

If we drop the domain login we will loose the security at login into the server.. and the goverment here in Norway demands that medical data, and access to medical data,  is secured with booth access conttroll and  behind some kind og two-phase protection in the network (several firewalls/proxies etc)

Any tips?

Sincerely Are Kristensen, Skarnes, Norway
1 Solution
Pete LongConsultantCommented:
Logging into the domain through a Firewall

Note this is to log in - NOT for Exchange, SQL or a Domain Controller, I’ve not tried those so I can't comment.

The following ports have to be open from the outside (or DMZ) to the domain controllers.
NB: I know having these open from outside/DMZ has security implications but sometimes it needs to be done.

Ports open from DMZ\Outside

UDP      domain            53
TCP      domain            53
UDP      Kerberos            88
TCP      Kerberos            88
UDP      Time                  123
TCP      Kerberos Auth      135
UDP      netbios-ns            137
TCP      netbios-ssn            139
TCP      ldap                  389
UDP      ldap                  389
TCP      microsoft-ds            445
TCP      ldap to GC            3268

However the process still fails (or runs like a two legged dog and appears to work) this is because
of the RPC system that runs on the domain controllers, when you log in the client fires up a
communication over port 135 the Domain controller, which then fires back a port number it wants to communicate
with the client over (this can be any number over 1024) your firewall lets this through outbound.

When it hits your client, it tries to open comms on that port, which is inevitably blocked on the firewall

When this happens you will see errors like

Error 1053
There are no more endpoints available from the endpoint mapper.

if you run netdiag on the machine you will see errors like
[WARNING] Cannot call DsBind to servername.domain_name.com (<ip address>). [EPT_S_NOT_REGISTERED]

There are two ways to solve the problem

1. Open every port above 1024 on your firewall, however this is about as sensible as eating yellow snow.

2. Change the way your domain controller handles RPC requests,

NOTE this must be done on EVERY domain controller

Click Start > Run > regedit {enter}

Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Create a new DWORD value called "TCP/IP Port"  (remove the quotes and include the space)
double click it and change the "base" to decimal type in a port number (between 1024 and 64000) for the sake of argument use 1024

Exit the Registry Editor and you MUST reboot the server.

Now go back to the Firewall and open the following port

TCP      static RPC      1024

Now the process will work.
Personally, I'd move the medical data off the DC onto another box and put that box behind an additional firewall with a strict policy. Having sensitive data on a DC is not recommended due to the additonal vulnerabilities a DC suffers.
Pete LongConsultantCommented:
Depends what the data is?

if its patient identifyable data then yes - if its not then its a judgement call - Im a network Engfineer who works in the National Health Service so Im used to that problem =/
Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

Rich RumbleSecurity SamuraiCommented:
Rick111 has the right idea. Since everyone will need access to the DC for logon and authentication in general, it's better the DC was on the user side, and the medical data was behind a DMZ as you've described. You don't necessarialy have to give up on the .1 subnet idea either, I think you were trying to use a /24 (slash 24) subnet mask, if you used a /25 you'd be ok
instead of (aka /24) use
If I have an ip address of subnetmask then that subnet is from
and if the other ip address is subnetmask then that subnet is from

List of networks
for the network with the subnet mask
Network      Hosts                                       Broadcast Address
                            from          to

you MAY still have to set up the right routes on the firewall, just as if you were using the 2 /24's (.2 and .1)

ithandelAuthor Commented:
good answers an ideas from everyone.. Petes answer solves the initial problem comunicating with the DC. But thanx to both Ricks :-)

The DC and data server should maybee been seperated since it's patient identifyable data. A economical questions for a non profit organizaton, but if you guys thinks its a security risk having patient identifyable data on a DC?

Maybee it should been som more point here for this issue... if possible?

ithandelAuthor Commented:

sorry to say the solution did'nt work at all.. I was to fast to accept the answer :-|

In registry at our NT4.0 server its no setting like:
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS

Any tips?

(We're running servicepack 6)

Sincerely Are Kristensen


Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now