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