[isapros] Re: Exchange NSPI Proxy RPC Communications and ISA
- From: "Jason Jones" <Jason.Jones@xxxxxxxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Sun, 13 Aug 2006 22:38:43 +0100
Hi Tim et al,
KB would be good to show the customer some MS evidence of why I am doing it via
static ports. What is really, really annoying is that this is how the customer
had their DCs setup originally, but it made windows firewall config on the DCs
really painful. I recommended they ditch the static RPC ports approach, as ISA
could easily handle the use of dynamic RPC!!! Doh!!!! :-))
More and more of my designs are going this way (SID and LP) - I am finding that
more customers are wanting to take full use of ISA for internal firewalling,
especially when they have MS networks with products like Exchange. SharePoint
etc. The RPC story is normally the clincher and very much a killer ISA feature
when used as a multinetwork firewall. If you think about most universities (the
customer) you can see why they distrust their internal networks so much. In
these scenarios, ISA is brilliant at providing segmented application networks
for things like Exchange. The RPC and HTTP filters via secure publishing make
for a very well protected application - but I guess you guys know that! ;-)
During the design phase, we talked about placing the DCs on the backend
network, but there were some concerns about how this would affect client access
to the DCs from the campus network. The customer was also keen to add a new ISA
network specifically for the DCs or even move the DCs to the same network as
the CSS servers. I am guessing the later options would still introduce the
issue I am seeing though.
The issue definitely only seems to affect the NSPI proxy connections, as all
other Exchange connectivity works really well. If I set the NSPI logging to
maximum, I can now see the RPC port numbers that the BE is using to talk to the
DCs in the application event log. If I compare this to the ISA logs, I can
match up exactly when it works, and exactly when it doesn't, by specifically
changing my firewall policy rules. From what I can gather the NSPI proxy on the
BE is only used for RPC/HTTP connections as normal MAPI client get a referral
which tells them to talk direct to the GC rather than Exchange having to proxy
the connections. Something I am going to try, is to set the Exchange "No RFR"
option to see if I then get the same issue with MAPI clients - chances are, I
will...
I would love to log a PSS call for this and the other RPC issue I have seen
recently, but even as an MS security gold partner, PSS calls still cost us
£1500 a go :-((
Let you know if I get any further...
JJ
________________________________
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thor (Hammer of God)
Sent: 13 August 2006 20:13
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA
I recall a KB out there somewhere (I'll research when I have some time) where
the circumstances dictated "static" assignment of a fixed RPC port range for DC
communications just as you have done here- this very well may be that
circumstance. Jim's later post regarding "the only way ISA can handle RPC is
via Exchange RPC or RPC (All Interfaces) may support that theory.
Hat's off to you for being committed to deploying security-in-depth with
least-privilege and not acquiescing to the "whatever works" mentality. I know
it's a hard thing to deploy and support. While I have a similar topology, I
only separate the clients from the servers with an infrastructure ISA box- not
the BE's from the DC's; they're on the same "protected" network.
That being said, I think the explicit range assignment might actually be a more
reliable method of ensuring proper RPC communications between your DC and BE
given ISA in the middle- as long as you only allow that range between just
those boxes, I think you've still adhered to the principles of SiD and LP. If
Jim is correct (and there is no reason for me to think otherwise) then you
really don't have a choice. But it is odd that is only happens for RDP/HTTP.
My "FE in the Perimeter" setup that I gleaned off of Tom does not exhibit this
behavior, but again, my BE's talk directly to my DC's.
If you figga it out, please post back - I for one would be interested in what
the cause is.
t
On 8/12/06 3:22 PM, "Jason Jones" <Jason.Jones@xxxxxxxxxxxxxxxxx> spoketh to
all:
From some testing, if I configure the DCs to use a fixed RPC range
(50000-50100 say) and then configure ISA to allow allow these ports in addtion
to RPC (All Interfaces) and other intradomain prorotocls then the NSPI proxy
connects properly. Surely I shouldn't need to do this though, as ISA should
allow for dynamic RPC port allocation??
As I have said, ISA correctly performing inspection of dynamic RPC port
allocations for other communications, just not the NSPI proxy process it would
appear.
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
Sent: 12 August 2006 22:41
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA
Maybe a napkin drawing, then?
I don't understand how your BE needs specific rules unless its
separated from the DC by ISA?
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
Sent: Saturday, August 12, 2006 2:19 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA
No, not confused, and realise the difference between RPC/HTTP and MAPI.
I guess I am obviously not explaining myself very well with a complex
environment and the problem very specific.
>>AS such, any NSPI connections are strictly the problem of the BE
server.
Not in this scenario, as the BE is in an ISA protected network
seperated from the DCs and FEs. The rule that allows access from BE=>DCs is
using RPC (All interfaces) and yet ISA is blocking traffic from the NSPI proxy
when using RPC/HTTP. All other RPC traffic from BE=>DCs is working as expected
and ISA is detecting the RPC dynamic ports correctly.
If I allow All outbound protocols from BE=>DCs the NSPI proxy works and
I see ports 1025. 1026 etc being used. It seems as if ISA is missing the
intitial RPC negations between the NSPI proxy and DCs and hence blocks all
dynamic ports after 135 is contacted.
Maybe I need to provide some diagrams and/or better desacirptions...
JJ
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
Sent: 12 August 2006 16:55
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA
I think you're confused; RPC/HTTP doesn't use MAPI; it's "just" HTTP
traffic.
AS such, any NSPI connections are strictly the problem of the BE server.
The only way ISA handles RPC traffic is via Exchange RPC or RPC (All
interfaces) rules.
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
Sent: Friday, August 11, 2006 5:13 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Exchange NSPI Proxy RPC Communications and ISA
Hi,
Bit of a shot in the dark, as this is a strange issue, but hoping
someone can confirm what I am seeing.
Basically, I have a pretty secure Exchange environment whereby both
Exchange FE's and BE's are on ISA protected perimeter networks with the
external network connected to the 'traditional LAN' e.g., ISA is acting as a
multinetwork internal firewall to specifically protect Exchange from the
internal network (all routed relationships). In this scenario, ISA is
controlling all communications to and from Exchange and all email client access
is published using web publishing or secure RPC publishing.
Up until now everything has been working pretty well (apart from the
other RPC filter issues in my other posts!) but we have come across a specific
issue when using RPC/HTTP as follows:
The problem seems to lie with the fact that the back-end Exchange
server is talking to the GCs and ISA is seeing these connections as newly
initiated connections (e.g. non RPC) as opposed to detecting them as dynamic
ports which have been defined as part of the RPC handshake process. Therefore,
ISA is dropping these connections and prevents the back-end server from
communicating with the GCs, specifically for RPC/HTTP (e.g. when using the NSPI
proxy). All other communications which relate to RPC and ISA's ability to
detect dynamic RPC ports is being done successfully (e.g. MAPI communications
from Outlook to Exchange). It looks to me as if the back-end Exchange server is
initiating it own connections which ISA sees as communications independent of
RPC. The issue only appears to arise when the back-end servers proxy the client
AD communication (e.g. when using the NSPI proxy), as is the case with
RPC/HTTP, because Outlook clients have no access to the GCs from the Internet.
For standard MAPI clients, they are simply given a referral to the actual GCs
which they communicate with directly, independent of Exchange (e.g. not using
NSPI proxy).
Does this sounds familiar? Is Exchange doing something weird here or is
ISA missing the RPC dynamic port negotiations?
Looking at the ISA logs, I see ports 1025, 1027, 1030 etc. being used
by the NSPI proxy which I am pretty sure are going to be the kind of ports
dynamic RPC would use. If I add the ephemeral ports (1024-65535) to the
existing BE=>GC rule everything work just fine. If I limit ports to standard
intradomain protocols including RPC then everything works apart from RPC/HTTP
and I start seeing ports 1025, 1027 etc. being denied by ISA as unidentified
traffic.
Answers on a postcard! ;-)
Cheers
JJ
All mail to and from this domain is GFI-scanned.
All mail to and from this domain is GFI-scanned.
Other related posts:
