Welcome to ISAserver.org

Discussion about article on Intradomain Communications through the ISA Firewall

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA Server 2004 Firewall] >> DMZ >> Discussion about article on Intradomain Communications through the ISA Firewall

Page: [1] 2 3 next > >>

Message

<< Older Topic Newer Topic >>

Discussion about article on Intradomain Communications ... - 6.Sep.2004 9:54:00 PM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

This thread is for discussing the article on allowing intradomain communciations through the ISA firewall over at http://isaserver.org/articles/2004perimeterdomain.html.

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.

Thanks!
Tom

[ September 06, 2004, 10:37 PM: Message edited by: tshinder ]

Post #: 1

Featured Links*

RE: Discussion about article on Intradomain Communicati... - 7.Sep.2004 9:23:00 AM

amakki

Posts: 3
Joined: 26.May2004
Status: offline

Dear,
What about if I have DMZ configured in other Hardware Firewall lets say PIX firewall and ISA configured as a back-end??
Thanks

(in reply to tshinder)

Post #: 2

RE: Discussion about article on Intradomain Communicati... - 7.Sep.2004 10:41:00 AM

gerpion

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.

That's it

(in reply to tshinder)

Post #: 3

RE: Discussion about article on Intradomain Communicati... - 7.Sep.2004 2:45:00 PM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

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?

Thanks!
Tom

(in reply to tshinder)

Post #: 4

RE: Discussion about article on Intradomain Communicati... - 7.Sep.2004 2:47:00 PM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

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

(in reply to tshinder)

Post #: 5

RE: Discussion about article on Intradomain Communicati... - 7.Sep.2004 4:20:00 PM

gdetant

Posts: 2
Joined: 7.Sep.2004
Status: offline

Hello,

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.

Is this possible ?

gert

(in reply to tshinder)

Post #: 6

RE: Discussion about article on Intradomain Communicati... - 7.Sep.2004 6:41:00 PM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Gert,

That is what this article was all about. Allowing intradomain communications through the ISA firewall.

HTH,
Tom

(in reply to tshinder)

Post #: 7

RE: Discussion about article on Intradomain Communicati... - 8.Sep.2004 10:15:00 AM

gerpion

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 [Smile]

(in reply to tshinder)

Post #: 8

RE: Discussion about article on Intradomain Communicati... - 8.Sep.2004 2:47:00 PM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Gerpion,

Thanks! [Big Grin]

Tom

(in reply to tshinder)

Post #: 9

RE: Discussion about article on Intradomain Communicati... - 10.Sep.2004 11:09:00 AM

gdetant

Posts: 2
Joined: 7.Sep.2004
Status: offline

I'm sorry Tom, but i forgot one important aspect, is this possible on a ISA 2000.

gert

(in reply to tshinder)

Post #: 10

RE: Discussion about article on Intradomain Communicati... - 12.Sep.2004 4:34:00 PM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Gert,

Yes, sort of, but not supported. There is an article on this site on how you can sort of maybe do it.

HTH,
Tom

(in reply to tshinder)

Post #: 11

RE: Discussion about article on Intradomain Communicati... - 28.Sep.2004 4:10:00 AM

ahamstra

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.

Any ideas?

(in reply to tshinder)

Post #: 12

RE: Discussion about article on Intradomain Communicati... - 28.Sep.2004 4:40:00 AM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi A,

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.

Thanks!
Tom

(in reply to tshinder)

Post #: 13

RE: Discussion about article on Intradomain Communicati... - 8.Oct.2004 6:58:00 AM

cactoid

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?

What do you all think?

(in reply to tshinder)

Post #: 14

RE: Discussion about article on Intradomain Communicati... - 18.Oct.2004 7:48:00 AM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

Hi Cac,

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.

Thanks!
Tom

(in reply to tshinder)

Post #: 15

RE: Discussion about article on Intradomain Communicati... - 2.Nov.2004 4:13:00 AM

Ara.A

Posts: 259
Joined: 21.Oct.2004
Status: offline

Thnaks

very handy

(in reply to tshinder)

Post #: 16

RE: Discussion about article on Intradomain Communicati... - 16.Dec.2004 5:20:00 PM

mountaindew

Posts: 7
Joined: 21.Jun.2004
From: MD
Status: offline

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?

(in reply to tshinder)

Post #: 17

RE: Discussion about article on Intradomain Communicati... - 19.Feb.2005 10:39:00 AM

karmi

Posts: 32
Joined: 5.Nov.2004
Status: offline

Hello,

I am trying to let the ISA Server 2004 to join a domain in our internal network. I have configured everything exactely as describerd in this article

http://www.isaserver.org/articles/2004perimeterdomain.html

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

(in reply to tshinder)

Post #: 18

RE: Discussion about article on Intradomain Communicati... - 19.Feb.2005 2:16:00 PM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

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.

HTH,
Tom

(in reply to tshinder)

Post #: 19

RE: Discussion about article on Intradomain Communicati... - 19.Feb.2005 2:19:00 PM

tshinder

Posts: 47010
Joined: 10.Jan.2001
From: Texas
Status: offline

quote:
Originally posted by karmi:
Hello,

I am trying to let the ISA Server 2004 to join a domain in our internal network. I have configured everything exactely as describerd in this article

http://www.isaserver.org/articles/2004perimeterdomain.html

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 [Frown]