Allowing Domain Membership through a Cisco Firewall

When setting up windows networks a DMZ must be created. This DMZ cannot contain any PC's that are a member of your internal Active Directory domain for security reasons. For your SME companies best practice is to generally configure all machines in your DMZ in a workgroup setup. For your enterprise companies best practice is to create a separate active directory forest for your DMZ. This allows centralised management over your DMZ servers allowing administrators to control servers using things such as Group Policy and WSUS.

However there are times where you need to allow PC's in your DMZ to access your internal Active Directory. For example I needed to setup an ADAM server to synchronise only particular attributes from various domains in an Active Directory forest which to be exposed to the internet using LDAPS (Secure LDAP) on secure port 636 for an external application. This ADAM server needs to be a member of of the Active Directory domain as I require User Proxy Bind Redirection to forward authentication requests through to an Active Directory domain controller. We created a separate DMZ just to contain this server requiring domain membership.



For more information on User Proxy Bind Redirection see:

http://clintboessen.blogspot.com/2011/04/userproxy-class-and-adam-lds.html

Windows machines are not very "firewall friendly". To start off with we opened up the following ports between our isolated "Domain DMZ" and our internal network:

UDP 53 – DNS Queries
TCP 88 – Kerberos v5 over TCP
UDP 88 – Kerberos v5 over UDP
TCP 135 – Microsoft Report Procedure Call Endpoint Mapper
UDP 389 – Unsecure LDAP over UDP
TCP 389 – Unsecure LDAP over TCP
TCP 443 – WSUS Windows Updates
TCP 445 – Simple Message Block Protocol
TCP 1688 – Key Management Server
TCP 3268 – Global Catalog Requests
TCP 3389 – Remote Desktop for management purposes

All the ports above still do not allow a workstation to be a member of an Active Directory domain due to the DCOM RPC ports. Microsoft RPC (MS-RPC) does not only use port TCP135 it also uses randomly generated ports from TCP 1024-65535 for XP/2003 and TCP 49152-65535 for Vista/2008 upwards. These are frequently informally referred to as "random RPC ports." In these cases, RPC clients rely on the RPC Endpoint Mapper (EPM) which runs on TCP135 to tell them which dynamic port(s) were assigned to the server.

Multiple components from the underlining windows subsystem get assigned their own dynamic RPC port every time the windows PC boots. These components include:

- Active Directory (Local Security Authority) – Runs on each domain member!
- Certificate Services
- Cluster Service
- Distributed File System
- Distributed File System Replication
- Distributed Link Tracking Server
- Distributed Transaction Coordinator
- Outlook MAPI Client
- ISA Server
- Fax Service
- File Replication
- FTP Publishing Service
- Group Policy
- Net Logon
- Remote Storage Notification
- Remote Storage Server
- Systems Management Server 2.0
- Terminal Services Licensing
- Terminal Services Session Directory

All these windows components get a dynamic port each time the system boots. RPC clients discover which port these services are on by querying TCP 135 (the port mapper).

So how did we get around this without opening every port from 1024-65535?

Our corporate firewall is currently a Cisco ASA 5540 running OS v8.4(1). The lastest Cisco OS software for the 5540 has integrated smarts for the Windows RPC Endpoint Mapper (EPM) running on TCP135. Cisco refers to this as "DCERPC".

This process works as follows:
1. A client queries an EPM server for the dynamically-allocated port number of a required DCERPC service. The EPM server listens on the well-known TCP port 135.
2. The ASA, located between the client and EPM server, intercepts the communication.
3. The EPM server indicates the port number on which the DCERPC service is available.
4. The ASA opens a pinhole for that DCERPC service.

This allows us to make the access control lists (ACLs) as tight as possible maintaining security whilst allowing application functionality through the ASA firewall.

Here is the Syntax used for configuring this functionality on our ASA:

class-map dcerpc
match port tcp eq 135
policy-map interface_dcerpc
class dcerpc
inspect dcerpc

service-policy interface_dcerpc interface dmz_adam

interface_dcerpc is our custom Service Policy
dmz_adam is our costom interface

Of course you also need to allow TCP135 (the RPC Port Mapper) in the ACL rules for this to work!

For more information on these dynamically generated RPC ports used by Windows Systems please see the following Microsoft knowledge base articles:

http://support.microsoft.com/kb/154596
http://support.microsoft.com/kb/832017

A big thank you to Peter Revill (CCIE #18371 Routing and switching, Voice) for helping me out on this one.