Core Enhancements to Terminal Services

Windows Server 2008 has a number of core improvements in how Terminal Service works. Most of the improvements we’ll look at were first introduced in Windows Vista, but for some of these enhancements to work in Windows Vista you need Windows Server 2008 running on the back end as your terminal server. Many of these improvements center around changes to the Remote Desktop Connection client that comes with Windows Vista and Windows Server 2008, so let’s begin there. After that, we’ll look at some core changes on the server side that change some of the ways Terminal Services operates and that terminal server admins need to know about. Finally, we’ll briefly look at how to install Terminal Services, and then move on to other new features such as TS Gateway, TS Web Access, and TS RemoteApp.


Remote Desktop Connection 6.0
On previous versions of Windows, there were effectively two Terminal Services clients:
Remote Desktop Connection, a Win32 client application that is the “full” Terminal

Services client and is included in Windows XP and Windows Server 2003. You could also download a version of this client (msrdpcli.exe) that could be installed on earlier Windows versions to provide similar functionality.

Remote Desktop Web Connection, an ActiveX control you could download from a Web page running on IIS and then use to connect over the Internet to a terminal server. Remote Desktop Web Connection has slightly less functionality than the full Terminal Services client but is easy to deploy-just download it using a Web browser and you can open a Terminal Services session within your Web browser.

Starting with Windows Vista, however (and in Windows Server 2008 too), this ActiveX control has been integrated into the Remote Desktop Connection client, so there is only one client now and users don’t have to download anything to access terminal servers over the Internet. This is good because some organizations might have security policies in place that prevent users from downloading ActiveX controls onto their client machines.

This new version 6.0 client (which is also available for Windows XP Service Pack 2-see article 925876 in the Microsoft Knowledge Base for more info) provides a number of significant improvements in the areas of user experience and security.


Network Level Authentication and Server Authentication
Remote Desktop Connection 6.0 (RDC 6.0) supports Network Level Authentication (NLA), a new authentication method that authenticates the user, the client machine, and server credentials against each other. This means client authentication is now performed before a Terminal Services session is even spun up and the user is presented with a logon screen. With previous RDC clients, the Terminal Services session is started as soon as the user clicks Connect, and this can create a window of opportunity for malicious users to perform denial of services attacks or steal credentials via man-in-the-middle attacks.

To configure NLA, open the System item from Control Panel, click Remote Settings, and select the third option.

The other security enhancement in RDP 6.0 is Server Authentication, which uses Transport Layer Security (TLS) and enables clients to be sure that they are connecting to the legitimate terminal server and not some rogue server masquerading as the legitimate one. To ensure Server Authentication is used on the client side, open RDC and on the Advanced tab select the Don’t Connect If Authentication Fails (Most Secure) setting from the drop-down list box (the default setting is Warn Me If Authentication Fails).

You can also configure Server Authentication using the Terminal Services Configuration snap-in. Using Network Level Authentication together with Server Authentication can help reduce the threat of denial of service attacks and man-in-the-middle attacks.


Display Improvements
RDC 6.0 also provides users with a considerably enhanced user experience in the area of display improvements. For one thing, Terminal Services sessions now support a maximum display resolution of 4096 × 2048. And although before only 4:3 display resolution ratios were supported, now you can define custom resolutions like 16:9 or 16:10 to get the more cinematic experience supported by today’s wide-screen monitors. Setting a custom resolution can be done from the RDC UI or by editing a saved .rdp file using Notepad or by starting RDC from a command line using switches-that is, typing mstsc /w:width /h:height at a command prompt.

Another display improvement is support for spanned monitors-that is, spreading the display across multiple monitors. Note that to do this you have to make sure that all your monitors have the same resolution configured and their total resolution doesn’t exceed 4096 × 2048. Additionally, you can span monitors only horizontally, not vertically (better for the neck, actually) using the /span switch.

A third display improvement is that RDC now supports full 32-bit color depth, which means that users can now experience maximum color quality when running applications in Terminal Services sessions. Personally, I can’t tell the difference between True Color (24-bit) and Highest Quality (32-bit), but I suppose someone who works with Photoshop can quickly notice the difference. To get 32-bit color, you need to configure it both on the client (on the Display tab of the RDC properties) and on the terminal server, which must be running Windows Server 2008. Or you can configure 32-bit color from the server by opening the Terminal Services Configuration snap-in and double-clicking on the RDP connection you want to configure (like the default RDP-Tcp connection). Then switch to the Client Settings tab of the connection’s properties dialog box and change the color depth to 32 bits per pixel. In fact, 32-bit color is now the default; this is because for typical higher-color applications, such as IE and PowerPoint, the new compression engine in RDP6 typically sends less data over the network in 32-bit color mode rather than in 24-bit color mode. If you need high color you should consider 15-bit, 16-bit, and 32-bit color before you consider 24-bit.

Yet another display enhancement is support for ClearType in Terminal Services sessions. This feature of RDC 6.0 is known as font smoothing because it makes the fonts of displayed text a lot easier to read. You can enable this on RDC by selecting the Font Smoothing check box on the Experience tab.

To ensure font smoothing is enabled on the server side of your Windows Server 2008 terminal server, open Appearance And Personalization from Control Panel, click Personalization, click Windows Color And Appearance, click Effects, and make sure ClearType is selected.

Source of Information : Introducing Windows Server 2008

Terminal Services RemoteApp

One of the biggest improvements and enhancements of Terminal Services in Windows Server 2008 is in the area of experience features, Terminal Services RemoteApp, which enables users to access standard Windows-based programs from anywhere by running them on a terminal server instead of directly on their client computers. In previous versions of Terminal Services, you could remote only the entire desktop to users’ computers. So when a user wanted to run a program remotely on the terminal server, she typically double-clicked on a saved .rdp file that the administrator previously distributed to her. This connected her to the terminal server, and after logging in (or being automatically logged in using saved credentials), a remote desktop would appear on her computer with a pin at the top pinning the remote desktop to her local (physical) desktop. The user could then run applications remotely on the terminal server from within her remote desktop, or she could minimize the remote desktop if she wanted to run applications on her local computer using her physical desktop.

TS RemoteApp solves this problem (and makes the lives of harried help desk staff easier) by allowing users to run Terminal Services applications directly on their physical desktop. So instead of having to switch between two desktops, the user sees the RemoteApp program (the program that is running remotely on the terminal server instead of on her local computer) sitting right there on her desktop, looking just like any other locally running program.


Using TS RemoteApp
First, we’ll open Server Manager and select the TS RemoteApp Manager node under Terminal Services. (We could also open TS RemoteApp Manager from Administrative Tools.)

TS RemoteApp Manager lets us specify which programs our Terminal Services users will be able to run remotely on their normal desktops. Right now, we have no programs on the Allow list, so let’s click Add RemoteApp in the Action pane at the right. This launches the RemoteApp Wizard. Clicking Next presents us with a page that allows us to choose which installed programs we want to add to the RemoteApp programs list. We’ll choose Paint.

Clicking Next and then Finish causes Paint to be added to the RemoteApp programs list with default settings.

If we select Paint in the center (Details) pane and click Properties in the Action pane, we see the default settings for running this RemoteApp program:

What these default settings indicate are that users will not be allowed to add their own command-line arguments when running Paint. (This is usually a good idea, though as far as I know, Paint doesn’t have any command-line switches.) The settings also indicate that the RemoteApp program will automatically be made available to users through Terminal Services Web Access (though we actually haven’t added that role service yet to our terminal server). In addition, we could change the name of the RemoteApp program to something other than “Paint” if we want users to know that they’re running the RemoteApp version of the program and not the version installed on their local computer.

Once we’ve added Paint to the RemoteApp programs list, how do we actually enable the user to run the RemoteApp program? To do this, we need to deploy a package containing the RemoteApp information for Paint to our users. We can package our RemoteApp program in two ways: as a Windows Installer file or as a Remote Desktop Protocol file. Let’s use the Windows Installer file approach because as administrators we’re used to deploying Windows Installer packages to client computers using Group Policy.

Start by selecting Paint in our RemoteApp programs list, and then click Create Windows Installer Package in the Action pane. This starts the RemoteApp Wizard again, but after you click Next the wizard displays the following page instead of the previous one:

By default, we see that our Windows Installer package (which will actually be created with the extension .rap.msi, with RAP presumably standing for RemoteApp Package) will be saved at C:\Program Files\Packaged Programs. We could elect to save it there, or we could save it on a network share instead, which is likely the better choice. This page of the wizard also lets us customize the terminal server settings (server name, port, and authentication settings), specify that the package is digitally signed to prevent tampering, or specify Terminal Services Gateway settings if we’re using this feature.

Accepting the default and clicking Next brings us to this wizard page:

Note that by default the RemoteApp program is going to be added to the user’s Start menu in a folder named RemoteApps. (We’ll see that in a moment.) By selecting the check box at the bottom of this page, we can also cause the RemoteApp program to launch whenever the user double-clicks on a file extension like .bmp that is associated with the program. Click through now to finish the wizard.

Now we just need to deploy the .rap.msi package by using Group Policy. After the package has been installed on these computers, now when the user clicks Start and then Programs, the RemoteApp program can be seen on the Start menu:

Now we select Paint under RemoteApp, and the following appears:

We’re also prompted for our user credentials because it’s the first time we’re running this RemoteApp program from our terminal server.

Once the RemoteApp is running, if we also start a copy of Paint locally from Accessories, then we’ve we had two copies of Paint running.

One more thing-what if we did have the Desktop Experience feature installed on our terminal server? In that case, both copies of Paint on our desktop would look identical. How could we tell then whether or not we’re using TS RemoteApp to run one of these copies? Try Task Manager-opening Task Manager displays the two copies of Paint that are running:

Notice that the remote version of Paint is clearly marked this way. Now right-click on the remote Paint application and select Go To Process. The Process tab now opens, and we see that mstsc.exe (in other words, RDC 6.0) is the actual process hosting our remote copy of Paint:


Benefits of TS RemoteApp
Now that we’ve examined the new RemoteApp feature of Terminal Services in Windows Server 2008, what do you think the benefits are? Several come to my mind:

• No more user confusion over why they need to have two desktops instead of one. And that’s not to forget the gratitude your help desk staff will have for you.

• A great new method for easily deploying new applications to users-that is, using small (generally less than 100-KB) .rap.msi files deployed using Group Policy software distribution.

• Less work for you as administrator because you no longer have to configure entire remote desktops for users but only RemoteApp programs, and this you can easily do using a wizard.

• No more getting caught up in the argument of whether Terminal Services is for rich clients or thin clients-RDP 6.0 together with RemoteApp makes every client rich.

What are some best practices for using TS RemoteApp? Well first, if you have some programs that are intended to work together-that is, they share data by embedding or linking using DDE-it’s a good idea to run these RemoteApp programs from the same terminal server instead of dividing the programs up onto different terminal servers. That way, the experience for users will be enhanced, and they will see better integration between different programs when they run them. And second, you should put different programs on different terminal servers if you have application compatibility issues between several programs or if you have a single heavy-use application that could result in users filling the capacity of one of your terminal servers. (Use the x64 architecture instead of x86, however, if you want much greater capacity for your terminal servers.)

Source of Information : Introducing Windows Server 2008

TS Gateway, ISA Server, and NAP Working Better Together

Terminal Services–based remote access has long been used as a simpler, lower-risk alternative to classical layer 2 VPN technologies. Whereas the layer 2 VPN has often provided “all ports, all protocols” access to an organization’s internal network, the Terminal Services approach restricts connectivity to a single well-defined port and protocol. However, as more and more capability has ascended the stack into RDP (such as copy/paste and drive redirection), the potential attack vectors have risen as well. For example, a remote drive made available over RDP can present the same kinds of security risks as one mapped over native CIFS/SMB transports.

With the advent of TS Gateway, allowing workers to be productive from anywhere has never been easier. TS Gateway also includes several powerful security capabilities to make this access secure. In addition to its default encryption and authentication capabilities, TS Gateway can be combined with ISA Server and Network Access Protection to provide a secure, manageable access method all the way from the client, through the perimeter network, to the endpoint terminal server. Combining these technologies allows an organization to reap the benefits of rich RDP-based remote access, while mitigating the potential exposure this access can bring.

ISA Server adds two primary security capabilities to the TS Gateway solution. First, because it can act as an SSL terminator, it allows for more secure placement of TS Gateway servers. Because ISA can be the Internet-facing endpoint for SSL traffic, the TS Gateway itself does not need to be placed within the perimeter network. Instead, the TS Gateway can be kept on the internal network and the ISA Server can forward traffic to it. However, if ISA were simply performing traffic forwarding, it would be of little real security benefit. Thus, the second main security value ISA brings to the solution is pre-authentication capabilities. Rather than simply terminating SSL traffic and forwarding frames on to the TS Gateway, ISA authenticates users before they ever contact the TS Gateway, ensuring that only valid users are able to communicate with it. Using ISA as the SSL endpoint and traffic inspection device allows for better placement of TS Gateway resources and ensures that they receive only inspected, clean traffic from the Internet.

Although ISA Server provides important network protection abilities to a TS Gateway solution, it does not address client-side threats. For example, users connecting to a TS Gateway session might have malicious software running on their machines or be non-compliant with the organization’s security policy. To mitigate against these threats, TS Gateway can be integrated with Network Access Protection to provide enforcement of security and healthy policies on these remote machines.

NAP is included in Windows Server 2008 and can be run on the same machine as TS Gateway, or TS Gateway can be configured to use an existing NAP infrastructure running elsewhere. When combined with TS Gateway, NAP provides the same policy-based approach to client health and enforcement as it does on normal (not RDP-based) network connections. Specifically, NAP can control access to a TS Gateway based on a client’s security update, antivirus, and firewall status. For example, if you choose to enable redirected drives on your terminal servers, you might require that clients have antivirus software running and up to date. NAP allows organizations to ensure that computers connecting to a TS Gateway are healthy and compliant with its security policies.

Source of Information : Introducing Windows Server 2008

Windows Server 2008 Terminal Services Gateway

Another new feature of Windows Server 2008 is Terminal Services Gateway (or TS Gateway), which is designed to provide authorized users with secure, encrypted access over the Internet to terminal servers on your internal corpnet. In other words, a salesperson arriving at a hotel in Hong Kong could open his Windows Vista laptop to bring it out of sleep mode, connect to the Internet using a hot spot in the lobby, and launch a RemoteApp program on his machine that actually runs far away on a Terminal Server hidden behind your company’s perimeter firewall at headquarters in New York. Or, depending on how your administrator has defined its resource authorization policies, the user might be able to access the remote desktop of his own desktop computer in New York, provided Remote Desktop has been enabled on it. And if the remote user is an administrator, he could access the remote desktop of any servers within his internal corpnet (provided Remote Desktop is enabled on them) and securely manage those servers and do whatever tasks he needs to perform on them.

And you can do all this without having to use a virtual private network (VPN) connection. Plus this will work regardless of the type of perimeter firewall your company has set up, or even if your business is using Network Address Translation (NAT). All it takes to make all this work is that your perimeter firewall has to allow TCP port 443 so that HTTP SSL traffic can pass through from the outside.

TS Gateway works by enabling tunneling of RDP traffic over HTTPS (HTTP with SSL encryption). The client computer at the left is attempting to connect to the terminal servers at the right that are hidden behind a pair of firewalls with a perimeter network subnet in between them. The TS Gateway is sitting between the firewalls on the screened subnet, and when the incoming RDP over HTTP traffic reaches the external firewall, the firewall strips off the HTTP part and passes the RDP packets to the TS Gateway. The TS Gateway can then use the Network Policy Server to verify whether the user is allowed to connect to the terminal server, and will use Active Directory to authenticate the remote user. Once the user is authenticated, she can access the internal terminal servers and run RemoteApp programs .

TS Gateway will support NAP so that when a remote client computer tries to connect to a terminal server on your internal corpnet, the remote client first has to undergo the required health check to make sure it has the latest security updates installed, has an up-to-date antivirus signature, has its host firewall enabled, and so on. After all, you don’t want unhealthy (read: infected with worms and other malware) remote computers to be able to connect to your internal terminal servers and infect your whole network! One thing to note, however, is that NAP will not be able to perform remediation for unhealthy clients connecting through TS Gateway-it simply blocks them from accessing your internal terminal servers. In addition, device redirection is blocked for remote clients connecting via TS Gateway (though best practice is actually to block such redirection on your terminal servers and not on your TS Gateway).

An alternative to placing your TS Gateway on the perimeter network is to put it on your corpnet-that is, behind your internal firewall. Then place an SSL terminator in your perimeter network to forward incoming RDP traffic securely to your TS Gateway. Either way you implement this, however, one advantage of this new feature is that you don’t need to worry about using an SSL VPN any longer and all the headaches associated with getting this working properly.

This integration with Network Access Protection (NAP) is an important aspect of TS Gateway because many mid- and large-sized organizations that will deploy Windows Server 2008 will probably do so because of NAP (and also, of course, because of the many enhancements in Terminal Services on the new platform).


Implementing TS Gateway
Implementing TS Gateway on a server running Windows Server 2008 requires that you add the TS Gateway role service for the Terminal Services role. When you do this using Server Manager, you are prompted to add the following roles and features as well (if they are not already installed):
• Network Policy and Access Server role (specifically, the Network Policy Server role services)
• Web Server (IIS) role (plus various role services and components)
• RPC Over HTTP Proxy feature

Note that for smaller environments, it’s all right to install TS Gateway and the Network Policy Server (NPS) on the same Windows Server 2008 machine. Larger enterprises, however, will probably want to separate these two different role services for greater isolation and manageability.

Adding the TS Gateway role service also requires that you specify a server certificate for your server so that it can use SSL to encrypt network traffic with Terminal Services clients. A valid digital certificate is required for TS Gateway to work, and you have the choice during installation of this role to import a certificate (for example, a certificate from VeriSign if you want clients to be able to access terminal servers running on your corpnet from anywhere in the world via the Internet), create a self-signed certificate (good for testing purposes), or delay installing a certificate until later:

After importing a certificate for your server, you’re given the option of creating authorization policies now or doing so later using the TS Gateway Management console. There are two kinds of authorization policies you need to create:
• Connection authorization policies These are policies that enable remote users to access your network based on conditions you have specified.
• Resource authorization policies These are policies that grant access to your terminal servers only to users whom you have specified.

Finally, the Add Role Services Wizard indicates which additional roles and role services will be installed for the Network Policy and Access Server and Web Server (IIS) roles (if these roles and role services are not installed already). And finally you’re done.

Once your TS Gateway is set up, you can configure it by creating additional connections and resource authorization policies. For example, you could create a resource authorization policy (RAP) to specify a group of terminal servers on your internal corpnet that you want the TS Gateway to allow access to by authorized remote clients:

When you create and configure connection authorization policies, you specify which security groups of users they apply to and, optionally, which groups of computers as well. You also specify whether authorization will use smart cards, passwords, or both. When you create and configure resource groups, you define a collection of resources (for example, terminal servers) that remote users will be allowed to access. You can specify these resources either by selecting a security group that contains the computer accounts of these computers, by specifying individual computers using their names (hostname or FQDN) or IP addresses, or by allowing remote users to access any computer (client or server) on your internal network that has Remote Desktop enabled on it. You need to create both connection and resource authorization policies for TS Gateway to do its job.

Finally, the Monitoring node in the TS Gateway Management console lets you monitor connections happening through your TS Gateway and disconnect them if needed.


Benefits of TS Gateway
Why is TS Gateway a great feature? It gives your users remote access to fully firewalled terminal servers on your corpnet, and it does so without any of the headache of having to configure a VPN connection to those servers. That’s not to say that VPNs aren’t still useful, but if users don’t need a local copy of data, network bandwidth is limited, or the amount of application data that needs to be transferred is large, you’ll likely get better performance out of using TS Gateway than trying to let your users VPN into your corpnet to access your terminal servers.

Best practices for deploying this feature? Use a dedicated TS Gateway (it can coexist with Outlook RPC/HTTP), and consider placing it behind Microsoft Internet and Acceleration Server (ISA) rather than using a simple port-based firewall.

Source of Information : Introducing Windows Server 2008

Running Licensing Diagnosis on a Terminal Server

The Licensing Diagnosis tool is now integrated into the Terminal Services Configuration MMC snap-in (TSConfig.msc). This tool on the terminal server, in conjunction with the TS Licensing Manager’s Review Configuration option on the License Server, can be useful in finding problems arising because of a misconfigured TS Licensing setup. The Diagnostic tool does not report all possible problems in all possible scenarios during diagnosis. However, it collates the entire TS Licensing information of Terminal Services and the License Servers at a single place and identifies common licensing configuration errors.

Upon launch of the Licensing Diagnosis tool, it first makes up a list of License Servers that the terminal server can discover via auto-discovery and also those that can be discovered via manual specification by using either the Use The Specified License Servers option in TSConfig.msc (registry-by-pass) or the Use The Specified Terminal Services License Servers Group Policy. It then contacts each License Server in turn to gather its configuration details, such as the activation state, License Key Pack information, relevant Group Policies, and so on. For this to work properly, we need to make sure that the Licensing Diagnosis tool has been launched with credentials that have administrator privileges on the License Servers. If needed, use the Provide Credentials option to specify appropriate credentials for each License Server individually at run time. Then the terminal server’s licensing settings-such as the licensing mode, Group Policies, and so on- are analyzed and compared, together with the License Servers information, to summarize common TS Licensing problems. A summary of diagnostic messages, with the possible resolution steps, is provided by this tool at the end of diagnosis.

We can understand how the tool can be used by considering some sample scenarios.

The terminal server has just been set up, and the licensing mode of the server has remained in Not Yet Configured mode. No other Licensing settings have been done on the TS, and a License Server has not been set up. Within the grace period of 120 days, TS has allowed connection to clients.

Past the grace period, the administrator observes that the clients are no longer able to connect. The administrator launches the diagnostic tool and finds that two diagnostic messages are reported. One message is that the TS mode needs to be configured to either Per-User or Per-Device mode, and the other is that no License Servers have been discovered on the terminal server. The administrator now sets the TS licensing mode to Per-Device mode using TSConfig.msc. (If the TS licensing mode is set up using the Set The Terminal Services Licensing Mode Group Policy, the Licensing tab in TSConfig.msc is disabled.) A License Server is also set up by the administrator in the domain. When rerunning the tool, it now reports that the License Server needs to be activated and License Key Packs of the required TS mode need to be installed on the License Server. And so on.

Case 2: Advanced Diagnosis Cases
The Terminal Services License Server Security Group Policy has been enforced on the domain. The administrator has not added the TS computer name into the Terminal Server Computers local group on the License Server. When the Licensing Diagnosis tool is launched, it displays a diagnostic message indicating that licenses cannot be issued to the given terminal server because of the Group Policy setting. This can be corrected by using the Review Configuration option in TS Licensing Manager to create the TSC group, and TS can be added to the group using the Local Users And Groups MMC snap-in.
If the License Server computer name is not a member of the Terminal Server License Servers local group in the Active Directory Domain Controller of the TS’s domain, peruser licensing and per-user license reporting will not work. In such case, when the Licensing Diagnosis tool is opened on TS, the Per-User Reporting And Tracking field in the License Server Configuration Details panel indicates that per-user tracking is not available. This can be corrected by using the Review Configuration option in TS Licensing Manager to add the License Server computer name into the Terminal Server License Servers group.

Case 3: License Server Discovery Diagnosis on the Terminal Server
During License Server setup, the administrator selected to install the License Server in the Forest Discovery Scope. But as the administrator ran the installation without the required Active Directory privileges, the License Server did not get published in the Active Directory licensing object. When the Licensing Diagnosis tool is launched on the TS, it is unable to discover the License Server. For diagnosing discovery problems, the administrator can initially specify the License Server by manually configuring it in the Use The Specified License Servers option in TSConfig.msc so that the License Server shows up in the diagnostic tool. When rerunning the Licensing Diagnosis tool, the administrator notices that the License Server’s discovery scope is visible in the License Server Configuration Details section. The discovery scope shows up as Domain Scope, instead of Forest Scope. This can be corrected by using the Review Configuration option in TS Licensing Manager and exercising the Change Scope option to set the License Server discovery scope to Forest Scope.

Case 4: Licensing Mode Mismatch Diagnosis
The terminal server is configured in Per-Device licensing mode, but the administrator has installed Per-User licenses on the License Server. On launching the Licensing Diagnosis tool, a diagnostic message shows that the appropriate type of licenses are not installed on the License Server, indicating a potential mode mismatch problem.

Source of Information : Introducing Windows Server 2008

CAL Revocation on Terminal Services License Server

CAL Revocation is supported only for Windows Server 2008 TS Per-Device CALs. Terminal Services License Server’s automatic CAL reclamation mentioned later in this sidebar applies only to Per Device CALs.

Per-Device CALs are issued to clients for a certain validity period, after which the CAL expires. If the client accesses the terminal server often, the validity of the CAL is renewed accordingly before its expiration. If the client does not access the terminal server for a long time, the CAL eventually expires. The Terminal Services License Server reclaims all the expired CALs periodically with its automatic CAL reclamation mechanism.

Occasionally, an administrator might need to transfer a Per-Device CAL from the client back into the free license pool on the License Server (a process referred to as reclaiming or revoking) when the original client has been permanently removed from the environment and one needs to reallocate the CAL to a different client. Historically, there was no way to do it. An administrator would have had to wait until the CAL expired or lost its validity and was automatically reclaimed by its mechanism. So it was desired to have the License Server support a mechanism to reclaim or revoke CALs.

Using the new Revoke CAL option in TS Licensing Manager, administrators can now reclaim issued CALs and place them back into a free license pool on the License Server. An administrator has to also select the specific client whose CAL needs to be revoked.

But there are certain restrictions on the number of CALs that can be revoked at a given time. This is a restriction imposed by the License Server to prevent misuse. The restriction can be stated as follows: At any given point in time, the number of LH PD CALs in a revoked state cannot exceed 20 percent of the total number of LH PD CALs installed on the License Server. A CAL goes into a revoked state right after revocation, and its state is cleared when it goes past its original expiration date. One can see the list of CALs in the revoked state in the TS Licensing Manager tool by observing the Status column in the client list view. When the administrator has exceeded this limit, he is given a date when further revocation is possible.

Note that TS CALs should not be revoked to affect concurrent licensing. TS CALs can only be revoked when it is reasonable to assume that the machine they were issued to will no longer participate in the environment, for example, when the machine failed. Client machines, no matter how infrequently they may connect, are required to have a TS CAL at all times. This also applies for per user licensing.

Source of Information : Introducing Windows Server 2008

Windows Server 2008 Terminal Services Licensing

Let’s move on and talk briefly about Terminal Services Licensing (or TS Licensing) and also hear from more of our experts on the Terminal Services team at Microsoft. The job of TS Licensing is to simplify the task of managing Terminal Services Client Access Licenses (TS CALs). In other words, TS Licensing helps you ensure your TS clients are \ properly licensed and that you aren’t purchasing too many (or too few) licenses. TS Licensing manages clients that are unlicensed, temporarily licensed, and client-access (that is, permanent) licensed clients, and it manages licenses for both devices and users that are connecting to your terminal servers. The TS Licensing role service in Windows Server 2008 supports terminal servers that run both Windows Server 2008 and Windows Server 2003.

Device-based TS Licensing basically works like this: When a client tries to connect to a terminal server, the terminal server first determines whether the client requires a license (a TS CAL). If the client requires a license, the terminal server contacts your TS Licensing server (usually a separate machine, but for small environments this could also be the terminal server) and requests a license token, which it then forwards to the client. Meanwhile, the TS Licensing server keeps track of all the license tokens you’ve installed on it to ensure your environment complies with licensing requirements. Note that if a client requires a permanent license token, your TS Licensing server must be activated. (Nonactivated TS Licensing servers can issue only temporary tokens.)

A new feature of TS Licensing in Windows Server 2008 is its ability to track issuance of TS Per-User CALs. If your terminal server is configured to use Per-User licensing mode, any user attempting to connect to it must have a TS Per-User CAL. If the user doesn’t, the terminal server will contact the license server to obtain a CAL for her, and administrators can track the issuance of these CALs by using the TS Licensing management tool. Note that TS Per-User CAL tracking and reporting requires an Active Directory infrastructure.


Configuring Terminal Server License Server After Installation
TS Licensing Manager, the admin console for Terminal Server License Server, can now find configuration-related issues with a Terminal Server License Server. It displays the License Server configuration status under a new column, Configuration, in the list view. If there are some issues with the License Server configuration, the configuration status will be set to Review.

TS Licensing Manager also allows the admin to view the current License Server configuration settings in detail. The admin can choose Review Configuration from the right-click menu for a License Server, which opens the configuration dialog. The License Server configuration dialog displays the following information:

• TS License Server Database Path

• Current scope for the license server

• Membership of the Terminal Server License Server group at the Active Directory Domain Controller. During installation of the TS Licensing role on a domain machine, the setup tries to add the License Server in the Terminal Server License Server group at the Active Directory Domain controller, for which it requires domain administrator privileges. Membership to this group enables the License Server to track Per-User license usage.

• Status of the global policy License Server Security Group (TSLS). If this policy is enabled and the Terminal Server Computers group is not created, a warning message will be displayed. If the policy is disabled, no message/status will be displayed. Admins can take corrective actions if some License Server configuration issues are found. The License Server configuration dialog allows an administrator to take the following actions:

• Change the License Server scope.

• If the License Server scope is set to Forest and the License Server is not published in Active Directory, the License Server configuration dialog shows a warning message to the administrator and allows the administrator to publish the License Server in Active Directory.

• Add to the TSLS group in AD.

• If the License Server Security Group Group Policy is enabled and the Terminal Server Computers local group is not created, the License Server configuration dialog displays the warning message and allows the administrator to create the Terminal Server Computers local group on the License Server.

Source of Information : Introducing Windows Server 2008

Understanding the Administration of Virtual Guest Sessions

One question that comes up frequently from administrators implementing virtual environments for the first time is how one administers a virtual server. For years, we have just walked up to a server that has a keyboard, mouse, and monitor and worked on “that system.” Having a different mouse, keyboard, and monitor for each system is simple; we know which devices go to which server that is running a specific application. With virtualization, however, guest sessions do not have their own mouse, keyboard, or monitor. So, how do you administer the system?

Many organizations have already been working off of centralized mice, keyboards, and monitors by using switchboxes that allow 4, 8, 16, or more servers to all plug into a single physical mouse, keyboard, and monitor. Simply by pushing a button on the switchbox, or using a command sequence, the administrator “toggles” between the servers. Administration of virtual servers works the exact same way. An administrator utility is loaded, and that utility enables administrators to open multiple virtual server sessions on their screen. Various tools and strategies, including the following, enable you to administer virtual systems:

• Using the Hyper-V Administration tool
• Using the System Center VMM tool
• Using Terminal Services for remote administration

The various administration options provide different levels of support to the management of the virtual guest sessions on Hyper-V.


Management Using the Hyper-V Administration Tool
The built-in Hyper-V Administration tool provides basic functions such as starting and stopping guest images, pausing guest images, forcing a shutdown of guest images, immediately turning off guest images, and the ability to snapshot images for a configuration state at a given time.

In most environments, the administrator would set a guest image to automatically start as soon as the host server itself has been started. That way, if the server is rebooted, the appropriate guest images are also started (but like if a physical server lost power and rebooted when the power came back on).

For images that have been set to be off after the host server reboot, those images can be manually started from the Hyper-V Administration tool. The manual start of images is common for servers that are hosting test images, images used for demonstration purposes, and copies of images that can be manually started when a specific server is required (that is, cold standby server startup).


Management Using the Virtual Machine Manager 2008 Tool
Organizations that want more than just starting and stopping guest images should consider buying and implementing the System Center Virtual Machine Manager 2008 (VMM) tool. VMM provides basic information about whether a guest image has been started or not, and it provides more information than the built-in Hyper-V Administration tool in terms of how much memory and disk space each image is taking on the host server. The VMM 2008 tool has several wizards and functions that allow an administrator to capture physical server information and bring the server configuration into a virtual image. VMM 2008 can also extract an image from another virtual server and bring that information into a new Hyper-V guest image.

Another feature built in to VMM 2008 is the ability to create a library where template images, ISO application images, snapshot libraries, and the like are stored. With a centralized library, administrators have at their fingertips the images, tools, and resources to build new images, to recover from failed images, and to deploy new images more easily. In addition, VMM 2008 provides delegation and provisioning capabilities so that administrators can issue rights to other users to self-provision and self-manage specific images without depending on the IT department to manage images or manually build out configurations.


Management Using Thin Client Terminal Services
Aside from using the centralized Hyper-V Administration tool to manage guest images, administrators can still use Terminal Services to remotely administer servers on the network, whether that’s physical servers or images running as virtual sessions in a Hyper V environment.

An administrator may choose to gain remote access into the Hyper-V host server, and then control all the guest images on that host server, or the administrator could gain remote access one by one to each of the guest sessions. The latter, which is the ability to individually administer a remote system, is a good solution to provide to an individual who needs access to a single server or a limited number of servers, such as a web administrator or a database administrator.

Source of Information : Sams - Windows Server 2008 Hyper-V Unleashed 08

What Is a TPM?

A Trusted Platform Module (TPM) is a microchip that provides some basic security-related functions, mostly ones that involve encryption keys. To be considered secure, the TPM is installed permanently on the motherboard of a computer. The TPM uses a hardware bus to talk to the rest of the system.

A classic problem with any software-based security solution is that if an attacker can insert malicious code before the security software, then the security software can be circumvented. It is also difficult to be confident that any software reporting on its own state can be trusted. Think of rootkits, for example. They make the OS lie. Once you can fake out the OS, what can you trust?

So, a TPM helps address this problem because it can build a chain of trust that starts with hardware. Since this trust begins in hardware, there isn't any practical way to insert malicious code "before" the TPM. The TPM actually validates components of the platform (the computer) and the early boot process very reliably, and BitLocker can rely on this validation.

In many ways, a TPM is similar to a smart card. Although a TPM doesn't store certificates, it can create keys for cryptography and also keep private key permanently within the TPM. If a key created in a TPM is never exposed to any other component, software, process, or person, then, since the private key is never released outside the TPM, it's pretty darn hard to compromise. Because the TPM uses its own internal firmware and logic circuits for processing instructions, it does not rely on the operating system and is not exposed to external software vulnerabilities.

The TPM can also encrypt data provided by the OS, such as symmetric keys used to encrypt large blocks of data. When this type of data is encrypted by the TPM, it can only be decrypted again by the same TPM. This process, often called "wrapping" or "binding" a key, can help protect the key from disclosure. (Sometimes the data being wrapped is called a "blob of data," but "blob" can have a lot of meanings.)

Each TPM has a master "wrapping" key, called the Storage Root Key (SRK), which is stored (and kept) within the TPM itself. A TPM must also have an Endorsement Key (EK), which is permanent once set for that TPM. Other keys are derived from or signed by the EK.

Every time the computer starts, certain measurements are made and stored in the TPM's platform control registers (PCRs). PCRs are discussed in more detail later in this chapter. Accordingly, computers that incorporate a TPM can also create a key that has not only been wrapped, but also tied to specific platform measurements in the PCRS. This type of key can only be unwrapped when those platform measurements have the same values that they had when the key was created. This process is called "sealing" the key to the TPM. Decrypting it is called "unsealing." The TPM can also seal and unseal data generated outside of the TPM. With a sealed key and software like BitLocker, you can lock data until specific hardware or software conditions are met. This process is the basis for the pre-OS boot component validation performed by BitLocker.

There is some bad news, though. To use a TPM, BitLocker requires a TPM that meets the version 1.2 standard, set by the Trusted Computing Group (TCG). If your computer is older than 2006, it is very unlikely to have a version 1.2 TPM (most computers existing today don't have a TPM at all). In addition to having a compatible TPM, your computer must also have compatible BIOS. Most computer manufacturers are releasing Vista-compatible BIOS updates for computers that have version 1.2 TPM chips.

For more information about the TPM specifications, you can visit https://www.trustedcomputinggroup.org/specs/TPM. TPM chip manufacturers work with the computer manufacturers, and generally ensure that the TPM meets encryption export requirements, and they may seek certification from various authorities. One example of a TPM chip in common use is the line by Infineon, featured at http://www.infineon.com (http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-84648&channelPage=%2Fep%2Fchannel%2FproductOverview.jsp&pageTypeId=17099).

Don't despair: computers that lack a compatible TPM can still use the encryption features of BitLocker, provided their BIOS supports access to a USB flash memory device during the early boot process. There are a lot more of these computers around.


Source of Information : Administering Windows Vista Security The Big Surprises

BitLocker Components

BitLocker contains four main components: a single Microsoft TPM driver, an API called TPM Base Services (TBS), BitLocker Drive Encryption, and a WMI provider.

Like most hardware, a TPM chip needs a driver to expose its functionality to the operating system and, ultimately, to applications. By including the Microsoft TPM driver within Windows Vista, we gain increased stability and can more easily leverage the TPM's security features. To use a TPM with BitLocker, you must allow Vista to use the Microsoft driver. The Microsoft driver works with TPM chips that are at version 1.2 or newer.

TPM Base Services (TBS) is an application programming interface (API) that allows applications to access the services provided by a TPM. In this aspect, even though it is part of the Windows operating system, BitLocker is an "application" that uses TBS. The advantage of this architecture is that other applications could also make use of the TPM. After Vista is in the marketplace for a while, I believe we will see other security applications that call on TBS. TBS also allows the TPM to be managed within Windows Vista from the TPM Management Console, instead of forcing users to navigate through endless BIOS screens.

BitLocker Drive Encryption, itself, is the OS component that encrypts and decrypts data on the volume, and uses the TPM to validate the pre-OS boot components. BitLocker has a number of options that can change its default behavior, many of which are exposed through Group Policy settings.

BitLocker is also totally scriptable and manageable. In addition to Group Policy options, BitLocker and TBS both include Windows Management Interface (WMI) providers. WMI is the Windows implementation of Web-Based Enterprise Management (WBEM), so any WBEM console can also be used with BitLocker. More usefully, though, this WMI interface allows BitLocker to be scripted, and Vista includes a scripted utility called manage-bde.wsf, which allows you to configure and control BitLocker from the command line or a batch file, either locally or remotely.

It is also worth noting here, even though we talk about it in more detail later in the chapter, BitLocker integrates with Active Directory Domain Services to store TPM and BitLocker information that can be used for recovery.

Source of Information : Administering Windows Vista Security The Big Surprises

BitLocker Drive Encryption-the Overview

A few years ago, Microsoft began a project called the Next Generation Secure Computing Base, and BitLocker is a direct result of that effort. In designing BitLocker, the System Integrity team in Windows wanted to come up with a solution that included laptop computers (note-books,) desktops, and servers, and provide a way to prevent thieves from using other operating systems or software hacking tools to break or bypass the protection provided by the Windows OS and the file system. That kind of prevention requires encryption.

BitLocker is also designed to provide a transparent user experience. In other words, unlike EFS or RMS, the user doesn't have to do anything complicated to configure and use the protection given by encryption, and the user (and you, the IT guru, and your colleagues in Legal Affairs) can be confident that everything is encrypted.

When Microsoft first started to talk about BitLocker (then called "secure startup"), it seemed like an interesting but impractical technology because it required a Trusted Platform Module (TPM) chip built-in to the computer. Thankfully, the Vista implementation of Bit-Locker, however, lets you encrypt any system so long as it's got a TPM chip, or else by using a compatible USB flash drive, USB port, and BIOS. (BIOS and USB compatibility is part of the testing done before a manufacturer can put a Vista logo on a computer.)

This allows BitLocker to be used on many existing computers. However, some incompatibilities will still be found. It's a good idea to test system, BIOS, and USB flash drive combinations before committing to a large roll-out.

Clearly, laptop computers are where you need to begin, because they are sometimes stolen and often lost. Desktops, too, are sometimes targeted for theft, or sometimes placed in less-than-secure environments (such as shared lobbies or offices without locked doors). BitLocker will also be included in Windows Server code-named "Longhorn" (and will actually offer additional supported features). Although I hope you don't misplace your server very often, servers are very high-value targets for theft. All of these types of computers contain sensitive data, such as IP and PII.

Source of Information : Administering Windows Vista Security The Big Surprises

How Hacker Obtaining Passwords

Attackers have several ways to get hold of your passwords. The following sections list them in order of ease of attack and prevalence (roughly speaking).


Ask for Them
An astonishing number of people, up to three-quarters in some studies, are willing to part with their passwords in trade for something they value more, like chocolate in one particular study (Wagner, 2004).


Capture the Passwords Themselves
Apart from just asking for them, the most fruitful, simplest, and possibly most common way to attack passwords today is to use a keystroke logger to capture them in plaintext as the user enters them. There are many different kinds of keystroke loggers. An innocuous option is using a hardware device that mounts between the keyboard and the computer and has onboard memory to hold all keystrokes. It can be surreptitiously installed or removed in a matter of seconds. Such a device will get access to everything that the computer sees, including all keystrokes, metadata such as typing cadence, and so on. A software program, commonly found in malware and spyware today, can also capture all keystrokes, and can typically capture metadata as well, not just passwords. Some of these include an automatic upload feature to a Web site or an Internet Relay Chat (IRC) channel. Others include a small Web server that the attacker can use to retrieve the goods.

However, the simplest and most direct route for an attacker to capture only passwords is to write a sub-authentication package. Windows, like any other industrial-strength operating system, includes functionality for third parties to extend its authentication subsystem to authenticate to other network devices. An attacker can, with just a few application programming interface (API) calls, write a sub-authentication package that will receive all passwords in plaintext when a user logs on. With some more effort, the attacker can augment the package with the same features as a more general keystroke logger, but generating far less noise because it is specialized to capture only passwords.
Both of the software options require administrative privileges to install, meaning that the attacker must first completely compromise the computer. Physical compromise would also be sufficient to install these types of tools; and it is quite telling that keystroke loggers are now found regularly on public access computers, especially at conferences.


Capture the Challenge-Response Sequence
It is rare that passwords are passed over the network in any form today, and even rarer to see new implementations of plaintext protocols such as FTP, POP, and Telnet. However, even with challenge-response protocols the attacker can often capture both the challenge and the response and attack the combination. It requires more calculations than attacking ordinary hashes, but can be very fruitful if the password is weak.


Capture the Hashes
This is the quintessential attack that everyone worries about. If an attacker has access to the password hashes, he can crack them or use them in some other way. There are several ways to crack them, as we shall see shortly. The most common way to capture the hashes is to compromise the authentication server that stores the passwords. Another option less common but equally valid—is to compromise a computer where someone is already logged on. When a user logs on, as I mentioned earlier, Windows caches that user’s NT hash in memory. An attacker with complete control over the computer can retrieve that hash and use it in the same way as any other hash. Again, this is a problem largely related to your operational practices.


Guessing Passwords
Finally, the attacker can simply try to guess passwords. This is the easiest method to remedy, and also the least fruitful, or at least it should be. Anyone who has an Internet-connected Windows computer and actually looks at the log files will see attempts at this. Most attackers use automated password “grinders” that attempt to log on using either Terminal Services or Windows Networking (Server Message Block, or SMB). The log-on actually an Internet Information Services log-on attempt, which I know only because the host does not respond on either Terminal Services or SMB across the Internet. The automated password grinders will typically try common user names, such as Administrator, with a dictionary of passwords. Shockingly, they must be successful enough with that approach to make it worthwhile to continue. Many people argue that you should rename the Administrator account to fool attackers, and some even say to create a decoy account called Administrator. This has absolutely no effect whatsoever. The error message is the same whether an account does not exist with the name Administrator or whether the attacker gets the password wrong. Therefore, from the attacker’s perspective, he cannot tell whether you have an account called Administrator. He can only tell that he did not get in. You can assure yourself that he will not get in simply by setting a reasonably strong password. For example, if the password is 15 characters long and seemingly random (meaning that it seems random from the attacker’s point of view) the attacker will have to try 542,086,379,860,909,058,354,552,242,176, or so, times before he succeeds. More than likely he will move on before he succeeds in guessing that password.

Source of Information : Microsoft Press Windows Server 2008 Security

Windows Server 2008 Terminal Services Web Access

Terminal Services Web Access (or simply TS Web Access) is another Terminal Services feature that has been enhanced in Windows Server 2008. The previous version of Terminal Services in Windows Server 2003 includes a feature called Remote Desktop Web Connection, which is an ActiveX control that provides essentially the same functionality as the full Terminal Services client but is designed to deliver it using a Web-based launcher. By embedding this ActiveX control in a Web page hosted on Internet Information Services (IIS), you enable a user to access the Web page using a Web browser such as Internet Explorer, download and install the ActiveX control, and initiate a session with a remote terminal server. The user’s computer does not require RDC-instead, the TS session runs within the user’s Web browser using ActiveX functionality.

Remote Desktop Web Connection was limited, however, to running entire remote desktop sessions, not individual applications. In addition, the user had to be able to download and install the ActiveX control to connect to and start a session with the terminal server. And if the security policy on the user’s computer prevented him from downloading and/or installing ActiveX controls, he was out of luck and couldn’t use Remote Desktop Web Connection.

Windows Vista, together with Windows Server 2008, enhances Remote Desktop Web Connection functionality in two basic ways. First, the RDC 6.0 client has this ActiveX control built into it, so users no longer need to download and install an ActiveX control to start a Terminal Services session within a Web browser-at least, they don’t have to do this if their client computer is running Windows Vista (which includes RDC 6.0) or if they are running Windows XP SP2 and have the RDC 6.0 update for Windows XP installed. (The RDC 6.0 update for Windows XP is described in KB 925876 and is available from the Microsoft Download Center or via Windows Update.)

And second, TS Web Access integrates with the TS RemoteApp feature, allowing users to go to a Web page, view a list of available RemoteApp programs they can run, click an icon link for a particular RemoteApp program, and run that program on their computer. In fact, TS Web Access includes a default Web page that you can use for deploying RemoteApp programs from a Web page. This default page consists of a frame together with a customizable Web Part that displays the list of RemoteApp programs within the user’s Web browser. And if you don’t want to use this default Web page, you can add the Web Part into a Microsoft Windows SharePoint Services site.

Once a RemoteApp program has been started from the default Web page, the application appears as if it is running on the local computer’s desktop just like with the TS RemoteApp feature described previously. In addition, if the user starts more than one RemoteApp program from the Web page and these programs are all running on the same terminal server, all the RemoteApp programs will run within the same Terminal Services session.

Source of Information : Introducing Windows Server 2008

Migrating from Microsoft Virtual Server 2005 and VMware to Hyper-V

Many organizations have already implemented Microsoft Virtual Server 2005 or VMware in their environments and wonder what it takes to migrate to Hyper-V, or whether there are ways to centrally manage and administer a dual virtualization platform environment. The simple answer is that there are several ways to migrate, integrate, and support Virtual Server 2005 and VMware images in a Hyper-V environment.


Mounting Existing Virtual Guest Images on Hyper-V
Hyper-V can mount and run both Microsoft Virtual Server 2005 VHD images and VMware guest images directly as guests within Hyper-V. Because Hyper-V has this ability to mount other virtual images, some organizations use Hyper-V as a disaster recovery host for existing images. In such a scenario, if a VS/2005 server or VMware server fails, the images can be copied over to Hyper-V, and Hyper-V can easily boot and mount the images onto the network backbone.

However, despite Hyper-V’s ability to mount VMware images natively within Hyper-V, a VMware image does not have the same administration, management, snapshotting, backup, and support capabilities as a native Hyper-V guest image. So the long-term plan should be to migrate images from VMware to Hyper-V using a virtual to virtual imagemigration tool like what is available in System Center Virtual Machine Manager 2008. When you migrate the VMware to a native Hyper-V image, all the capabilities built in to support Hyper-V images are supported.

For Virtual Server 2005 images mounted on Hyper-V, those images work fine as long as you install the Hyper-V integration tools onto the image that update the drivers of the image itself.


Performing a Virtual to Virtual Migration of Guest Images
A strategy for migrating older images to Hyper-V is to do a virtual to virtual image migration. Via VMM, an administrator can select a running virtual machine (running VMware, XenServer, Virtual Server 2005, or the like) and choose to migrate the image to Hyper-V. This process extracts all the pertinent server image information, applications, data, Registry settings, user settings, and the like and moves the information over to a target Hyper-V host server. Once migrated, the Hyper-V integration tools can be installed, and the image is now clear and ready to be supported by Hyper-V or VMM.


Using VMM to Manage VMware Virtual Infrastructure 3
For organizations that have a fairly substantial investment in VMware and the VMware Infrastructure 3 (VI3) management environment, Microsoft System Center VMM has a built-in configuration setting, shown in Figure 1.8, that allows for the support, monitoring, and consolidation of information between VI3 and VMM. This integration between management tools is vital for organizations that want to keep both the VMware and a new Hyper-V environment running in parallel, and for organizations that are migrating to Hyper-V but still want to have integrated support for the old VMware environment while the migration process is performed.

Source of Information : Sams - Windows Server 2008 Hyper-V Unleashed 08

Cloud storage is for blocks too, not just files

One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...