Scotty McLeod recently gave a presentation to the Windows Server UK User Group on Windows Server 2008 Server Core. I mentioned Server Core in a previous post but here’s some more on the subject, based on Scotty’s presentation (it’s also worth checking out Micheal Pietroforte’s post on Server Core essentials).

• Contrary to popular belief, Server Core still has a GUI. There is no Start Menu, no Explorer, no Internet Explorer (it is entirely command-line driven), but the logon screen is graphical and some GUI applications can be used (the latest beta includes an old version of notepad.exe that has very few dependencies and rundll.exe can be used to launch some GUI hooks). It is rumoured that, because some of the product teams didn’t follow Microsoft’s own application development rules, it’s too difficult to remove the GUI from Windows without breaking it completely.
• At present, the Server Core image is about 600MB in size – small enough to facilitate some interesting potential deployment scenarios – and, because of its small size, Server Core installs quickly.
• The number of supported roles for Server Core is growing quickly – that could be seen as a potential weakness but even so, the basic principle of providing a reduced attack service for common server scenarios still holds true. Interestingly, one of the roles (and potentially the most problematic of them all) is as an (IIS) web server – only for ISAPI/ASP applications (i.e. no .NET Framework – yet) but rumour has it that Apache will also run on Server Core and a cut-down IIS allows the installation of PHP for a Windows alternative to a LAMP web server (this lends itself to an unfortunate acronym though – WIMP – Windows, IIS, MySQL, PHP).
• Because there is no .NET Framework for Server Core at this time, there is no ability to run PowerShell scripts.
• After installation, Server Core has a blank administrator password. This must be changed at logon but can be changed to another blank password; however keeping it blank will prevent remote access to the server.
• Core server has huge potential, but still seems to be a little disjointed on the administration front (ironic, given what a huge improvement has been made in the full installation through the introduction of the Server Manager tool) – it seems that the recommended approach is to use a full Windows Server 2008 server as a management server for the various Core Server installations around the enterprise.

Scotty McLeod has been working hard to get the Windows Server User Group UK website off the existing SharePoint platform and onto something more appropriate (SharePoint is great for some things but it was not great for the user group website – hey, even SharePoint blogs uses Community Server! Come to think of it, so do most of the Microsoft blog sites!).

Anyway, head over to http://www.winserverteam.org.uk/. It’s still work in progress but, over the coming weeks and months, I’m hoping it will grow to become a lively discussion area (backed up with regular meetings) for UK-based IT Professionals who are interested in the development of the Windows Server platform.

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.

A few days back, I wrote a post looking forward to Windows Server 2008

It turns out that Microsoft also has published a Windows Server 2008 Technical Overview white paper that may be worth a read.