Some more about Terminal Services Gateway Servers

In an earlier post, I mentioned Austin Osuide’s recent Windows Server User Group presentation on Terminal Services Gateway Server and what follows is some of the detail from that session.

Terminal Services Gateway Server is a server role in Windows Server 2008 – effectively a protocol translator that allows authorised users to remotely access resources on a corporate LAN using RDP over HTTPS.

Up until now, it’s been necessary to open TCP port 3389 to allow RDP traffic through the corporate firewall but by encapsulating the RDP traffic within an SSL-secured tunnel, control may be exercised over which computers (and hence which applications), users can connect to and from. Other advantages include the fact that there is no need for a VPN infrastructure, so connectivity can be gained from any PC, anywhere (home, hotel, business partner or client premises, mobile or wireless hotspot). Then there are other advantages for IT organisations looking to reduce costs…

Consider a large outsourcer, with many support teams, each supporting a single customer’s infrastructure. What if one team (with the appropriately scaled resources) could manage multiple networks? Maybe even in an offshore scenario? As an IT professional, I’m not keen on this and as a customer I would be concerned about the potential impact on security but what if my managers could convince the customer that they can maintain security in a global infrastructure such as this? Using technologies such as network access protection (NAP) the health of any connected devices can be ensured and terminal services gateway servers can be deployed to control who can connect to which computers – perhaps only to defined administrative servers with a controlled application set.

The process for connection is as follows:

  1. Client tunnel RDP connection through HTTPS.
  2. Terminal Services Gateway strips out the HTTPS encapsulation and forwards the request to the terminal server/remote desktop (if the request passes appropriate policy checks – connection authorisation policies control who can connect and resource authorisation policies control what they can connect to, using user-defined or built-in groups for servers).
  3. Remote machine beleives that the request has come directly from the client and responds appropriately.

It all sounds straightforward enough but, as Austin explained, there are some gotchas too:

  • As for when tunneling RPC through HTTPS with Outlook and Exchange, the certificate must be recognised as valid – there is no manual option to trust a site if there are certificate issues (as there would be when browsing the Internet). There are two possible options:
    1. Establish a corporate public key infrastructure and install the appropriate certificates on the client. The downside to this is where clients don’t allow certificates to be installed by users (e.g. in a kiosk scenario).
    2. Alternatively, purchase a certificate from a trusted certification authority.
  • At least initially, few organisations will have a PKI based on Windows Server 2008 and, due to the removal of the Xenroll ActiveX control from Windows Vista (see Microsoft knowledge base article 922706), Windows Vista and Windows Server 2008 computers cannot use the WIndows 2000/2003 CA web interface (or indeed the equivalent interfaces on the Thawte or Verisign websites). It should be possible to craft an appropriate web server certificate using the MMC Certificates snap-in, but the common name for the server needs to be fully qualified and the MMC tools insert an unqualified name in a computer certificate. Thankfully there is another method – using the certreq.exe command line tool and a .inf file with the certificate template information (the syntax is described in Microsoft knowledgebase article 321051 and certutil -csplist will list the trusted cryptographic service providers), for example:

    [Version]
    Signature="$Windows NT$

    [NewRequest]
    Subject = "CN=servername.domainname.tld"
    KeySpec = 1
    KeyLength = 2048
    Exportable = TRUE
    MachineKeySet = TRUE
    SMIME = False
    PrivateKeyArchive = FALSE
    UserProtected = FALSE
    UseExistingKeySet = FALSE
    ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
    ProviderType = 12
    RequestType = PKCS10
    KeyUsage = 0xa0

    [EnhancedKeyUsageExtension]
    OID=1.3.6.1.5.5.7.3.1

In terms of best practice, Austin had some more advice to give:

  • Use a dedicated Terminal Services Gateway Server.
  • Consider placing the gateway server behind an ISA server.
  • Terminate the SSL connection in the DMZ and put the Terminal Services Gateway Server on the corporate network
  • VPNs may still have a place in the infrastructure – Terminal Services gateway servers are best used where no local copy of the data is required or where bandwidth issues mean that the user experience over a VPN experience is poor.

Further information

Microsoft Terminal Services.
Microsoft Terminal Services team blog.
Terminal Services in the Windows Server 2008 Technical Library.

James May’s 20th Century

I’ve just spent an hour in front of the gogglebox watching James May’s 20th Century. “What’s that?”, you may ask. It’s a new BBC/Open University television programme looking at technology and how it’s changed the way in which we live over the last hundred-or-so years.

Tonight featured two episodes: the first looking at how the world became smaller with the development of air and motorised road travel and how, ironically, it was not supersonic aircraft travel that became the accepted means to “shrink” our planet but computers, fibre optics and the Internet; and the second looking at how the space race grew from one man’s dreams to a desire for military supremecy and eventually to a means to communicate (bit of a theme running here…) – I never realised just how many satellites are in orbit around the world.

Anyway, for UK readers with even the remotest interest in technology (and if you don’t have that, I’m surprised that you’re reading this blog), it’s fascinating viewing. Even my wife was interested, although as our toddler son is asking more and more “who?, “what?”, “when?” and “why?” questions this could be the science lesson that she needs in order to be able to keep up!

Why the banks just don’t get IT

Identity theft worries me. It doesn’t stop me sleeping at night but nevertheless it does worry me.

It seems that each time I log in to a banking website the security has been “enhanced” with yet another item that I fail to enter correctly and then have to call the helpdesk to get my account unlocked – and I’m an IT guy… what about the “normal” users (they probably write down the details somewhere)!

Mark James has written an interesting article about this issue – and how the answer is really quite simple – if only the banks would apply the same security approach to consumer banking as corporates do for remote access.

Security – Why the banks just don’t get IT

A few weeks back, I read a column in the IT trade press about my bank’s botched attempt to upgrade their website security and I realised that it’s not just me who thinks banks have got it all wrong…

You see, the banks are caught in a dilemma between providing convenient access for their customers and keeping it secure. That sounds reasonable enough until you consider that most casual Internet users are not too hot on security and so the banks have to dumb it down a bit.

Frankly, it amazes me that information like my mother’s maiden name, my date of birth, and the town where I was born are used for “security” – they are all publicly available details and if someone wanted to spoof my identity it would be pretty easy to get hold of them all!

But my bank is not alone in overdressing their (rather basic) security – one of their competitors recently “made some enhancements to [their] login process, ensuring [my] money is even safer”, resulting in what I can only describe as an unmitigated user experience nightmare.

First I have to remember a customer number (which can at least be stored in a cookie – not advisable on a shared-user PC) and, bizarrely, my last name (in case the customer number doesn’t uniquely identify me?). After supplying those details correctly, I’m presented with a screen similar to the one shown below:

Screenshot of ING Direct login screen

So what’s wrong with that? Well, for starters, I haven’t a clue what the last three digits of my oldest open account are so that anti-phishing question doesn’t work. Then, to avoid keystroke loggers, I have to click on the key pad buttons to enter the PIN and memorable date. That would be fair enough except that they are not in a logical order and they move around at every attempt to log in. This is more like an IQ test than a security screen (although the bank describes it as “simple”)!

I could continue with the anecdotal user experience disasters but I think I’ve probably got my point across by now. Paradoxically, the answer is quite simple and in daily use by many commercial organisations. Whilst banks are sticking with single factor (something you know) login credentials for their customers, companies often use multiple factor authentication for secure remote access by employees. I have a login ID and a token which generates a seemingly random (actually highly mathematical) 6 digit number that I combine with a PIN to access my company network. It’s easy and all it needs is knowledge of the website URL, my login ID and PIN (things that I know), together with physical access to my security token (something I have). For me, those things are easy to remember but for someone else to guess – practically impossible.

I suspect the reason that the banks have stuck with their security theatre is down to cost. So, would someone please remind me, how many billions did the UK high-street banks make in profit last year? And how much money is lost in identity theft every day? A few pounds for a token doesn’t seem too expensive to me. Failing that, why not make card readers a condition of access to online banking and use the Chip and PIN system with our bank cards?

[This post originally appeared on the Seriosoft blog, under the pseudonym Mark James.]

Windows Vista volume activation failure

When I upgraded my Vista installation from a (not-yet activated) copy of Windows Vista Business Edition to Windows Vista Enterprise Edition, the activation counter was reset to 30 days; however, since then it’s been bugging me with the following message

Volume activation has failed.

Your computer could not be activated.

Error:
0x8007232B
Description:
DNS name does not exist

Cryptic though the message is, it’s really quite simple – this is a volume licensed (Enterprise) copy of Windows Vista so it is looking for a key management server (KMS) to activate itself. I’m at home today, so it can’t find one but in any case, as I had not provided a product key during installation, Vista could not activate. Once I provided the appropriate multiple activation key (MAK), Vista was able to activate via the Microsoft servers.

It was interesting to see the changes in the system properties as activation took place. First the remaining time to activate dropped from 24 days (30 days minus the 6 since I upgraded the PC) to 5 days when the MAK was accepted. Then, once activation had completed successfully, Windows acknowledged that it was activated and genuine.

There’s more information about this error in Microsoft knowledge base article 938107 and Christian Mohn has blogged about a similar experience he had with Windows Vista Business Edition requiring the product key to be re-entered.

Open XML documents driving me insane on the Mac

A few weeks back, I wrote about how smart Office 2003 had been in detecting my need for an Office 2007 document converter and opening it for me. If only I could say the same for Office 2004 on the Mac. I’m all too familiar with Microsoft product groups working independently but the MacBU has excelled (excuse the pun) in its inability to ship a working document converter for the Open XML document formats more than seven months after the release of Office 2007 on Windows.

To make matters worse, Office 2008 for Mac (which uses the new file formats) is a closed beta so I can’t use that to convert/open the files.

Ironically, there are various reports of using an alternative office suite like OpenOffice or NeoOffice to open the files! Hmm… not such a smart business move for Microsoft then…

My Digital Life has information on the various options for working with Open XML in Office 2004 for Mac. Mac Mojo (the Mac Office team blog) has information about a beta converter for Word documents (only).