As an administrator, one of the things I really like to do is access my servers remotely - why travel to work when there's no need to, and how much nicer to just log in and fix the problem from home?
That's all fine in theory, but as we all know enabling remote access isn't something to be taken lightly, as it can introduce security problems if not implemented correctly. So, I'm going to take a look at Routing and Remote Access Services (RRAS) within Windows 2008 Server, to see what's new to help us fulfil our requirements for a safe and secure set of servers.
Virtual Private Networking (VPN) is one of the best known and most used forms of RRAS nowadays. A VPN can be used to enable home users to safely connect to servers at work, to effect connections between organisational sites within the same company and also between different companies.
Setting up a VPN requires a server with two network interfaces, one interface connected to the internet and the other to the local network.
As machines connect to the servers they receive IP addresses, either from a DHCP server or from the VPN server itself - you can choose what you want to happen there.
You should be aware, though, that if you have a DHCP server then the VPN server will grab IP addresses in groups of ten at a time (one for the RAS server interface and nine for its clients), so you'll need to think carefully about the size of allocation you make to the VPN server.
For a VPN to work, you need three components: a VPN client, which is any computer that runs an OS that supports PPTP, L2TP or IPSec; a VPN server; and a VPN tunnel through which they can communicate.
|Begin creating your VPN server by installing the Network Policy and Access Role in Windows Server 2008|
Obviously, the least secure area here is the VPN tunnel, so the various tunnelling protocols take care to encrypt all data that passes through the tunnel.
Windows Server 2008 comes with a new VPN tunnel called Secure Socket Tunneling Protocol (SSTP), which was introduced because many companies chose to block PPTP and L2TP/IPSec, for a variety of reasons.
Certainly, PPTP could never be regarded as totally secure, because while the link would eventually become secure the initial exchange of credentials between client and server was unencrypted, and the link became secure only after the credentials have been established.
This scheme was therefore somewhat open to attack and compromise. L2TP/IPSec did establish secure connection right from the start, but even so, many firewalls are routinely set up to not accept any connections from these protocols.
SSTP sends Point to Point Protocol (PPP) packets down the tunnel via the Secure Sockets Layer (SSL) channel used by HTTPS, thus offering a different routing scenario that may appeal to companies that don't use the other protocols.
The authentication method used by default in SSTP is Extensible Authentication Protocol (EAP) - which, of course, also works over L2TP/IPSec and PPTP - in the format of EAP-TLS (Transport Level Security). EAP can use other forms, but only TLS comes by default with Windows Server 2008.
Before you can even think about deploying a VPN setup you must first configure RRAS on a server, and before you can do that you need to add the Network Policy and Access Services role on the server. Network Policies are concerned with the security of your network and just how you handle client connections.
To this end, they're split into three sections - conditions, constraints and settings - and these all work hand-in-hand with one another.
Thus, you specify a connection condition, and if a client fulfils that condition then the settings you've specified will be applied to it, taking into consideration any constraints you might also have imposed.
There's a huge range of conditions to choose from (and you must have at least one in each policy). Some of them - such as HCAP - are specific to Cisco Network Admission Control, others to RADIUS Clients, still others to NAP, some are for time-of-day and many more than I have space for here. You'll find plenty of literature on the topic is available already.
Along with conditions come constraints, which work in areas such as time-of-day, session timeouts, idle timeouts, access media for clients via NAS port types and, of course, the called station ID metaphor of old where you set the telephone number of a dial-up server.
Although a client might satisfy the initial conditions you've set, the constraints also need to be satisfied before a complete connection can be made.
Settings is split into two parts that deal with the attributes for RADIUS and RRAS. In the case of RRAS this means looking at the number of connections, for example, and deciding what to do in order to ensure the RRAS servers don't get overloaded, or too much bandwidth consumed. You also get IPv4 and IPv6 filters to play with, as well as the ability to set up the encryption strength you want between client and server.
Once you've set up the Network Policy Server role, you can set about configuring your network policy. Start by running the Network Policy Server MMC from Administrative Tools.
Your first job is then is to make sure NPS is registered within Active Directory. You do that by right-clicking on NPS (Local) and selecting the fairly obvious menu option, "Register server in Active Directory".
Once that's happened, you can set about creating a new policy and giving it a meaningful name. You then select the type of network access server, which in this case would be "Remote Access Server (VPN Dial-Up)".
Now you set your conditions, and bearing in mind that you have to have at least one condition, the most obvious one to set would be the tunnel type that you're going to use.
Scroll down the list of conditions until you find Tunnel Type, and then check the boxes next to all the different tunnel types (PPTP, L2TP, and so on) that you're going to work with.
The next step is to set your access permissions for the selected tunnel types, which could be allow or deny. Then set up the authentication method you want to use (EAP, MS-CHAP-v2, and so on).
The next step is to sort out the constraints (idle timeout is an absolute necessity here) for this policy, and then the settings, which include an element I haven't covered as yet, namely Network Access Protection (NAP).
You can also set encryption type for the data here, Multilink and Bandwidth Application Protocol (BAP) settings, and more.
Once you've done that you get a chance to review all the settings you've made, and you can then hit the Finish button. The new network policy you've just created will be placed behind any existing policies, so if you want it to be actually processed when those clients come a'calling, make sure you move it up in the network policy list.
People who have set up VPNs under Windows Server 2003 will be familiar with the Network Access Quarantine Control. Windows Server 2008 uses a new feature called Network Access Protection (NAP) VPN, which pretty much works in the same way, but that Microsoft feels will be easier to work with and to roll out.
NAP is a sort of health service for your systems, which examines clients, for example, checking their patch status and the like. It can be used to restrict client access to server features until they're either manually or automatically brought up to the NAP specification requirements that you've set. NAP ships with Windows Vista, Windows XP SP3 and Windows Server 2008, so administrators will become very familiar with it.
Network Policy and Access Services (NPAS) in Windows Server 2008 provide you with all the tools you need to ensure safe connections in a wide range of areas, not just the RRAS features I've talked about here.
Apart from RRAS, it works with other members of the alphabet soup including HCAP, HRA, and the aforementioned NPS.
The process of creating a network policy is just as complicated as it's always been, but the tools to do it with now seem easier and clearer to work with in Windows Server 2008. I've barely scratched the surface of what can be done, but
I hope I've whetted your appetite enough to want to find out more. The more I look into Windows Server 2008, the more I like it, but it's still very early days in the lifetime of a server, so I'll not let myself get too carried away yet.