Stanislas Quastana’s Guide to Intradomain Communications Including AD UUIDs
I’ve done a number of intradomain communcations articles where I describe how to configure the ISA firewall to allow domain members to be placed in a secure, authenticated access DMZ segments. This is crucial information for properly securing front-end Exchange Servers.
As you probably already know, in order to secure front-end Exchange Servers, you need to place them in a security zone different from the back-end Exchange Server security zone. That’s because the front-end Exchange Server is an Internet facing device and the back-end Exchange Server is not Internet facing.
For comprehensive coverage on why the front-end Exchange Server needs to be in an authenticated access DMZ, check out Creating Multiple Security Perimeters with a Multihomed ISA Firewall Part 1: DMZ Design Concepts and Why the Front-end Exchange is Placed in the DMZ at http://www.isaserver.org/tutorials/Creating-Multip...1.html
As good as I think my intradomain communcations are, I always knew that someone smarter and stronger than me would come up with something that could make them better. That smarter and stronger guy is Stanislas Quastana. He has a Blog post Segmenting Networks with ISA 2004 — Filtering access to Domain Controllers at http://blogs.msdn.com/squasta/archive/2006/03/17/5...5.aspx that nicely summarizes the protocols required and also the custom domain UUIDs you can use for RPC communications. Those UUIDs are golden!
Many thanks to Stanislas and his team for doing the hard work to discover those UUIDs.
HTH,
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP — ISA Firewalls
BlackPH Says:
April 13th, 2006 at 4:32 am
I have tried this perfect way of RPC filtering ,but nothing. Maximum result when i have - is error about wrong TCP checksum on EMP Map request level
”
Internet Protocol, Src: 172.16.2.2 (172.16.2.2), Dst: 192.168.1.248 (192.168.1.248)
Transmission Control Protocol, Src Port: 1130 (1130), Dst Port: epmap (135), Seq: 117, Ack: 85, Len: 156
Source port: 1130 (1130)
Destination port: epmap (135)
Sequence number: 117 (relative sequence number)
Next sequence number: 273 (relative sequence number)
Acknowledgement number: 85 (relative ack number)
Header length: 20 bytes
Flags: 0×0018 (PSH, ACK)
Window size: 65451
Checksum: 0×7169 [incorrect, should be 0×9142]
SEQ/ACK analysis
This is an ACK to the segment in frame: 6
The RTT to ACK the segment was: 0.000029000 seconds
DCE RPC Request, Fragment: Single, FragLen: 156, Call: 1 Ctx: 0
Version: 5
Version (minor): 0
Packet type: Request (0)
Packet Flags: 0×03
Data Representation: 10000000
Frag Length: 156
Auth Length: 0
Call ID: 1
Alloc hint: 132
Context ID: 0
Opnum: 3
DCE/RPC Endpoint Mapper, Map
”
I used “access” rule, not “public”. DMZ and Internal have route relationship. When i remove my “RPC for AD Logon” filter protocol, and add predefined RPC (all interfaces) - all working fine.
Thomas Shinder Says:
April 13th, 2006 at 6:35 am
The checksum issue has nothing to do with RCP UUIDs.
Make sure you’re following the complete procedures in both mine and Stan’s articles.
HTH,
Tom
Stanislas Quastana Says:
April 14th, 2006 at 3:21 pm
Hi,
You must use a publication rule for RPC filtering (by design the RPC filter apply only to incoming RPC traffic). It’s “normal” (by design) that RPC filtering doesn’t work with access rule
This publication rule works also between 2 routed networks (don’t forget to check source ip = client IP adress)
- Stanislas -
Thomas Shinder Says:
April 15th, 2006 at 7:09 am
Hi Stanislas,
Thanks!
Tom
BlackPH Says:
April 17th, 2006 at 8:49 am
it`s new knowlege for me. But if i want use RPC filter for FE Exchange - i will need use only 1 DC+GC
Very big 10x Stanislas.