New Feature: RDP over SSL with Windows Server 2003 SP1

Release Candidate 2 for Windows Server 2003 SP1 is available to test from microsoft.com, which means RTM can’t be that far away!

A new feature in SP1 (at least, present in the RC2 build of SP1) that’s been causing some confusion is RDP over SSL – a new option for Terminal Services that should provide server authentication for TS sessions, preventing MITM (man in the middle) attacks while providing a new option for encryption.

Up front – RDP over SSL is not a firewall traversal technology. It doesn’t mean you’re using Web protocols to do RDP. To rephrase, it’s not “RDP over HTTP”, it’s “RDP with TLS authentication and encryption over TCP” – it still happens over TCP port 3389, as RDP usually does.

For the screenshot at left, I don’t have a server certificate installed on my test VM at the moment, but I’m told that when you do, the SSL options become available.

This led to a few questions on how you server publish RDP/SSL with ISA Server, and the answer is: Exactly as you’d publish RDP normally with an ISA Server – using Server Publishing (ISA 2000 version is here).

Essentially, ISA creates an opaque TCP connection between the client and the server, and the encryption and authentication occurs directly between client and server in a manner that ISA can’t inspect (except at the IP traffic level).

 

 

ISA 2004 Enterprise Edition hits RTM… (And why is that special?)

’nuff said! See http://www.microsoft.com/isaserver/ for more information.

March 1 is the general availability date, but there’s a trial CD available for order now. The trial download’s currently scheduled for March 1.

I’m still learning about the cool new stuff in Enterprise Edition, but if there’s something you’re specifically interested in, please feel free to ask!

[Update] OK, so the question was asked about what was actually new and improved in ISA 2004 (next time, I’ll just say “ask me in a week”).

What’s New And Different In Internet Security and Acceleration Server 2004 Enterprise Edition? And what does it mean?

  • Support for CARP arrays
    • near-linear scaling of cache size and performance, content is distributed across all array members
      • your cache size is increased by the size of the cache on each array member, rather than having N copies of the same content in each cache
  • Support for ADAM-based Configuration Storage Server(s)
    • schema extensions of Active Directory are no longer required
      • easier/less risk to deploy Arrays
    • can be resident on an ISA Array member, or on another computer – can be domain- or workgroup- based (and mixed and matched, at least to some extent)
      • can span AD organizational boundaries and still apply policy
  • Support for Enterprise and Array-level policy definition
    • Like ISA 2000, only, um, OK, a lot like ISA 2000 EE. But it’s in CSS now, so it’s better. Trust me*.
    • Set policy for multiple servers within an Array with Array policy
    • Set policy for multiple arrays within an Enterprise with Enterprise Policy
      • So: makes managing groups of servers easy
  • Integrated support for Network Load Balancing
    • Load balancing across NLB-enabled Array members
      • With monitoring of array members for easy failover
    • And BiDirectional Affinity
      • Allows a client to take a predictable “sticky” route in both directions through multiple load balanced interfaces (feature of WS2003).

More as I learn about it…

And This Morning, I Didn’t Like Podcasts

My experience to date with podcasting has been that I’d rather not, thank you. Nice that you’re excited about it, but bluntly, I have a problem not being able to visually skip content when someone’s talking about the weather, and when it sounds like they recorded the ‘cast using the paper-cup-and-string method.

I was pointed at the G’day World Aussie Podcast by a blogless (and so identityless) friend, who said I was mentioned (so how could I not try it?), and, well, I’m subscribing now. Cameron and Mick do an excellent job hosting, Frank was a very interesting interviewee, and the production values of the ‘cast were staggeringly good.

Recommended.

“Buttering” Onesself with MSN Search?

The verb form of “Google” seems to have become the commonly accepted form of “searching using Google”:

“I googled myself today…”, “I’m googling it…”, “Google me!”, “Go And Get Googled” (when someone asks a question verbally using only search terms – eg “Hey Tristan! ISA Web Publishing SSL?”)

I’ve (just today) switched my default Maxthon search service over to MSN Search, and I’m finding it’s definitely on the “good” side of usable, a marked improvement from even a month ago.

The dastardly, complex problem I’m having now is that while the word “Google” lends itself neatly to being verbified* (if nobody claims that word, it’s mine), “MSN Search” doesn’t.

As it’s “Better with the Butterfly”, I’m considering the following alternatives for the above:

  1. I butterflied myself today…
  2. I’m buttering it…
  3. Butter me up!
  4. Go And Cover Yourself In Butter, Then Ask Again
  5. Cholesterol This!

Got any better suggestions for a verbiated* form of MSN Search?

ISA 2004: Forms-Based Authentication and RADIUS

Forms-Based Authentication in ISA 2004 is a nifty new feature that emulates Exchange 2003’s FBA authentication option (and allows you to put it out front of OWA versions prior to 2003 – that is, you can use ISA 2004 to provide FBA authentication for Outlook Web Access from Exchange 2000 or Exchange 5.5).

We have a planning guide on how you can configure an OWA installation using ISA 2004 here. Key takeaways: the /exchange/ (OWA default) virtual directory needs Basic authentication enabled on it (so please, use SSL between ISA and the OWA server), and FBA should *not* be enabled at the Exchange level if you’re using it at the front end.

Dr Tom came up with an ingenious way around the limitation of a single advanced authentication type via what appears to be a single listener, so that you can have your kayak and heat it too. (If you’re searching for this post later, remember: the only post that had the words FBA, RADIUS and KAYAK in it).

But I’m not here to share that knowledge with you, I’m here to surreptitiously draw your attention to this KB article on adding RADIUS to the mix over here. (A while back I lost interest in trying to sneak the longest KB article title ever past the content team, but it looks like someone else has had a crack at it, with pretty successful results: “You cannot use the RADIUS authentication protocol when you use the Outlook Web Access (OWA) Forms-Based Authentication on a Web publishing rule to publish an internal Web site such as OWA in ISA Server 2004” – yes, that’s just the title (which I’ve requested be shortened to something like “Enabling FBA with RADIUS”.)

The short version of the article above is that by default, FBA expects ISA to be a member of a domain in order to authenticate user accounts. Once the hotfix above is applied, a registry setting becomes available that allows you to authenticate FBA requests using RADIUS, which means ISA can sit happily out front as a non-domain member. You can’t apply Windows group membership as the Firewall rules are being traversed (all we get back from RADIUS is a yes/no, not a user token containing group membership information), but when you consider you’re still allowing only pre-authenticated pre-authorized traffic via pre-defined paths, well, *shrug*.

You just configure your FBA rule, then set a registry key to enable RADIUS authentication for that rule: in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Proxy\Parameters , create a value called OwaAuthenticatesUsingRadius as a  Dword, and set the value to 1.

So, if the above sounds like something you’re interested in doing, go check out the guidance at the top, Tom’s bits, and then the KB article.

Questions? (You have 30 days to post ’em).

ISA 2004: Protocol Definitions can now have multiple primary ports

Just a quickie: As I’ve mentioned in passing a couple of times, when using ISA 2004 Protocol Definitions can have multiple primary ports – including ranges of primary ports – associated with them.

ISA 2000 was only able to use a single primary port per protocol definition, which quickly gets awkward when your ISP runs (say) their Enemy Territory servers on UDP 27961-27968, and you need to create an individual protocol definition per server to allow your SecureNAT clients to connect to them.

With 2004, you can create a single protocol definition spanning a range of ports, so you can simplify the ruleset for a routed or SecureNAT client while retaining basic control over the allowed protocols. It can also be useful for Server Publishing, if your application uses a range of inbound connection ports.

Of course, if you don’t want that much control, there’s the All IP Traffic option too…

ISA 2004: “All IP Traffic” really means it

With ISA 2000, while “All IP Traffic” rules were open slather for Firewall clients, they actually meant “All IP Traffic For Which I Have A Protocol Definition” for SecureNAT clients.

With ISA 2004, that’s no longer the case, it really means everything, so there’s no need to create loads of definitions for each port you need to use unless you’re locking it down to specific ports or ranges.

Application Filters are still used, though.

Aussies: Got Windows Skills? Want A Job?

JJ’s posted a bit about a role in our Platforms team, which is where I work. I thought I’d burble on for a little while on the sort of stuff we handle:

Platforms locally handle Windows itself, and most of the in-box and add-on technologies (like AD (inc GP), ADAM, ADS, CA, DNS, DHCP, FPS, RIS, WINS, IAS, RRAS, NLB, MSCS, TS + TSL, WM)  that come with it (excluding such notables as IIS, SMTP and Sharepoint, but we don’t always shoot you for knowing something about it – more knowledge == better), plus various other platform-level products (SMS, MOM, ISA, Virtual Server, Virtual PC (Windows), IE). We do tend to specialize, so you’re not expected to know everything about everything, just (some of everything) pretty well, and a little about the rest.

The job is primarily about troubleshooting. Lots of (quickly) learning how things (should) work, and why they sometimes don’t. Lots of support from really, really smart and/or experienced people around you.

Some level of basic development skill can be a plus (AD scripting with VB or JS leaps to mind), but you most likely won’t be asked to write any huge applications. Debugger skills are often useful. An understanding of Windows architecture at the big-picture level is mandatory, and the more detail you understand, the better.

So, if you have relatively broad and occasionally deep Windows skills, and are looking for a constant challenge, go check it out!

ISA 2004: Publishing a RADIUS Server

Newsgroup question: I don’t want ISA to actually do the RADIUS stuff, but I want to publish a RADIUS server (in Microsoft land, that’s called IAS – Internet Authentication Service – if you’re running Windows Server) behind ISA so that we can authenticate remote RADIUS clients.

Poking around through the ISA 2004 Protocol Definitions, there’s no RADIUS Server protocol out of the box. RADIUS client and Accounting protocols are included, but they’re not Server Publishing protocols – they’re defined as outbound.

Outbound Protocol Definition - Send then Receive

I’m going to assume that you’re using a server on an Internal network as the RADIUS Server, but this applies equally if it’s on any network that has a NAT relationship with the RADIUS clients (in this case, via an ISP, so they’ll be on the the External network). So if you have a screened subnet/DMZ that hosts the RADIUS server that also NATs to the Internet, this still applies.

Note the relationship from Internal to External is NAT

In a non-Routed relationship, we need to Server Publish a server to present it to our External clients, and to Server Publish, we’ll first need a set of Inbound protocol definitions for the job.

I made a couple to test with, and have exported them to an XML file – there’s one not shown here called “RADIUS Server – Conglomerated”, that contains both ports in a single server protocol definition, as in my experience most people just want to publish both ports. The other two do a single UDP port each. With ISA 2000, you’d absolutely need two protocol definitions and server publishing rules; 2004 is cooler.

Quick aside: with a Route relationship on a fully routed network, I’d usually suggest creating an Access Rule rather than a publishing rule, Source External, destination your RADIUS Server, protocol RADIUS (the default Outbound one, just in an inbound direction).

If you’re going to use this – and as a general best practice – please back up your configuration (right-click the topmost node in ISA management, and choose Back Up) before importing any definitions ever, so you can restore if something goes wrong. Just in case. No, I don’t anticipate a problem, but I won’t be held responsible either! Okay, just give me the file

Import Protocol

To import the definitions, you can use the Toolbox (right-click All Protocols, choose Import All, then pick the XML file), or a script like this one or, well, anything, really.

Once they’re there, just create a regular Server Publishing rule, pick RADIUS Server – Conglomerated as the protocol (or be more specific and use two rules if you’d like) and you’re done.

Completed Server Publishing Rule