Having an internal A record and an external A record with the same host name. Using this method as described will work fine.
BUT if the user connects via the VPN, the name lookup issue gets weird. My guess is when a user has connected via VPN and then an NSlookup of the Exchange server will yield the external IP. In that case will Exchange be connectign via RPC over HTTP? Or wil it be tunneling through the VPN to the private IP?
Wouldn't RPC over HTTP be better for the following reasons?
All traffic goes over TCP port 80 so that port blocking won't be an issue.
All data payload and authentication is encapsulated and encrypted within SSL. Since normal Exchange authentication uses NTLM and CHAP, that means it would be extremely easy to dictionary crack the password much like the way you crack LEAP or PPTP. An SSL tunnel should protect the whole thing.
For these two reasons, better security and better firewall traversal, I think taking the time to enable RPC over HTTP is well worth it. Of course, you must have Outlook 2003 and Exchange 2003 for it to work. However, the security considerations alone should elevate HTTP encapsulation to a must have.
RPC over HTTP is nice, but there are two major issues:
1. It requires both Outlook 2003 and Exchange 2003, so if you aren't using both, you're out of luck.
2. You have to allow uninspected SSL tunnels outbound through your network to allow users to use it. That's a security risk. In contrast, my ISA firewall inspects outbound RPC, so I'm secure on my outbound and inbound RPC.
I missed you statement re: NTLM. That's true, but overall, I'm less concerned about someone running rainbow tables against my RPC connections than someone tunneling any protocol they like through SSL. So I block outbound SSL except to full qualified users, and then only to approved sites.
Security concern: As with the PPTP and LEAP authentication issue, the password can be broken any time an authentication protocol relies purely on a hashed password challenge. The soul protection you get is the strength of your password. Unless you're willing to enforce very strong passwords and routinely audit them with something like L0phtCrack or a commercial version of the tool, I would not run any form of CHAP authentication over an untrusted and sniffable Internet. Once the Exchange authentication session (NTML MSCHAPv2) is captured with a free sniffer, the game is over and your password is seconds away from being revealed as clear text. This is extremely easy to do now with the proliferation of Wireless LAN hotspots and you really canĂt find Wired Ethernet service anymore since all the hotels have wised up that Wireless is cheaper to deploy. It is a known fact that 90% of any organizations passwords are crackable within hours and 99% are crackable within a week unless you want your users writing down their passwords. Once I have your password, I can probably come directly in to your network and access your servers via PPTP VPN or at least I can access your Exchange server. If I have a Domain AdminĂs password, then I completely own your network and your servers and I get to play God or Devil.
As for the SSL outbound issue, I donĂt know of a single hotel that blocks SSL. I would also wager that most corporate or organizations are much more likely to permit SSL than TCP 135. As for inbound SSL, you only need to open SSL to a single server in the DMZ. IĂm wondering if ISA2004 can terminate the SSL tunnel for RPC traffic so that you can inspect the traffic. There are also IDS/Firewall solutions that allow you to snoop in on SSL traffic.
As for the requirement for both Outlook 2003 and Exchange 2003, you have a point there. The company that I was with uses both so they didnĂt have a problem. I think using the small business license for Exchange 2003 makes it pretty attractive. Maybe Microsoft could add SSL/RPC termination capability to ISA server and offer an add-in for older versions of Outlook to address some of your particular concerns. From my point of view, protecting the userĂs password is priority one because I wouldnĂt want to give hackers the key to my kingdom.
The point with SSL isn't that hotels, conference centers, etc don't allow it outbound. The issue is that I don't want to allow it outbound through my networks that I control. The stuff moving through an SSL tunnel is completely out of my control, just like with VPNs. I don't allow VPNs outbound through networks until my control either for the same reason -- you can secure the connection at the firewall if you tunnel through the firewall. It would make my ISA firewall as helpless as a PIX!
I do appreciate what you're saying about password complexity and you're right. I use several common strings in people's lives and concatenate them. However, I know how difficult it is to scale complex passwords
From a usability standpoint, I'm strictly looking at this from a road warrior's perspective in hotels, airports, and other hotspots since thatĂs where they would want to use Outlook without a VPN. I wouldnĂt allow these external road warriors to connect to my internal LAN in the first place. For external users, IĂve created a ˘Guest÷ Wireless LANs off of a virtual SSID on the existing production Wireless LAN so they get the royal hotspot treatment. For internal users, they have no business connecting to some other Outlook server in the first place. I donĂt blame you for blocking outbound SSL though, but CheckPoint VPN client in ˘Guest mode÷ will tunnel through port 80 so IĂm not sure how you block something like that on an ISA server. The Breachview product claims to eliminate the ˘blind spot÷ in SSL with your existing firewall by using a client agent to tell your firewall or IDS the SSL session key.
As for the strength of complex passphrases that use the first letter of every word or just the entire words out right, that certainly eliminates all but the NSA and really serious hackers. Any password you can conjure up using a series of words can easily fit each and every combination in to a 1 terabyte database. ASLEAP for example can now support greater than 4 terabytes and can scan through them at a rate of 45 million pre-computed hashes per second so it doesnĂt take long to run your password through a 4 terabyte database. There are simple tools that can generate password or pass-phrase tables based on your preference. This is why I donĂt even bother with complex passwords because my time is much better spent enforcing strong authentication protocols. Servers and gateways can be made to behave, humans cannot because they will find a way to make it easy either by putting the password in their PDA or writing it down on a sticky note.
RE: Discussion about article on Outlook Access from Any... - 8.Feb.2005 4:52:00 AM
I don't know if everyone reads the article but after "Creating the Exchange RPC Server Publishing Rule" paragraph, point 4 states for "SMTP server" protocol rule but the protocol selected is Exchange RPC server that should be the correct protocol for the heading.
From: New York
Dear All: I have a win2k server box with ISA 2004 and Exchange 2003. I followed the procedure posted by Thomas Shinder. However, my outlook client still cannot connect, though the name check seems to work fine. I got "Cannot Start Microsoft Office Outlook. Unable to open the Outlook window. The set of folders could not be opened". In addition, the outlook tray icon keeps on telling me the exchange connectoin has been lost/restore. Is there some other ports I need to open (I didn't see any rejections from ISA when I attempt to access the server), or there are something else I need to configure? Any help will be very grateful. Thx in advance.
My guess is that this is a name resolution issue. What are the exact names of your Exchange Server, the name you've configured the Outlook client to use from the Internet, and the actual IP addresses of the ISA firewall and Exchange Server on the corpnet?
From: New York
Hi Tom: Thank you for your prompt reply. My outlook client is trying to connect to domain.domain.com. Both domain.com and domain.domain.com are pingable over the net. In addition, both of them resolve to an IP address which is the only IP on my box (Exchange and ISA).
I missed something about your configuration. If you have ISA and Exchange on the same machine, its impossible to use Secure Exchange RPC publishing, IIRC. I've never tested a co-lo ISA/Exchange, since its not a supported config.
Actually, it was impossible to publish Secure Exchange RPC on ISA 2000. It would be an interesting experiment to see if it would work now, but again, its not a supported config and who knows what else might blow up and become a security hole that attackers could leverage.
From: New York
Hi Tom: I know I am working with the very odd environment, but due to political and other nonsense reasons. This is the only setting that I can use. I am just wondering if I down grade it to "Dumb as a Traditional Stateful Packet Inspection Firewall". Will it work?
From: San Angelo, TX
This was a great article - something I've been wanting to make happen for a while. Unfortunately, I can't get it to work. I have followed all the steps exactly, but my remote clients can't connect.
I get an alert in ISA that says "The connectivity to the publishing RPC service changed." and in the Windows event log, the following event is logged: Event Type: Warning Event Source: ISA Server RPC Filter Event Category: None Event ID: 20021 Date: 3/1/2005 Time: 9:37:34 AM User: N/A Computer: <ISA Server> Description: The published RPC service <Exchange server IP>:135 cannot be reached.
I am using the hosts file method for testing. We only have a few users anyway that will need this initially. In the hosts file, I have tried both the Exchange Server host name and the FQDN pointing to the external IP of the ISA server.
I can't even get the profile setup in the remote Outlook client. When I put in the server name and the username and click Check Name, that is when it fails. I get an error that says, "The name could not be resolved. The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action."
I do see the request get to the ISA server by using the real-time logging. I see it Initiate the connection from the Client to the ISA server on port 135, but then I get a "Failed Connection Attempt" with: Destination IP: <Exchange Server IP> Destination Port: 135 Protocol: Exchange RPC Server Rule: Publish Secure Exchange RPC
I can't figure out where this is failing at. It seems like ISA can't talk to the Exchange server on port 135, but I can't find any reason why not.
Any ideas? Sorry if this was a long post, but I wanted to give as many details as I could.
Make sure the Exchange Server is a SecureNAT client. I made this mistake in front of some very important people who I was trying to impress with this feature, and took an hour to figure out that I was a bonehead
From: San Angelo, TX
Thanks for the reply. I don't know if this is going to work for us or not. I tried to make the Exchange server a SecureNat client by changing the default gateway to be the ISA server. Before I changed it, the gateway was our core router, whose default gateway is our Cisco pix firewall. The Pix box is our default route to the internet. We are just using ISA to publish some servers and for vpn and I was hoping to use it for this also. But when I changed the default gateway on the Exchange Server to be ISA, we started getting calls from users saying that their Outlook could not connect to the Exchange Server. Email worked fine on the same network as the Exchange Server, but other subnets were having trouble. I'm really not sure why that happened. The ISA server has a static route that lets it communicate with all other networks.
The good news is that when I changed the gateway on Exchange, a remote Outlook client was able to connect to Exchange and get their email - at least somewhat. I got it to work once, but then Outlook disconnected from the Exchange server and I could not get it to reconnect. I also had a connectivity verifier to the Exchange Server port 135 running on ISA and it was very shaky. Sometimes it would verify and other times it would timeout and fail.
So I had to change the default gateway back because people could not get their mail. Unless you have any ideas, I think I will give up on this for now until we can get Exchange 2003 which should be maybe a year away. When I read your article, I was hoping I could make this work before that, but that may not happen.
Thanks for the help and let me know if you can think of anything that I haven't thought to try.
The ISA dev team was aware of situations like yours and enabled a new feature that allows the ISA firewall to replace the original source address of the Internet host with the IP address of the ISA fireall itself.
So, this means you don't need to change the gateway address of the Exchange Server, since the Exchange Server should know the route to the Internal interface of the ISA firewall.
So, check the checkbox in the Secure Exchange RPC Server Publishing Rule to replace the source IP address with the ISA firewall's address.
From: San Angelo, TX
Well, I tried your suggestion and I thought this was working. We have a computer here at work that we have sitting outside our network with a public IP that we can use to test firewall issues. As soon as I made the change you suggested, it started working. I was able to connect to our Exchange server with Outlook.
But then I tried it from home and it doesn't work. The weird thing is that I never even see the request get to the ISA server. I wonder if my ISP or something would be blocking that traffic? A coworker tried it from home also (same ISP - Cox cable) and she could not get it to work either. We both also have a personal router with built-in firewall at home. I thought maybe that was blocking it, but I checked and my router is allowing all outbound traffic, so I don't think that's the issue.
Weird. Any thoughts? If it's the ISP, there may not be anything I can do. I don't know why the ISP would be blocking it, but it's just strange that the request never even shows up in ISA.