Ramblings from another nerd on the grid
One of my favorite features of all time is RPC Over HTTP. Most of you are familiar with it because it allows Outlook to encapsulate RPC calls inside a HTTP packet or frame. That frame must of course travel across the internet to your “Front-End” server or proxy. All of that voodoo just makes it trivial for users to check email without first having to deal with a RAS/VPN infrastructure. RPCHTTP rocks and everyone knows it. But, if you’re like most of the geeks I know, you probably cracked the joke about wanting HTTP Over HTTP (HoH).
Guess what? It’s coming. Well, sort of. It isn’t really HTTP Over HTTP. Think of it more like fine grained control of multi factor authentication across HTTP.
This week I started testing our internal implementation of this new set of technologies using ISA Server 2006 and it’s ability to provide access to Microsoft internal LOB applications.
I was able to access my team’s SharePoint site, our expense reporting website, the security and email distribution list maintenance site, the bug reporting site, our timecard website and a few other pilot sites. SharePoint is of course pretty easy to publish with ISA Server 2004. However, until ISA 2006 and this pilot, access to many of the other sites required me to use a VPN connection. This also meant that the machine must be part of the Microsoft corporate Active Directory (AD) Forest in order to allow the IPSEC policies to work their magic. Several of my home machines are not part of the corporate forest, so access to the applications wasn’t an option. This is no longer true.
I recently purchased a new Dell Latitude D820. It’s my personal machine and I have no intention of adding it to the corporate forest and allowing SMS to control it. With this pilot however, I was able to simply pop my smartcard into the D820 built-in smartcard slot and go hit the portal website (see login screen shot). I modified the screenshot and removed our DNS name. Sorry.
The first time I went to this website, IE7 complained about the SSL certificate presented. Since my machine is not part of the corp forest, it doesn’t have the root CA certs already installed so the certificate path wasn’t trusted. This is of course easily fixed by installing the cert, which I did.
I should also mention that before being presented this screen, you are prompted for the pin to the local smartcard cert. Ah, multi-factor is a good thing.
After logging in, we get a custom webpage with the listing of supported websites. It isn’t wide open so I am not able to access resources like the daily Windows Vista .iso’s or another personal SharePoint web I have.
I did submit my expense reports Thursday across the connection. It was very nice to not have to VPN. Ok, I’m lazee.
I’ll be really impressed if we can rethink access to our product servers. Today, most of the beta’s I download are via a VPN connection using the SMB protocol. I would jump up and down for joy if I could use HTTP to grab the Windows Vista DVD .iso file from our internal servers. I’m guessing I’d see a huge improvement in performance by doing that. Improvement equals time. Time is money.
So where do you get more information on how to work this magic?
You should definitely check out the small whitepaper on ISA Server 2006 Web Proxy. That’s the official name. Download the whitepaper at http://www.microsoft.com/isaserver/2006/prodinfo/Web_Proxywp.mspx. It’s about twenty pages and will give you some decent descriptions of the HTTP filtering process, SSL bridging, the event and alert models, proxy caching, etc.
Next, make sure to check the TechNet resources on your subscription or at the http://www.microsoft.com/technet/prodtechnol/isa/2006/beta.mspx location. This link will of course change when ISA Server 2006 ships and considering it’s already in release candidate status, that isn’t too far off.
By all means download the product and install it. See http://www.microsoft.com/isaserver/2006/beta.mspx for access to the release candidate bits. The Enterprise and Standard Editions are siting there begging you to try them. Don’t forget you can test a wide variety of scenarios using our Virtual PC or Virtual Server 2005 R2 products. Virtual Server 2005 R2 is free so what’s your excuse?
That’s not all !!!
Don’t want to download and install? Don’t!!! Go to http://www.microsoft.com/technet/traincert/virtuallab/isa.mspx and run the virtual labs to see how to do secure application publishing.
I agree with you that time is money and productivity can be increased using a solution like this. I would use it for some internal apps i would like to expose, but definitely not to some LoB apps which could expose my internal secrets.
IPSEC took its time to be trusted by the community, and even if there is easier ways to get connected, those ways will have to proof its credibility before being considered a replacement for it. That's why i don't think this would be a killer app for VPN..
Although, this is a very interesting improvement and solution to expose some non-critical apps, like expense reporting, project reporting, knowledge bases, etc...
I am quite concerned about the way things are moving with remote communication in all its aspects. It shows over the last few years that more and more vendors are adopting the approach to encapsulating all sorts of protocols in HTTP. Of course this is a very tempting solution, as HTTP in many cases is about the only protocol that is allowed to travel across a company’s firewall.
I remember a presentation on security, hosted by MS employees, were it was stated bluntly : don’t use VPN, it is a hole in your firewall, which is quite fair to me.
Now, I wonder what the advice would be from the MS security experts on protocols that are ported over HTTP. I try to understand what the risks could be, or why I should be rest assured that this is under control. The way I understand it is that there is no defence against malicious code, encapsulated in an HTTP protocol other than a very performant firewall with state of the art statefull inspection and even then, I am told, it still is risky business. On the why’s, I get various explanations that do not always comply with one another.
Now, I understand that this IPsec solution, offered by ISA2006, is pretty nice in terms of setting up a secure P2P connection without the hassle of a VPN client. But this is not the discussion. What to think about an employee, trying to access the OWA servers from a public computer : no VPN, no IPsec, just a certificate and a password. Once compromised, you can only but imagine what could go wrong. And in this case we are ‘talking’ HTTP, plain simple (for the firewall that is).
What if that employee tries to do RDP over HTTP or whatever other traffic that could be routed over HTTP. I am making to much fuzz out of nothing, or should we be careful in how we ‘adopt’ these new features?