Answers to the questions: 1. What TCP port number is used for the RPC endpoint mapper? The RPC endpoint mapper uses TCP port 135. The RPC client application then receives the RPC service's high number port and uses the high number port for subsequent communications.
2. When using an ISA firewall, do you need to enforce a specific high port number for the Active Directory RPC services to listen on? No. The ISA firewall's RPC application filter is able to listen to the RPC communications and automatically open the required high port number through the firewall.
3. Does the ISA firewall "open ports" or does the ISA firewall understand the actual protocols required? The ISA firewall, as an application layer inspection firewall, understands the actual protocols and doesn't "open and close ports" like simple stateful filtering firewalls. Only a stateful application layer inspection firewall can be trusted to provide the level of protection you require for your critical corporate assets.
4. Why did we not need to create the Protocol Definitions for Direct Host and RPC Endpoint Mapper protocols? The ISA firewall comes with these protocol definitions right out of the box. When you create a Protocol Definition with the same parameters as a built-in Protocol Definition, then the built-in definition will be used preferentially.
5. Would the rule we created for intradomain communications work for Windows NT DC based intradomain communications? No. NT domains are NetBIOS dependent and the rule we created does not support NetBIOS communications.
Posts: 16
Joined: 16.Jun.2004
From: France
Status: offline
Hey Thomas
I would add one thing about your nice articles and the test i've done. You can allow (depending the needs) netbios in one way. This, in order to grants one network to see the other comps. So you got 1 network that can see only the comps on its network while the other network (let's say the admin network) can see the whole networks and admin em.
quote:Originally posted by amamak: Dear, What about if I have DMZ configured in other Hardware Firewall lets say PIX firewall and ISA configured as a back-end?? Thanks
Hi Amamak,
Why would the PIX packet filter need to pass intradomain communications through the ISA firewall?
I would add one thing about your nice articles and the test i've done. You can allow (depending the needs) netbios in one way. This, in order to grants one network to see the other comps. So you got 1 network that can see only the comps on its network while the other network (let's say the admin network) can see the whole networks and admin em.
That's it
Hi Gerpion,
That's true. But in this example I'm allowing intradomain communications through a DMZ segment to the Internal network. You certianly do not want to allow NetBIOS through from an Internnet facing DMZ segment to the Internal network.
I can see how this would be useful if you were controlling traffic between two internal network segments.
A configuration question. Currently we have an application that runs in the DMZ (or perimeter) Also in the DMZ their is a Smart Card application, an Active Directory, IIS server with the application and an SQL-server. The firewall is the ISA server. For the moment users access the application through the firewall and they hit the smart card app first. the Smart card app authenticates them against the Active Directory and the application uses the windowsprincipal to get the authenticated-userid.
My question now is. I would like to move everything to the corporate domain and just leave the smart card app and the IIS web server in the DMZ. The problem is that the IIS server has to be in the Active Directory domain to get the authentication of the smart client right.
Posts: 16
Joined: 16.Jun.2004
From: France
Status: offline
quote:Originally posted by tshinder:
quote:Originally posted by gerpion: Hey Thomas
I would add one thing about your nice articles and the test i've done. You can allow (depending the needs) netbios in one way. This, in order to grants one network to see the other comps. So you got 1 network that can see only the comps on its network while the other network (let's say the admin network) can see the whole networks and admin em.
That's it
Hi Gerpion,
That's true. But in this example I'm allowing intradomain communications through a DMZ segment to the Internal network. You certianly do not want to allow NetBIOS through from an Internnet facing DMZ segment to the Internal network.
I can see how this would be useful if you were controlling traffic between two internal network segments.
Thanks! Tom
Indeed Thomas, i'm talking about it in internal networks scenario. I did it myself and it work nice. Nice article anyway
Posts: 7
Joined: 21.Aug.2003
From: South Carolina
Status: offline
Tom,
I am having some difficulties with something and figured I would finally give up and post to see if you had any insight.
Network Configuration:
IPSEC Site-Site VPN
Site 1: Subnet A: 172.16.1.X Subnet B: 172.16.2.X
Site 2: Subnet C: 10.1.1.X Subnet D: 10.1.2.X
All communication works great from Subnet A to Subnet C
The problem is coming into play when we introduced Subnet's B and D to the scheme.
We can ping, RDP no problems.
We are having a problem when trying to add a computer to the domain from Subnet D to Subnet B. The DC is in Subnet B.
We are seeing a connection failure on a system policy (Allow RPC from ISA server to Trusted Servers) I have verified I have the B subnet in the trusted servers in the system policy.
Now if i Move the DC from subnet B to Subnet A it works just fine.
Do you have a network diagram showing the relationships of the network and the routers connecting them on the local and remote networks?
Also, if you're using a ISA firewall on both sides, do NOT use IPSec tunnel mode for site to site VPNs. IPSec tunnel mode should be used ONLY when connecting to downlevel VPN servers/gateways. If you're using ISA firewalls on both side, always use L2TP/IPSec for the highest level of security.
Posts: 3
Joined: 8.Oct.2004
From: Australia
Status: offline
I wonder what other people think about this situation..
Having domain member servers in a DMZ has been technically possible with other firewalls for, well, forever. A typical scenario is where one or more DMZ servers are providing some kind of network service to the public and for whatever reason, the server needs to be a member server.
Quite often the reason for segmenting the server in the first place is to limit the amount of damage an attacker could do if the DMZ server is compromised. However, by permitting DMZ<->Internal network communication, you have exposed some of your most critical internal network services.
I've often wondered whether it's really worth the effort when in order to support domain member servers across a firewall, you have to open up so many ports (and it doesn't make much difference if you've got member servers in a DMZ or you've got a separate domain with a trust).
I admit it's better than permitting connections from the outside to hit a server in the internal network, but am I the only one that doesn't get a warm fuzzy feeling from the whole DMZ member server scenario?
I would only want to do this for an authenticated DMZ segment. Only connections that are authenticated *at the ISA firewall first* are allowed into such a DMZ segment.
I would NOT put domain members into an anonymous access DMZ segment.
I have clients scattered all over the nation. They sit at home, they sit in customer offices...they come at the network from a variety of locations. I want them to have secure, password protected access to the intranet. I am curious what options I have in this scenario to authenticate these incoming connections "at the ISA firewall first*." I would like to use their AD accounts for access, either with a DMZ DC or a new, trusted domain.
Do I need to issue them all certs? Does anybody else have this problem?
Unfortunately, I did not work!, I always get "Remote Procedure Call Failed". When I check the computer list in the PDC I find the computer name has been added but with red cross "disabled".
I monitored all denied traffic, nothing there !. I have configured a rule to allow ALL OUTBOUND to/from the PDC, the same!.
I have stopped the firewall service, it worked !. When I enabled the firewall service again everything continues to work smoothly with PDC.
What was preventing the ISA Server from joining the PDC?. How can we make it work without stopping the firewall?.
quote:Originally posted by mountaindew: I have clients scattered all over the nation. They sit at home, they sit in customer offices...they come at the network from a variety of locations. I want them to have secure, password protected access to the intranet. I am curious what options I have in this scenario to authenticate these incoming connections "at the ISA firewall first*." I would like to use their AD accounts for access, either with a DMZ DC or a new, trusted domain.
Do I need to issue them all certs? Does anybody else have this problem?
Hi MD, This sounds like a good VPN scenario to me.
Unfortunately, I did not work!, I always get "Remote Procedure Call Failed". When I check the computer list in the PDC I find the computer name has been added but with red cross "disabled".
I monitored all denied traffic, nothing there !. I have configured a rule to allow ALL OUTBOUND to/from the PDC, the same!.
I have stopped the firewall service, it worked !. When I enabled the firewall service again everything continues to work smoothly with PDC.
What was preventing the ISA Server from joining the PDC?. How can we make it work without stopping the firewall?.
Thanks
Hi Karmi,
I've heard people mention this happening, but I've not ever been able to reproduce it. I suspect that everyone doing this is making the same configuration error, but I can't figure out what that error is