Windows サーバーとの間でやりとりするすべてのデータをセキュリティー保護するため、Windows Connector は組み込みの RDP ネットワークセキュリティーおよび強化されたネットワークセキュリティーオプションをサポートします。組み込みの RDP セキュリティーは、RC4 暗号化を使用します。RC4 は、56 ビットまたは 128 ビットの鍵を使用してさまざまなサイズのデータを暗号化します。強化されたネットワークセキュリティーオプションには、TLS/SSL (オプションでサーバー認証) および CredSSP を使用したネットワークレベル認証があります。
Windows Connector は、RSA セキュリティーの RC4 暗号を使用して、Windows システムとの間でやり取りされるすべてのデータを保護します。この暗号では、各種サイズのデータが、56 ビットまたは 128 ビットの鍵で暗号化されます。
表17.8「ネットワークセキュリティーの暗号化レベル」は、Windows システムに構成できる 4 つの暗号化レベルの一覧です。
表17.8 ネットワークセキュリティーの暗号化レベル
レベル | 説明 |
---|---|
低 | クライアントがサポートする最大の鍵強度に基づいて、クライアントからサーバーへのデータがすべて暗号化されます。 |
クライアント互換 | クライアントがサポートする最大の鍵強度に基づいて、クライアントとサーバー間の両方向のデータがすべて暗号化されます。 |
高 | サーバーの最大の鍵強度に基づいて、クライアントとサーバー間の両方向のデータがすべて暗号化されます。この強度の暗号化をサポートしていないクライアントは接続できません。 |
FIPS 準拠 | FIPS 準拠暗号化はサポートされていません。 |
クライアントからサーバーへのデータのみを暗号化する「低」設定以外のデータ暗号化は双方向です。
強化されたネットワークセキュリティーオプションには、TLS/SSL (オプションでサーバー認証) および CredSSP を使用したネットワークレベル認証があります。これらのオプションは、完全なセッション接続が確立される前に、Windows セッションを悪意のあるユーザーやソフトウェアから保護するのに役立ちます。
表17.9「強化されたネットワークセキュリティーのコマンド行の例」に記載した uttsc コマンド行の例では、Windows リモートデスクトップサービスをクライアントとネゴシエーションするように構成した場合に使用されるセキュリティーメカニズムを示しています。「RDP」という結果は、組み込みの RDP セキュリティーが使用されることを示しています。
表17.9 強化されたネットワークセキュリティーのコマンド行の例
uttsc コマンド行の例 | 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 |
TLS/SSL セキュリティーを構成する場合は、次の注意事項に従ってください。
RDP ホストでは、Windows Server 2003 R2、Windows 7、Windows Server 2008 R2、Windows 8、または Windows Server 2012 が実行されている必要があります。
Windows システムのセキュリティーレイヤーを「SSL (TLS 1.0)」または「ネゴシエーション」に構成する必要があります。
TLS/SSL ピアの検証を有効にして (-j VerifyPeer:on
) Windows ホストに接続するには、クライアントの OpenSSL 証明書ストアにルート証明書を追加するか、uttsc コマンドの -j CAPath:
または path
-j CAfile:
オプションを使用して、別の検索パスまたは PEM ファイルを指定します。 pem-file
TLS/SSL 接続には、Windows システム上に証明書が存在している必要があります。証明書がない場合、接続は可能な場合は内蔵の RDP セキュリティーにフォールバックするか、失敗します。
NLA セキュリティーを構成する場合は、次の注意事項に従ってください。
RDP ホストでは、Windows 7、Windows Server 2008 R2、Windows 8、または Windows Server 2012 が実行されている必要があります。
Windows システムのセキュリティーレイヤーを「SSL (TLS 1.0)」または「ネゴシエーション」に構成する必要があります。
Windows システムで NLA セキュリティーを強化できます。たとえば、Windows Server 2008 R2 の「システムのプロパティ」ウィンドウの「リモート」タブで、「ネットワーク レベル認証でリモート デスクトップを実行しているコンピュータからのみ接続を許可する (セキュリティのレベルは高くなります)」オプションを選択します。このオプションを選択した状態で、-u
および -p
オプションを指定した uttsc コマンドを使用してサーバーに接続します。
デフォルトでは、NLA セキュリティーには Kerberos 認証が使用されます。Windows Connector がリモートデスクトップサービス用の Kerberos チケットを取得できない場合は、NT LAN Manager (NTLM) 認証が使用されます。uttsc コマンドの -N kerberos
オプションを指定して、Kerberos 認証のみを使用するように強制できます。または、-N ntlm
オプションを指定して、NTLM 認証のみを使用するように強制できます。
Kerberos 認証を使用する場合、指定するユーザー名は有効な Kerberos 主体名でなければなりません。kinit コマンドを使用して、主体名が有効かどうかを確認します。
Kerberos 認証を使用する場合、「NLA セキュリティーに対する Kerberos 認証の設定」に説明されているように Kerberos が Sun Ray サーバーで構成されている必要があります。
NLA セキュリティーに対して Kerberos 認証を使用する場合は、Sun Ray サーバーで Kerberos が適切に構成されている必要があります。Kerberos 認証の設定については、次の情報を参照してください。
krb5.conf(4)
マニュアルページ - http://docs.oracle.com/docs/cd/E19253-01/816-5174/6mbb98ufn/index.html
Kerberos サービス (Oracle Solaris の場合) - http://docs.oracle.com/docs/cd/E19253-01/816-4557/seamtm-1/index.html
Kerberos (Oracle Linux の場合) - http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-kerberos.html
構成すると、getent
、nslookup
、および kinit
を使用して、Kerberos およびその名前解決の要件が適切に構成されていることを確認できるようになります。
たとえば:
# getent hosts my.windows.host
は、IP アドレスとホスト名を返す必要があります。
# getent hosts IP_of_my.windows.host
は、IP アドレスとホスト名を返す必要があります。
# nslookup -query=any _gc._tcp.domain_name
は、ドメインを解決する必要があります
# kinit -V super-user@domain_name
が成功する必要があります