Thin Client Feature Overview (Windows Embedded CE 6.0)
Applies to Windows Embedded CE 6.0 R2
This topic provides an overview of key features that are available for Windows Embedded CE powered thin clients. This primarily includes features of Remote Desktop Protocol (RDP) 6.0.
Windows Embedded CE 6.0 R2 includes support for using Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols to encrypt data sent through an RDP channel. SSL and TLS are protocols that enable client/server applications to communicate in a way that reduces the risk of eavesdropping, data tampering, and message forgery. SSL/TSL protocols provide endpoint authentication communications privacy over the Internet by using cryptography. Remote Desktop clients can use TLS/SSL or RDP data encryption.
|RDP does provide 128-bit data encryption. However, in order to provide authentication to verify the identity of a server when you connect to it, a thin client must use SSL/TLS.|
When it communicates with a server, a thin client can use encryption and authentication by including SSL/TSL in the operating system (OS) design.
To communicate by using SSL/TLS, the protocol must be available on both the thin client and the server. When you try to connect to a server that does not have SSL/TSL, you are prompted to connect to a server without SSL/TLS support. Only servers that are running Windows Server 2003 operating systems, Windows XP Professional, Windows Vista, or Windows Server 2008 operating systems support SSL/TLS.
By default, SSL/TLS is included when you include the Remote Desktop Protocol Catalog item in your OS design.
Network Level Authentication (NLA) is an authentication method that finishes the user authentication process before a full Remote Desktop Connection is established and the logon screen appears. With Network Level Authentication, a Terminal Services client can only connect to a server if that server first authenticates it.
Network Level Authentication requires fewer remote server resources. This is because the remote server uses a limited number of resources before it authenticates the thin client. NLA helps improve security by reducing the risk of denial of service attacks that try to limit or prevent access to the Internet. NLA also protects users from connecting to remote computers that are set up for malicious purposes.
To use Network Level Authentication, a thin client must connect to a server that is using Remote Desktop Connection and has enabled the default Network Level Authentication settings.
To enable Network Level Authentication on the server, the IT administrator must do the following:
Click Start, select Control Panel, and then select System.
In the System Properties dialog box, select Remote.
Select Allow connections only from computers running Remote Desktop with Network Level Authentication.
By default, Network Level Authentication is included when the Remote Desktop Protocol Catalog item is included in your OS design.
Network Level Authentication is transparent to the end-user and requires no additional configuration of the thin client.
Server Authentication (SA) can be used to verify that a thin client is connecting to the correct remote server. Server Authentication helps prevent a thin client from connecting to a server that it was not intended to connect to. This also helps to prevent unintentionally exposing confidential information on a server in the enterprise network.
Server Authentication is available with both Windows Vista and the Windows Server 2008 operating system.
Server Authentication is enabled by default. A user can configure this on the Remote Desktop Connection client by doing the following:
Open the CETSC UI. For example, on the Windows Thin Client Shell, click Connect from the Terminal Connection Manager dialog box.
Click Options, and then click the Advanced tab.
Choose Don't connect if authentication fails for the highest level of Server Authentication. The three available authentication options are as follows:
Always connect, even if authentication fails
If you enable this option, you can connect even if Remote Desktop Connection cannot verify the identity of the remote computer.
Warn me if authentication fails
If you enable this option, when Remote Desktop Connection cannot verify the identity of the remote computer, this option warns you so that you can decide whether to continue with the connection.
Don't connect if authentication fails
If you enable this option, you cannot connect if Remote Desktop Connection cannot verify the identify of the remote computer.
- Always connect, even if authentication fails
Windows Embedded CE 6.0 R2 provides a universal serial bus (USB) Smart Card class driver for Smart Card readers based on the USB Chip/Smart Card Interface Devices (CCID) Specification (revision 1.0 or later). The CCID specification specifies a protocol that a host computer can use to interact with CCID class devices or interfaces (on a composite device). This Smart Card driver can be added to a thin client OS design to enable the thin client device to interact with a Smart Card for scenarios such as providing credentials when you log on to a server.
With USB Smart Card class-driver support in Windows Embedded CE, any USB CCID Smart Card reader can connect to a thin client and read credentials from a Smart Card.
To include the USB Smart Card class driver to your OS design, add both the Smart Card Redirection Catalog item and the USB Smart Card Reader Catalog item, located in Device Drivers\Smart Card.
When you include the USB Smart Card Reader Catalog item in your OS design, you must also include a Cryptographic Service Provider (CSP) that is custom-designed to work with your Smart Card reader. Contact your third-party Smart Card reader provider to obtain a Smart Card CSP. For more information about CSPs, see this Microsoft Web site.
For more information, see USB CCID Smart Card Reader Class Driver.
Redirection changes the expected path for accessing resources. Resources to redirect include hard drives, ports, printers, and smart cards. You can achieve redirection by using a redirector.
With RDP 6.0 support for redirection, you can redirect the path of a resource from a location on the server to a location on the thin client. For example, you can redirect the clipboard.
Or, you can redirect the path of a resource from a location on the thin client to a location on the server. For example, you can redirect an installed printer.
The following list shows the types of redirection that you can include in your thin client:
Printer Redirection: Printer redirection automatically sends print jobs to a printer installed on a thin client during a Terminal Services session, without any manual printer configuration changes. When a connection to the server is established, the server checks for the printer installed on the thin client and, if driver support exists, it creates the installed printer in Control Panel on the server to use during the RDP session.
COM Port Redirection: You can use COM port redirection to enable a server-side application to access thin client serial ports directly, such as COM1 and COM2, during a Terminal Services session.
File Storage Redirection: File storage redirection enables users and administrators to redirect the path of a folder on a remote computer to a new location on a local computer. For example, a user can map a client local drive to a drive on the server during an RDP session.
Smart Card Redirection: Smart Card redirection enables a thin client user to log on to a remote server by using a Smart Card. The server authenticates the user by using credentials on a Smart Card plugged into a Smart Card reader attached to the thin client of the user. Smart Card redirection on thin clients can be used only to log on from a Remote Desktop Connection to a remote server by using the certificates that are stored on the Smart Card.
To use Smart Card redirection, you must include the USB CCID Smart Card driver and a custom Smart Card CSP in your OS design. For more information, see USB CCID Smart Card Reader Class Driver.
Audio Redirection: Audio redirection enables sounds or audio on the server to redirect to the speakers or headphones on the thin client.
Clipboard Redirection: Clipboard redirection enables a user to copy bitmaps, text, and files from a remote computer to the clipboard on the local computer during an RDP session.
To include support for a type of redirection, add the specific redirection Catalog item to your OS design, located in CEBASE\Core OS\Applications - End User\Remote Desktop Protocol.
A key feature of RDP is the ability to receive bitmap information from the server and draw the bitmaps onto the local display screen connected to the thin client. RDP 6.0 provides additional features to increase support for displaying GUI on the local display screen.
Custom Display Resolutions
Thin clients built with RDP 6.0 can support custom display resolutions. A custom display resolution provides support for additional display resolution ratios, such as 16:9 or 16:10. For example, newer monitors with resolutions of 1680 × 1050 or 1290 × 1200 are supported. The maximum resolution supported is 4096 × 2048.
In Windows Embedded CE 6.0 R2, the desktop display can be displayed across multiple monitors, known as monitor spanning.
The monitors used for monitor spanning must meet the following requirements:
All monitors must use the same resolution. For example, two monitors that use 1024 × 768 resolution can support monitor spanning. However, one monitor set at 1024 × 768 and one monitor set at 800 × 600 cannot support monitor spanning.
All monitors must align horizontally (that is, side-by-side). There is currently no support for monitor spanning involving multiple monitors vertically on the client system.
The total resolution across all monitors cannot exceed 4096 × 2048.
For additional information about how to provide support for multiple monitors, see How to Support Multiple Screens on a Device.
In Windows Embedded CE 6.0 R2, RDP 6.0 provides support for the following color depths on the local display screen:
8 bits per pixel
16 bits per pixel
24 bits per pixel
32 bits per pixel