デスクトップSSOの設定方法

デスクトップSSOとは、統合Windows認証を用いることで、Active Directory(以下AD)に参加しているデバイスであればトラスト・ログインへの認証が不要にすることができる機能です。

※ご利用にはオプション申し込みが必要です。料金はこちら

▼デスクトップSSO  紹介動画はこちら

 

設定方法:

  1. ADサーバ上の設定

  2. トラスト・ログイン上の設定

  3. 利用者PC上の設定 

デスクトップSSOによる認証の優先設定方法

トラブルシューティング

 

設定方法

1. ADサーバ上の設定

※2及び3の操作はコマンドによる操作が必要です。

  1. デスクトップSSO用のAD ユーザーを作成します。
    ※このユーザーはデスクトップSSOの設定をするドメインに属している必要があります。
    ※このユーザーは本機能で認証する度に利用しますので削除しないでください。

  2. setspnコマンドでサービスプリンシパル名を登録します。
    登録:setspn -S HTTP/portal.trustlogin.com [手順1で作成したADユーザー名]
    ※参考 setspnコマンド
    解除:setspn -D http/portal.trustlogin.com [ADドメイン名]\[作成済みADユーザー名]
    確認:setspn -Q http/portal.trustlogin.com

  3. keytabコマンドでKey Tableファイルを生成します。
    ktpass /out c:\[任意のKeyTab名].keytab /princ HTTP/portal.trustlogin.com@[ADドメイン名(大文字)] /mapuser [手順1で作成したADユーザー名]@[ADドメイン名(大文字)] /pass [手順1で作成したADユーザーパスワード] /ptype KRB5_NT_PRINCIPAL /crypto All

    生成したKeytabファイルをローカルに保存します。

2. トラスト・ログイン上の設定

  1. ユーザーのsAMAccountNameを設定します。管理ページにログインし、「管理ページ > メンバー」から対象のメンバーを選択し、「カスタム属性」タブを開き「編集」をクリックします。AD用のカスタム属性を以下の通り設定し、「保存」します。(CSVで一括登録することも可能です。)
    ・ 属性名 : UPN
    ・ 属性値 :  [sAMAccountName]@[ADドメイン名(大文字)]
    ※なお、 AD連携オプションを利用になれば、sAMAccountNameは自動設定されるためこちらの作業は不要です。(2020/3/2以前にダウンロードしたADコネクターは再インストールが必要です)
    ※SCIM IDP連携を使いAzure ADからユーザー属性を取得する場合は、こちらの作業は不要ですただし、ADとAzure ADで同じドメインの利用が必要です。

    desktopSSO_2_3.png

  2. 「管理ページ > 設定 > オプション機能」メニューを開き、「デスクトップSSO」の右にある「設定」ボタンを開き、表示画面の「デスクトップSSO設定追加」を開きます。

    desktopSSO_2_1.png
  3. 各項目の入力及びKeytabファイルをアップロードし、「登録」ボタンを押します。
    「UPNの選択」はデスクトップSSO認証時に必要なUPN値を保持するカスタム属性項目名の指定に使用します。
    ・ 名前:デスクトップSSOのログインボタン名
    ・ ドメイン名:ADドメイン名(大文字)
    ・ Keytabファイル:ADで生成したKeytabファイルをアップロード
    ・ UPNの選択:(推奨設定)AzureAD SCIMユーザーはuserPrincipalName、それ以外のユーザーはUPN
    desktopSSO_2_2.png
  4. デスクトップSSOを利用するユーザーを指定します。デスクトップSSOの設定画面を開き、デスクトップSSOの名前をクリックします。

    desktopsso_2_4.png
    ※サービスプリンシパル名は自動入力されます。

  5. 「メンバー追加」より利用するメンバーを登録します。

    desktopsso_2_5.png

3. 利用者PC上の設定

  1. ブラウザの統合認証設定を行います。

    【Internet Explorer】
    ①コントロールパネル > インターネットオプション > セキュリティ > ローカルイントラネット > サイト
    「https://portal.trustlogin.com」をゾーンに追加します。

    desktopSSO_3_1.png

    ②コントロールパネル> インターネットオプション > 詳細設定
    「統合Windows認証を使用する」にチェックが入っていることを確認します。

    desktopSSO_3_2.png


    【Chrome、Edge(Chromium版)】
    ※Internet Explorerと設定を共有するため、Internet Explorerでの設定方法をご確認ください。

    【Firefox】
    ① アドレスバーに about:config と入力し、「危険を承知の上で使用する」をクリックします。

    desktopSSO_3_3.png

    ②  [ network.automatic-ntlm-auth.trusted-uris ]を検索し、検索結果をダブルクリックします。
    文字列に [ https://portal.trustlogin.com ] と入力し、「OK」をクリックします。

    desktopSSO_3_4.png

    ③ [ network.negotiate-auth.trusted-uris ]を検索し、検索結果をダブルクリックします。
    文字列に [ https://portal.trustlogin.com ] と入力し、「OK」をクリックします。

    desktopSSO_3_5.png

    ■ Firefox設定のヒント
    Active Directory によるポリシー設定で一括設定するには以下の記事をご参照ください。
    グループポリシーを使用して Firefox をカスタマイズする
    ※こちらの設定についてはサポート外となります。


  2. 動作確認を行います。

    トラスト・ログインのログイン画面に企業IDとメールアドレスを入力し「ログイン」ボタンをクリックします。
    desktopSSO_3_6.png

    認証済みADに加入済みのPCから接続した場合
    ログインボタン押下後、自動で認証行い、成功後マイページへ遷移します。

    desktopSSO_3_7.png

    認証済みADに加入していない端末から接続した場合
    デスクトップSSOが許可されていない端末では「別の認証方法でログイン」するボタンが表示されます。
    ※デスクトップSSO以外の認証を持たないユーザーの場合はボタンを押しても画面遷移しません。

    desktopSSO_3_8.png
  3. デスクトップSSO以外の認証方法を選択します。
    ※デスクトップSSOボタンを押すと「別の認証方法でログイン」の画面へ戻ります。

    desktopSSO_3_9.png

デスクトップSSOによる認証の優先設定方法

  1. 管理ページにログインし、「管理ページ > 設定 > オプション機能」メニューを開き、「デスクトップSSO」の右にある「設定」ボタンを開き、表示画面の「編集」ボタンを押下します。
    「デスクトップSSOによる認証を優先して行う」の右側のバーのON/OFFにより設定を変更できます。

    ON:最初にデスクトップSSOによる認証を行い、失敗した場合認証方法の選択画面を表示する
    OFF:最初から認証方法の選択画面を表示する

    desktopSSO_3_10.png
    desktopSSO_3_9.png

トラブルシューティング

Q 1)設定を間違えたためトラスト・ログインにログインできなくなってしまいました。

A )上記で設定したURLを削除することでデスクトップSSOが無効となり、他の認証方法でログインできるようになります。

【IE、Chrome】

① Internet Explorerツール > インターネットオプション > セキュリティ > ローカルイントラネット > サイト 「https://portal.trustlogin.com」を削除します。

【Firefox】

上記「3.利用者PCの設定 >1.ブラウザの統合認証設定を行います。」のFirefox①、②、③の手順で設定したURLを削除します。

Q2 )デスクトップSSOに失敗してしまいます。

A )デスクトップSSOでのログインに失敗する場合は、以下のチェックを行ってください。

チェック項目 対処方法
Active Directoryに接続可能でしょうか? トラスト・ログインにログインする際にActive Directoryに接続する必要があります。Active Directoryに接続できない場合は、ネットワークの設定をご確認ください。プロキシやVPNに問題のある場合もあります。
Windowsのログオンアカウントを間違っていませんか? トラスト・ログインのアカウントに対応するWindowsアカウントでPCにログオンする必要があります。ドメインユーザーのアカウントを利用しているかご確認ください。
ブラウザの設定は済んでいますか?

ブラウザで統合Windows認証の設定をする必要があります。ブラウザ毎の設定方法については、こちらの”3. 利用者PC上の設定”をご確認ください。

Q3 )Windows 11 24H2 への更新後デスクトップSSO が利用できなくなった。

A )

問題の発生要因

Windows AD サーバーと Windows PC の間で 
・Kerberos の暗号化タイプに互換性がある場合は、デスクトップSSO の利用が可能です。 
・暗号化タイプに互換性がない場合は、デスクトップSSO を利用することはできません。

Windows 11 バージョン 23H2 以前の OS では、Windows Server 2016 や 2019 の AD サーバーにおける既定の暗号化タイプ(RC4)と互換性があるため、デスクトップSSO は問題なく利用できていました。 
 
一方、Windows 11 バージョン 24H2 では、RC4 暗号化方式が既定で無効化されており、これにより Windows Server 2016 や 2019 の AD サーバーが使用する RC4 による Kerberos 認証が拒否されます。その結果、Windows 11 バージョン 24H2 では デスクトップSSO が正常に機能しない原因となっています。

Windows 11 のデフォルト値変更に関して、以下 Microsoft の公式ドキュメントでご確認いただけます。

https://learn.microsoft.com/ja-jp/windows/whats-new/deprecated-features 

1. 事象概要

Windows 11 23H2 以前の OS 環境では正常に動作していた デスクトップSSO が、Windows 11 24H2 に更新後、動作しなくなった。

2. 原因分析

調査手順

クライアント端末の以下のコマンドを実施し、Kerberos チケットの詳細を確認します。

klist get http/portal.trustlogin.com

A screen shot of a computer

AI-generated content may be incorrect.

上記コマンドの出力から、以下のように暗号化方式(Encryption Type)が RSADSI RC4-HMAC(NT) であることが確認されました。

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

Windows AD サーバーのバージョンによっては、Kerberos の暗号化タイプが明示的に設定されていない場合、OSの既定値が自動的に使用されます。

バージョン 既定で使用される暗号化タイプ 備考
Windows Server 2016 RC4-HMAC, AES128, AES256 通常は明示的な設定は不要ですが、既定では RC4 が優先されます。
Windows Server 2019 RC4-HMAC, AES128, AES256 上記と同様に、RC4 が既定で使用されます。
Windows Server 2022 / 2025(推定) AES128, AES256(RC4 は下位互換用として有効) セキュリティ強化の観点から、AES 系が中心に利用される設計です。

 

3. 対処方法

対応方針

AD サーバーにおいて、トラストログインサーバーとの通信に使用される Kerberos チケットの暗号化方式を、Windows 11 バージョン 24H2 以降でも互換性がある方式に変更します。 

操作手順

3.1 過去にグループポリシーまたはローカルセキュリティポリシーで、Windowsのセキュリティポリシー「Kerberos で許可する暗号化の種類を構成する」の設定を変更していた場合、3.2の設定を適用することで、既存の Windows 端末において デスクトップSSO が利用できなくなるリスクがあります。 

作業を実施する前に、デスクトップSSO を利用しているすべての Windows 端末がKerberos の許可する種類は「RC4」に限定していないことを必ずご確認ください。 
※確認方法は最後の「4. 補足事項 」を確認 ください。

3.2 Active Directory(AD)での設定変更

デスクトップSSO 用に構成されたADユーザーアカウントを確認します。 
(※AD サーバーで setspn を用いて設定したADユーザーアカウント。 
 設定マニュアルの「1. ADサーバ上の設定 の 1のそのADユーザー」を指します) 

https://support.trustlogin.com/hc/ja/articles/360000548741

該当ADユーザーに対し、以下の設定を行います。

  • 該当ユーザーのプロパティ画面を開き、「アカウント オプション」から、「このアカウントで Kerberos AES 256 ビット暗号化をサポートする」チェックボックスを有効にし、「OK」または「適用」をクリックします。

A screenshot of a computer

AI-generated content may be incorrect.

これでトラストログインサーバとの通信の暗号タイプはAES 256になりました。

※全体の変更点は、上記の1か所のみです。個別の AD ユーザーに対する設定変更は不要です。

3.3 クライアント PC 側でのグループポリシー更新

AD 上の変更をクライアントに反映するため、以下コマンドを実行します。

gpupdate /force

3.4 Kerberos チケットの再確認

再度、以下のコマンドでチケット取得時の暗号方式を確認します。

klist get http/portal.trustlogin.com

A computer screen with white text

AI-generated content may be incorrect.

出力に以下のように表示されれば設定は正常です:

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 

3.5 デスクトップSSO 動作確認

対象のクライアント端末にて、デスクトップSSO による認証が正常に行えるか確認してください。

4. 補足事項 
デスクトップSSO を利用しているWindows 端末がKerberos の許可する種類は「RC4」に限定していないことを必ずご確認ください。

4.1 ローカルポリシーでの確認項目

管理者で、[ローカル グループ ポリシー エディター]>[セキュリティの設定]>[ローカル ポリシー]>[セキュリティ オプション]>[ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する]> セキュリティ設定内容を確認します。 
なにもチェックつけていない場合は、下記の通りに選択してください。 

且つ下記の項目は選択されている状態にしてください。

RC4_HMAC_MD5、AES128_HMAC_SHA1、AES256_HMAC_SHA1

Future encryption types 
 

4. 2 レジストリの値確認

レジストリにて、以下の項目の値をご確認ください。

パス: 
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\

確認すべき値: 
SupportedEncryptionTypes の値が 0x7ffffffc(16進数)になっていれば正しい設定です。

別の値になっている場合、7ffffffcに更新してください。

デスクトップSSOの設定方法

デスクトップSSOとは、統合Windows認証を用いることで、Active Directory(以下AD)に参加しているデバイスであればトラスト・ログインへの認証が不要にすることができる機能です。

※ご利用にはオプション申し込みが必要です。料金はこちら

▼デスクトップSSO  紹介動画はこちら

 

設定方法:

  1. ADサーバ上の設定

  2. トラスト・ログイン上の設定

  3. 利用者PC上の設定 

デスクトップSSOによる認証の優先設定方法

トラブルシューティング

 

設定方法

1. ADサーバ上の設定

※2及び3の操作はコマンドによる操作が必要です。

  1. デスクトップSSO用のAD ユーザーを作成します。
    ※このユーザーはデスクトップSSOの設定をするドメインに属している必要があります。
    ※このユーザーは本機能で認証する度に利用しますので削除しないでください。

  2. setspnコマンドでサービスプリンシパル名を登録します。
    登録:setspn -S HTTP/portal.trustlogin.com [手順1で作成したADユーザー名]
    ※参考 setspnコマンド
    解除:setspn -D http/portal.trustlogin.com [ADドメイン名]\[作成済みADユーザー名]
    確認:setspn -Q http/portal.trustlogin.com

  3. keytabコマンドでKey Tableファイルを生成します。
    ktpass /out c:\[任意のKeyTab名].keytab /princ HTTP/portal.trustlogin.com@[ADドメイン名(大文字)] /mapuser [手順1で作成したADユーザー名]@[ADドメイン名(大文字)] /pass [手順1で作成したADユーザーパスワード] /ptype KRB5_NT_PRINCIPAL /crypto All

    生成したKeytabファイルをローカルに保存します。

2. トラスト・ログイン上の設定

  1. ユーザーのsAMAccountNameを設定します。管理ページにログインし、「管理ページ > メンバー」から対象のメンバーを選択し、「カスタム属性」タブを開き「編集」をクリックします。AD用のカスタム属性を以下の通り設定し、「保存」します。(CSVで一括登録することも可能です。)
    ・ 属性名 : UPN
    ・ 属性値 :  [sAMAccountName]@[ADドメイン名(大文字)]
    ※なお、 AD連携オプションを利用になれば、sAMAccountNameは自動設定されるためこちらの作業は不要です。(2020/3/2以前にダウンロードしたADコネクターは再インストールが必要です)
    ※SCIM IDP連携を使いAzure ADからユーザー属性を取得する場合は、こちらの作業は不要ですただし、ADとAzure ADで同じドメインの利用が必要です。

    desktopSSO_2_3.png

  2. 「管理ページ > 設定 > オプション機能」メニューを開き、「デスクトップSSO」の右にある「設定」ボタンを開き、表示画面の「デスクトップSSO設定追加」を開きます。

    desktopSSO_2_1.png
  3. 各項目の入力及びKeytabファイルをアップロードし、「登録」ボタンを押します。
    「UPNの選択」はデスクトップSSO認証時に必要なUPN値を保持するカスタム属性項目名の指定に使用します。
    ・ 名前:デスクトップSSOのログインボタン名
    ・ ドメイン名:ADドメイン名(大文字)
    ・ Keytabファイル:ADで生成したKeytabファイルをアップロード
    ・ UPNの選択:(推奨設定)AzureAD SCIMユーザーはuserPrincipalName、それ以外のユーザーはUPN
    desktopSSO_2_2.png
  4. デスクトップSSOを利用するユーザーを指定します。デスクトップSSOの設定画面を開き、デスクトップSSOの名前をクリックします。

    desktopsso_2_4.png
    ※サービスプリンシパル名は自動入力されます。

  5. 「メンバー追加」より利用するメンバーを登録します。

    desktopsso_2_5.png

3. 利用者PC上の設定

  1. ブラウザの統合認証設定を行います。

    【Internet Explorer】
    ①コントロールパネル > インターネットオプション > セキュリティ > ローカルイントラネット > サイト
    「https://portal.trustlogin.com」をゾーンに追加します。

    desktopSSO_3_1.png

    ②コントロールパネル> インターネットオプション > 詳細設定
    「統合Windows認証を使用する」にチェックが入っていることを確認します。

    desktopSSO_3_2.png


    【Chrome、Edge(Chromium版)】
    ※Internet Explorerと設定を共有するため、Internet Explorerでの設定方法をご確認ください。

    【Firefox】
    ① アドレスバーに about:config と入力し、「危険を承知の上で使用する」をクリックします。

    desktopSSO_3_3.png

    ②  [ network.automatic-ntlm-auth.trusted-uris ]を検索し、検索結果をダブルクリックします。
    文字列に [ https://portal.trustlogin.com ] と入力し、「OK」をクリックします。

    desktopSSO_3_4.png

    ③ [ network.negotiate-auth.trusted-uris ]を検索し、検索結果をダブルクリックします。
    文字列に [ https://portal.trustlogin.com ] と入力し、「OK」をクリックします。

    desktopSSO_3_5.png

    ■ Firefox設定のヒント
    Active Directory によるポリシー設定で一括設定するには以下の記事をご参照ください。
    グループポリシーを使用して Firefox をカスタマイズする
    ※こちらの設定についてはサポート外となります。


  2. 動作確認を行います。

    トラスト・ログインのログイン画面に企業IDとメールアドレスを入力し「ログイン」ボタンをクリックします。
    desktopSSO_3_6.png

    認証済みADに加入済みのPCから接続した場合
    ログインボタン押下後、自動で認証行い、成功後マイページへ遷移します。

    desktopSSO_3_7.png

    認証済みADに加入していない端末から接続した場合
    デスクトップSSOが許可されていない端末では「別の認証方法でログイン」するボタンが表示されます。
    ※デスクトップSSO以外の認証を持たないユーザーの場合はボタンを押しても画面遷移しません。

    desktopSSO_3_8.png
  3. デスクトップSSO以外の認証方法を選択します。
    ※デスクトップSSOボタンを押すと「別の認証方法でログイン」の画面へ戻ります。

    desktopSSO_3_9.png

デスクトップSSOによる認証の優先設定方法

  1. 管理ページにログインし、「管理ページ > 設定 > オプション機能」メニューを開き、「デスクトップSSO」の右にある「設定」ボタンを開き、表示画面の「編集」ボタンを押下します。
    「デスクトップSSOによる認証を優先して行う」の右側のバーのON/OFFにより設定を変更できます。

    ON:最初にデスクトップSSOによる認証を行い、失敗した場合認証方法の選択画面を表示する
    OFF:最初から認証方法の選択画面を表示する

    desktopSSO_3_10.png
    desktopSSO_3_9.png

トラブルシューティング

Q 1)設定を間違えたためトラスト・ログインにログインできなくなってしまいました。

A )上記で設定したURLを削除することでデスクトップSSOが無効となり、他の認証方法でログインできるようになります。

【IE、Chrome】

① Internet Explorerツール > インターネットオプション > セキュリティ > ローカルイントラネット > サイト 「https://portal.trustlogin.com」を削除します。

【Firefox】

上記「3.利用者PCの設定 >1.ブラウザの統合認証設定を行います。」のFirefox①、②、③の手順で設定したURLを削除します。

Q2 )デスクトップSSOに失敗してしまいます。

A )デスクトップSSOでのログインに失敗する場合は、以下のチェックを行ってください。

チェック項目 対処方法
Active Directoryに接続可能でしょうか? トラスト・ログインにログインする際にActive Directoryに接続する必要があります。Active Directoryに接続できない場合は、ネットワークの設定をご確認ください。プロキシやVPNに問題のある場合もあります。
Windowsのログオンアカウントを間違っていませんか? トラスト・ログインのアカウントに対応するWindowsアカウントでPCにログオンする必要があります。ドメインユーザーのアカウントを利用しているかご確認ください。
ブラウザの設定は済んでいますか?

ブラウザで統合Windows認証の設定をする必要があります。ブラウザ毎の設定方法については、こちらの”3. 利用者PC上の設定”をご確認ください。

Q3 )Windows 11 24H2 への更新後デスクトップSSO が利用できなくなった。

A )

問題の発生要因

Windows AD サーバーと Windows PC の間で 
・Kerberos の暗号化タイプに互換性がある場合は、デスクトップSSO の利用が可能です。 
・暗号化タイプに互換性がない場合は、デスクトップSSO を利用することはできません。

Windows 11 バージョン 23H2 以前の OS では、Windows Server 2016 や 2019 の AD サーバーにおける既定の暗号化タイプ(RC4)と互換性があるため、デスクトップSSO は問題なく利用できていました。 
 
一方、Windows 11 バージョン 24H2 では、RC4 暗号化方式が既定で無効化されており、これにより Windows Server 2016 や 2019 の AD サーバーが使用する RC4 による Kerberos 認証が拒否されます。その結果、Windows 11 バージョン 24H2 では デスクトップSSO が正常に機能しない原因となっています。

Windows 11 のデフォルト値変更に関して、以下 Microsoft の公式ドキュメントでご確認いただけます。

https://learn.microsoft.com/ja-jp/windows/whats-new/deprecated-features 

1. 事象概要

Windows 11 23H2 以前の OS 環境では正常に動作していた デスクトップSSO が、Windows 11 24H2 に更新後、動作しなくなった。

2. 原因分析

調査手順

クライアント端末の以下のコマンドを実施し、Kerberos チケットの詳細を確認します。

klist get http/portal.trustlogin.com

A screen shot of a computer

AI-generated content may be incorrect.

上記コマンドの出力から、以下のように暗号化方式(Encryption Type)が RSADSI RC4-HMAC(NT) であることが確認されました。

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

Windows AD サーバーのバージョンによっては、Kerberos の暗号化タイプが明示的に設定されていない場合、OSの既定値が自動的に使用されます。

バージョン 既定で使用される暗号化タイプ 備考
Windows Server 2016 RC4-HMAC, AES128, AES256 通常は明示的な設定は不要ですが、既定では RC4 が優先されます。
Windows Server 2019 RC4-HMAC, AES128, AES256 上記と同様に、RC4 が既定で使用されます。
Windows Server 2022 / 2025(推定) AES128, AES256(RC4 は下位互換用として有効) セキュリティ強化の観点から、AES 系が中心に利用される設計です。

 

3. 対処方法

対応方針

AD サーバーにおいて、トラストログインサーバーとの通信に使用される Kerberos チケットの暗号化方式を、Windows 11 バージョン 24H2 以降でも互換性がある方式に変更します。 

操作手順

3.1 過去にグループポリシーまたはローカルセキュリティポリシーで、Windowsのセキュリティポリシー「Kerberos で許可する暗号化の種類を構成する」の設定を変更していた場合、3.2の設定を適用することで、既存の Windows 端末において デスクトップSSO が利用できなくなるリスクがあります。 

作業を実施する前に、デスクトップSSO を利用しているすべての Windows 端末がKerberos の許可する種類は「RC4」に限定していないことを必ずご確認ください。 
※確認方法は最後の「4. 補足事項 」を確認 ください。

3.2 Active Directory(AD)での設定変更

デスクトップSSO 用に構成されたADユーザーアカウントを確認します。 
(※AD サーバーで setspn を用いて設定したADユーザーアカウント。 
 設定マニュアルの「1. ADサーバ上の設定 の 1のそのADユーザー」を指します) 

https://support.trustlogin.com/hc/ja/articles/360000548741

該当ADユーザーに対し、以下の設定を行います。

  • 該当ユーザーのプロパティ画面を開き、「アカウント オプション」から、「このアカウントで Kerberos AES 256 ビット暗号化をサポートする」チェックボックスを有効にし、「OK」または「適用」をクリックします。

A screenshot of a computer

AI-generated content may be incorrect.

これでトラストログインサーバとの通信の暗号タイプはAES 256になりました。

※全体の変更点は、上記の1か所のみです。個別の AD ユーザーに対する設定変更は不要です。

3.3 クライアント PC 側でのグループポリシー更新

AD 上の変更をクライアントに反映するため、以下コマンドを実行します。

gpupdate /force

3.4 Kerberos チケットの再確認

再度、以下のコマンドでチケット取得時の暗号方式を確認します。

klist get http/portal.trustlogin.com

A computer screen with white text

AI-generated content may be incorrect.

出力に以下のように表示されれば設定は正常です:

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 

3.5 デスクトップSSO 動作確認

対象のクライアント端末にて、デスクトップSSO による認証が正常に行えるか確認してください。

4. 補足事項 
デスクトップSSO を利用しているWindows 端末がKerberos の許可する種類は「RC4」に限定していないことを必ずご確認ください。

4.1 ローカルポリシーでの確認項目

管理者で、[ローカル グループ ポリシー エディター]>[セキュリティの設定]>[ローカル ポリシー]>[セキュリティ オプション]>[ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する]> セキュリティ設定内容を確認します。 
なにもチェックつけていない場合は、下記の通りに選択してください。 

且つ下記の項目は選択されている状態にしてください。

RC4_HMAC_MD5、AES128_HMAC_SHA1、AES256_HMAC_SHA1

Future encryption types 
 

4. 2 レジストリの値確認

レジストリにて、以下の項目の値をご確認ください。

パス: 
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\

確認すべき値: 
SupportedEncryptionTypes の値が 0x7ffffffc(16進数)になっていれば正しい設定です。

別の値になっている場合、7ffffffcに更新してください。