デスクトップ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で同じドメインの利用が必要です。
   
   
   
   
2. 「管理ページ > 設定 > オプション機能」メニューを開き、「デスクトップSSO」の右にある「設定」ボタンを開き、表示画面の「デスクトップSSO設定追加」を開きます。
   
   
3. 各項目の入力及びKeytabファイルをアップロードし、「登録」ボタンを押します。
   「UPNの選択」はデスクトップSSO認証時に必要なUPN値を保持するカスタム属性項目名の指定に使用します。
   

   ・　名前：デスクトップSSOのログインボタン名
   ・　ドメイン名：ADドメイン名(大文字)
   ・　Keytabファイル：ADで生成したKeytabファイルをアップロード
   ・ UPNの選択：（推奨設定）AzureAD SCIMユーザーはuserPrincipalName、それ以外のユーザーはUPN

   
4. デスクトップSSOを利用するユーザーを指定します。デスクトップSSOの設定画面を開き、デスクトップSSOの名前をクリックします。
   
   
   ※サービスプリンシパル名は自動入力されます。
   
   
5. 「メンバー追加」より利用するメンバーを登録します。
   
   

3. 利用者PC上の設定

1. ブラウザの統合認証設定を行います。
   
   【Internet Explorer】
   ①コントロールパネル ＞ インターネットオプション ＞ セキュリティ ＞ ローカルイントラネット ＞ サイト
   「https://portal.trustlogin.com」をゾーンに追加します。
   
   
   
   ②コントロールパネル＞ インターネットオプション ＞ 詳細設定
   「統合Windows認証を使用する」にチェックが入っていることを確認します。
   
   
   
   
   【Chrome、Edge（Chromium版）】
   ※Internet Explorerと設定を共有するため、Internet Explorerでの設定方法をご確認ください。
   
   【Firefox】
   ① アドレスバーに about:config と入力し、「危険を承知の上で使用する」をクリックします。
   
   
   
   ②  [ network.automatic-ntlm-auth.trusted-uris ]を検索し、検索結果をダブルクリックします。
   文字列に [ https://portal.trustlogin.com ] と入力し、「OK」をクリックします。
   
   
   
   ③ [ network.negotiate-auth.trusted-uris ]を検索し、検索結果をダブルクリックします。
   文字列に [ https://portal.trustlogin.com ] と入力し、「OK」をクリックします。
   
   
   
   ■ Firefox設定のヒント
   Active Directory によるポリシー設定で一括設定するには以下の記事をご参照ください。
   グループポリシーを使用して Firefox をカスタマイズする
   ※こちらの設定についてはサポート外となります。
   
   
   
2. 動作確認を行います。
   
   トラスト・ログインのログイン画面に企業IDとメールアドレスを入力し「ログイン」ボタンをクリックします。
   
   
   

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

   
   
   

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

   
   

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

   
   
   

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

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

トラブルシューティング

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

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

【IE、Chrome】

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

【Firefox】

上記「３．利用者PCの設定 ＞１．ブラウザの統合認証設定を行います。」の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

上記コマンドの出力から、以下のように暗号化方式（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」または「適用」をクリックします。

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

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

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

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

gpupdate /force

3.4　Kerberos チケットの再確認

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

klist get http/portal.trustlogin.com

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

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に更新してください。