Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices
To secure all data being transferred to and from the Windows server, the Windows connector supports built-in RDP network security and enhanced network security options. The built-in RDP security uses the RC4 cipher, which encrypts data of varying size with a 56-bit or a 128-bit key. The enhanced network security options include TLS/SSL (with optional server verification) and Network Level Authentication (NLA) using CredSSP.
The Windows connector uses RSA Security's RC4 cipher to secure all data being transferred to and from the Windows system. This cipher encrypts data of varying size with a 56-bit or a 128-bit key.
Table 17.8, “Encryption Levels for Network Security” lists the four levels of encryption that can be configured on the Windows system.
Table 17.8 Encryption Levels for Network Security
Level | Description |
|---|---|
Low | All data from client to server is encrypted based on maximum key strength supported by the client. |
Client-compatible | All data between client and server in both directions is encrypted based on the maximum key strength supported by the client. |
High | All data between the client and server in both directions is encrypted based on the server's maximum key strength. Clients that do not support this strength of encryption cannot connect. |
FIPS-Compliant | FIPS-compliant encryption is not supported. |
Data encryption is bidirectional except at the Low setting, which encrypts data only from the client to the server.
The enhanced network security options include TLS/SSL (with optional server verification) and Network Level Authentication (NLA) using CredSSP. These options protect the Windows session from malicious users and software before a full session connection is established.
Table 17.9, “Command Line Examples for Enhanced Network Security” provides a list of uttsc command line examples that show which security mechanism is used when the Windows remote desktop service is configured to negotiate with the client. A result of "RDP" means that the built-in RDP security is used.
Table 17.9 Command Line Examples for Enhanced Network Security
uttsc Command Line Examples | Windows XP | Windows Server 2003 R2 | Windows 7, Windows Server 2008 R2 | Windows 8, Windows Server 2012 |
|---|---|---|---|---|
| RDP | SSL/TLS | NLA | NLA |
| RDP | SSL/TLS | SSL/TLS | SSL/TLS |
| RDP | SSL/TLS | NLA | NLA |
| RDP | RDP | RDP | RDP |
Use the following notes to configure TLS/SSL security:
The RDP host must be running Windows Server 2003 R2, Windows 7, Windows Server 2008 R2, Windows 8, or Windows Server 2012.
The Windows system's security layer must be configured as "SSL (TLS 1.0)" or "Negotiate."
In order to connect to a Windows host with TLS/SSL peer
verification enabled (-j VerifyPeer:on),
you must add the root certificate to the client's OpenSSL
cert store or specify an additional search path/PEM file
by using the -j
CAPath: or
path-j
CAfile:
options of the uttsc command.
pem-file
TLS/SSL connections require a certificate to be present on the Windows system. If that is not the case, the connection might fall back to the built-in RDP security (if allowed) or fail.
Use the following notes to configure NLA security:
The RDP host must be running Windows 7, Windows Server 2008 R2, Windows 8, or Windows Server 2012.
The Windows system's security layer must be configured as "SSL (TLS 1.0)" or "Negotiate."
You can enforce NLA security on a Windows system. For
example, when using Windows Server 2008 R2, select the following option
on the Remote tab of the System Properties window: "Allow
connections only from computers running Remote Desktop
with Network Level Authentication (more secure)". With
this option selected, users must use the
-u and -p options with
the uttsc command to connect to the
server.
By default, Kerberos authentication is used for NLA
security. If the Windows connector cannot obtain a
Kerberos ticket for the remote desktop service, it will
use NT LAN Manager (NTLM) authentication. You can specify
the -N kerberos option of the
uttsc command to force it to use only
Kerberos authentication or the -N ntlm
option to force it to use only NTLM authentication.
When using Kerberos authentication, the user name specified must be a valid Kerberos principal name. Use the kinit command to verify if a principal name is valid.
When using Kerberos authentication, Kerberos must be configured on the Sun Ray server as described in Section 17.9.2.3, “Setting Up Kerberos Authentication for NLA Security”.
If you want to use Kerberos authentication for NLA security, Kerberos must be configured properly on the Sun Ray server. Refer to the following information about setting up Kerberos authentication:
krb5.conf(4) man page -
http://docs.oracle.com/docs/cd/E19253-01/816-5174/6mbb98ufn/index.html
Kerberos Service on Oracle Solaris - http://docs.oracle.com/docs/cd/E19253-01/816-4557/seamtm-1/index.html
Kerberos on Oracle Linux - http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-kerberos.html
Once configured, you can check that Kerberos and its name
resolution requirements are configured properly by using the
getent, nslookup, and
kinit commands.
For example:
# getent hosts
my.windows.host must
return the IP address and the hostname
# getent hosts
IP_of_my.windows.host
must return the IP address and the hostname
# nslookup -query=any
_gc._tcp.domain_name
must resolve the domain
# kinit -V
super-user@domain_name
must succeed
Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices