[isapros] Re: Exchange NSPI Proxy RPC Communications and ISA
- From: "Jason Jones" <Jason.Jones@xxxxxxxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Wed, 23 Aug 2006 23:16:44 +0100
Had exactly the same issue with another customer, so got some good
evidence for a PSS call now...will update when I can...
________________________________
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jason Jones
Sent: 15 August 2006 23:21
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA
Right, managed to do some more testing today with the following
findings:
By setting the NSPI proxy diag logging to maximum, I now see the RPC
ports being used by the proxy. These seem to be 1025, 1027 and 1030
pretty consistently, but I would guess they could increase depending on
the number of clients (I was only testing with one or two). By matching
these ports to the ISA logs I can now see the initial 135 connection
being allowed by ISA, followed by 1025 also being allowed by ISA. Both
protocols are shown as "RPC (All interfaces)". Any subsequent ports like
1027 and 1030 are shown as "unidentified" and subsequently blocked by
ISA. By cross referencing these to the NSPI logs, I can see why the
proxy is unable to connect to the GC as ISA is dropping the connections.
If I create static a static RPC port range on the DCs and configure ISA
to allow these protocols (inc RPC and other intradomain) then the NSPI
proxy works just fine. If I configure a new protocol on ISA using the
1024-65535 range then the NSPI proxy also works just fine.
As I test, I also created RPC server publishing rules to publish the DCs
to the Exchange Back-end servers for RPC Server, thinking this may make
the RPC filter "more aware". However, this worked for RPC connectivity
but I still saw 1027 etc. being blocked as unidentified. Kinda looks to
me like ISA is not identifiying these ports as part of the RPC
communications for some reason - maybe the NSPI proxy is doing something
weird outside of the portmapper???
Customer is happy with the RPC static port range workaround for now, but
wants to understand why this is happening...a call to PSS is on the
cards!
Unlikely I know, but any more ideas???
________________________________
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:
