# シングルサインオン

Nexthinkクラシックプラットフォームを使用しているお客様は、クラウドネイティブのSSOメカニズムに移行する必要があります。

{% hint style="warning" %}
SSOユーザーの名前がメール形式に従っていない場合は、Nexthink Infinityへの移行手順の一部である[フェーズ1 - 移行準備とFinderの削除](https://edocs.nexthink.com/ja/infinity-transition/infinity-transition-phases/phase-1-prepare-for-transition-and-remove-finder#step-6-transition-to-the-cloud-native-single-sign-on-sso)の拡張ドキュメントを参照してください。
{% endhint %}

多くの組織は、従業員が単一の会社のログインを使用してビジネスアプリケーションにアクセスできるように、IDおよびアクセス管理（IAM）ソリューションを採用しています。 この技術はシングルサインオン (SSO) アクセス制御と呼ばれています。 SSOは、従業員が覚えたり入力したりするパスワードの数を減らすことで、組織のセキュリティを向上させます。

セキュリティアサーションマークアップ言語 (SAML) は、認証と認可の情報を間違いなく交換するための標準であり、特にサービスプロバイダー（ユーザーを認証する必要があるアプリケーション）と、ユーザーのIDについてアサーションを提供するアイデンティティプロバイダーのシステム間で使用されます。 SAMLは、SSOを実装するために多くの組織で広く使用されています。

SAMLを利用することにより、すでにある企業のアイデンティティプロバイダを通じて、NexthinkのWebインターフェースとFinder（クラシック）にログインできるようにします。

## 前提条件 <a href="#singlesign-on-prerequisites" id="singlesign-on-prerequisites"></a>

NexthinkユーザーのSAMLベースの認証を有効にするには、SSO認証方法を提供するSAMLをサポートするIAM企業ソリューションが必要です。 アイデンティティプロバイダ（IdP）として、システムはNexthinkインスタンスとのSSO認証を開始するためのHTTPリダイレクトバインディングに対応している必要があります。

認証フロー内で、Nexthinkインスタンスに接続しようとしているシステムは、すでに認証されていない場合は、許可されたアクセスを得るための安全なゲートウェイにリダイレクトされます。 ITインフラストラクチャが次のURLへのアクセスを許可していることを確認してください：

`https://<instance>-login.<region>.nexthink.cloud`

* `<instance>` はNexthinkインスタンスの名前です
* `<region>` はインスタンスのロケーション名です
  * `us` はアメリカ合衆国用
  * `eu` は欧州連合用
  * `pac` はアジア太平洋地域用
  * `meta` は中東・トルコ・アフリカ用

また、以下のものを確保してください：

* Nexthink Webインターフェースにアクセスするためのローカル管理者アカウント
* Nexthink インスタンス内の 1 つまたは複数の Nexthink ユーザー [ロール](https://github.com/nexthink/documentation.online-product-documentation/blob/develop/ja_docs/configuring_nexthink/configuring-your-platform/administration/account-management/roles/README.md)
* SAMLアイデンティティプロバイダ内のユーザーおよびユーザーグループ

## シングルサインオン管理にアクセス <a href="#singlesign-on-accessingsinglesign-onmanagement" id="singlesign-on-accessingsinglesign-onmanagement"></a>

* メインメニューから**管理**モジュールを選択します。
* **アカウント管理**のセクションの下に、**シングルサインオン**を選択します。

メニュー項目が表示されない場合はロールが正しい[権限](#singlesign-on-permissionspermissions)を持っているか確認してください。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-8d862785eea0c8d5659c903d2fd75666156ce8f2%2Fnxcheseaux-20230228-164110-2x-20230228-154133.png?alt=media" alt=""><figcaption></figcaption></figure>

## アカウントプロビジョニング <a href="#singlesign-on-userprovisioninguserprovisioning" id="singlesign-on-userprovisioninguserprovisioning"></a>

デフォルトでは、ユーザーインターフェイスページにSSOグループのリストが表示されます。 アカウントプロビジョニングは必須です。ユーザーを手動で追加するとローカルアカウントしか作成されません。 SSO 構成を完了するまで、［アカウントプロビジョニング］タブはグレー表示のままです。

IdPで定義したグループをNexthinkのユーザーロールにマッピングします:

1. 管理者の権限を持つローカルユーザーアカウントを使用して、NexthinkのWebインターフェイスに接続します。
2. **Single sign-on** の構成ページに移動し、**アカウントプロビジョニング** タブを選択します。
3. ページの右上隅にある**新しいSSOグループ**ボタンをクリックします。
   * **SSOグループ**フィールドにグループ名を入力してください。
     * Azure ADをIdPとして使用する場合は、グループ名ではなく\_group identifier\_を使用してください。
     * Active Directory Federation Services (AD FS) を使用する場合、グループ名の前にドメインを付けます: `<domain>\<group_name>`。
   * **ロール**には、リストからユーザーロールを選択します。
4. オプションで、前の手順を繰り返してより多くのマッピングを追加します。
5. **保存**をクリックします。

ログイン時には、マッピングされたグループの少なくとも1つのメンバーであるすべてのユーザーにNexthinkのWebインターフェイスへのアクセス権が付与されます。 割り当てられたロールによって、ユーザーの正確な権限が決まります。

#### **マッピングの優先順位を決定する**

ユーザーは複数のグループに属する場合があるため、グループのマッピングを指定する順序が重要です。 ユーザーが2つのグループに属し、両方のグループが異なるロールにマッピングされている場合、システムはリストの最初のグループにマッピングされたロールをユーザーに割り当てます。

{% hint style="info" %}
**Everyoneグループ**

\_Everyone\_という名前のSSOグループをマッピングすることはできません。これはシステムがのみ使用できるためです。 \_Everyone\_という名前のグループのマッピングはシステムによって拒否されます。
{% endhint %}

## SSO コンフィギュレーション <a href="#singlesign-on-ssoconfigurationssoconfiguration" id="singlesign-on-ssoconfigurationssoconfiguration"></a>

SSOを有効にして設定するには、Nexthink管理者として:

* **シングルサインオン**設定ページに移動します。
* [SSO コンフィギュレーション](#singlesign-on-ssoconfigurationssoconfiguration)タブを選択します。

NexthinkのSSOメカニズムは[Okta](https://www.okta.com)によって提供される技術に依存しています。 セットアップフェーズ中に、例えばNexthink Webインターフェースが提供する`metadata.xml`ファイル内で `*.okta.com`や`*.oktacdn.com`ドメイン名への参照がある場合があります。 そのため、NexthinkはOktaのURLをファイアウォールルールで許可することを推奨します。 [connectivity-requirements](https://docs.nexthink.com/platform/ja/configuring_nexthink/before-you-begin/technical-requirements/connectivity-requirements "mention") を参照してください。

{% hint style="info" %}
一度有効にすると、新しい設定がさまざまなアプリケーション層に反映され、Nexthinkインスタンスが新しい認証プロセスに切り替わるまで数分かかる場合があります。
{% endhint %}

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-8cd05a9c9617e7bb45429fcfef01a0557a03ea68%2Fnxcheseaux-20230228-161248-2x-20230228-151708.png?alt=media" alt=""><figcaption></figcaption></figure>

**SSO構成**タブを次のように設定してください。

1. **SAML 2.0認証**スイッチを切り替えます。
2. **IdPメタデータのアップロード**セクションで、Identity Providerからの情報を使用して各フィールドを設定します。
   * **IdP発行者URI**: Identity Providerの発行者URIです。 この値は通常、Identity Provider `EntityDescriptor`のSAMLメタデータ`entityID`です。
   * **IdP Single sign-on URL**: Identity Providerの認証リクエストプロトコルエンドポイントで、NexthinkインスタンスからのSAML `AuthnRequest`メッセージを受信します。 Nexthinkは`AuthnRequests`にHTTP-GETを使用します。 HTTP-POSTではなくHTTP-リダイレクトバインディングを選択してください。
   * **IdP署名証明書**: Identity ProviderのSAMLメッセージとアサーション署名を検証するために使用するPEMまたはDERエンコードされた公開鍵証明書です。 これをBase64エンコードしなければなりません。
3. Nexthinkの`metadata.xml`ファイルをダウンロードし、それを使用してIdentity ProviderでのSSOアクセスを設定します。
4. SAMLオプションを選択します。 SAMLメッセージは、異なるメソッド（**バインディング**と呼ばれる）を使用して送信できます。
   * **HTTPリダイレクト**では、HTTPリダイレクトメソッドを使用してSAMLメッセージを送信します。 コンテンツはURLパラメータを使用して送信されます。 これがデフォルトオプションです。
   * **HTTP POST**は、HTMLフォームを使用してSAMLメッセージをPOSTリクエストで送信します。 SAMLメッセージコンテンツがURLパラメータを使用して送信するには大きすぎる場合、このオプションを選びます。
5. ユーザープロビジョニング時にユーザー情報を取得するために使用される**属性名**を設定してください。 決められた名前のSAML属性としてその値を送信するようにIdentity Providerを設定する必要があります。 Identity ProviderがNexthink名に一致するカスタム属性名をサポートしていない場合、それらを調整します。
   * **グループ属性**: ユーザーグループのリストを取得するためのSAML属性。 ユーザーは、Nexthinkにアクセスするためにユーザープロビジョニングセクションに定義されたグループと一致するグループを少なくとも１つ持たなければなりません。 デフォルト値は`nexthink.groups`です。
   * **フルネーム属性**: ユーザーのフルネームを取得するためのSAML属性。 デフォルト値は`nexthink.fullname`です。
   * **メールアドレス属性**: ユーザーのメールアドレスを取得するためのSAML属性。 デフォルト値は`nexthink.email`です。
   * **名前ID形式属性**: 予想される名前の形式。 一部のIdentity Providerは、これを`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`に設定することを要求します。 デフォルト値は`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`です。

{% hint style="info" %}
シングルサインオン（SSO）を設定した後、NexthinkはデフォルトでSSOログインページを表示します。 そのため、非SSOローカルユーザーは認証には"/login"ページを使用する必要があります。

より詳しい情報は、[Webインターフェイスへのログイン](https://docs.nexthink.com/platform/ja/getting-started/logging-in-to-the-web-interface)ドキュメントを読んでください。
{% endhint %}

## SSO コンフィギュレーションの例 <a href="#singlesign-on-ssoconfigurationexamples" id="singlesign-on-ssoconfigurationexamples"></a>

#### **Identity ProviderとしてActive Directory Federation Services (AD FS)を構成する**

1. Nexthink管理者として、**シングルサインオン**設定ページに移動し、**SSO構成**タブを選択します。
2. **SAML 2.0認証**スイッチを既に有効にしていないなら切り替えます。
3. メタデータの値を次のように設定します。
   * **IdP Issue URL** を `https://<yourdomain.com>/adfs/services/trust/` とし、`<yourdomain>` を AD FS サーバーの完全修飾ドメイン名 (FQDN) に置き換えます。
   * **IdP Single sign-on URL** を `https://<yourdomain.com>/adfs/ls/` とし、`<yourdomain.com>` を AD FS サーバーの完全修飾ドメイン名 (FQDN) に置き換えます。

{% hint style="warning" %}
値は、AD FS メタデータによっては `https` ではなく `http` を含む場合があることに注意してください。
{% endhint %}

1. Nexthinkの`metadata.xml`ファイルをダウンロードしてください。
2. AD FSを実行しているWindows Serverシステムに管理者としてログインします。
3. AD FS管理コンソールを開きます。
4. **依頼先の信頼**を右クリックし、\*\*依頼先の信頼の追加...\*\*を選択して、信頼できる依頼先の追加ウィザードを起動します。
   * **ようこそ**ステップで、**クレーム認識型**の依頼先を選択します。
   * **開始**をクリックします。
   * **データソースの選択**ステップで、**ファイルから依頼先に関するデータをインポートする**オプションを選択します。
   * \*\*参照...\*\*をクリックし、`metadata.xml`ファイルの位置を指定します。
   * `metadata.xml`ファイルを選択し、**開く**をクリックします。
   * **次へ**をクリックします。
   * **表示名の指定**ステップで、適切な依頼先の名前を入力します。
   * （オプション）依頼先に関する追加情報を**ノート**に入力します。
   * ウィザードの残りのステップをスキップするために**次へ**を連続してクリックします。
   * 処理を完了するには**閉じる**をクリックします。
5. 左側のツリーで、**依頼先の信頼**をクリックして、信頼できる依頼先のリストを表示します。
6. 新しく追加されたNexthink Webインターフェースを表す信頼できる依頼先エントリを右クリックします。
7. コンテキストメニューから、クレームを発行するためのポリシーを編集するエントリを選択します。
   * Windows Server 2016の場合、\*\*クレーム発行ポリシーの編集...\*\*を選択します。
   * Windows Server 2012の場合、\*\*クレームルールの編集...\*\*を選択します。
8. **発行変換ルール**タブで、\*\*ルールの追加...\*\*をクリックして、ユーザーのUPNをName IDにマッピングし、それをNexthink Webインターフェースがユーザーフィールドと一致させて認証します。
   * **ルールタイプの選択**では、**LDAP属性をクレームとして送信**を**クレームルールテンプレート**で選択します。
   * **次へ**をクリックします。
   * **クレームルールの構成**:
     * **クレームルール名**には、ルールの適切な名前を入力します（例: `Map UPN to Name ID`）。
     * **属性ストア**で**Active Directory**を選択します。
     * **LDAP属性からのクレームタイプへのマッピング**の設定では、**LDAP属性**の**User-Principal-Name**を、**クレームタイプの出力**の**Name ID**として選択します。
   * **完了**をクリックします。
9. 再度、**発行変換ルール**タブで\*\*ルールの追加...\*\*をクリックして、クレームを追加します。
   * **ルールタイプの選択**で、**クレームを変換する**を**クレームルールテンプレート**で選択します。
   * **次へ**をクリックします。
   * **クレームルールの構成**:
     * **クレームルール名**には、ルールの適切な名前を入力します（例: `UPN as Name ID in email format`）。
     * **入力クレームタイプ**に**UPN**を選択します。
     * **出力クレームタイプ**に**Name ID**を選択します。
     * **出力名ID形式**には**Email**を選択します。
     * すべてのクレーム値を透過的に保持するオプションをチェックしておきます。
   * **完了**をクリックします。
10. また**発行変換ルール**タブで、\*\*ルールの追加...\*\*をクリックしてクレームを追加します。
    * **ルールの種類の選択**では、**クレームルールテンプレート** の下で**LDAP 属性をクレームとして送信する**を選択してください。
    * **次へ**をクリック。
    * **クレームルールの設定**:
      * **クレームルール名**には、適切な名前を入力してください。例としては、`Nexthink claims`があります。
      * **属性ストア**で**Active Directory**を選択。
      * **LDAP属性のクレームタイプへのマッピング**で、**ドメイン名で修飾されたトークングループ**と**アウトゴーイングクレームタイプ**として**グループ**を選択します。
      * 1 線を追加し、**LDAP属性のクレームタイプへのマッピング**で、**表示名**と**姓**を**アウトゴーイングクレームタイプ**として選択してください。
      * 1 行を追加し、**LDAP属性のアウトゴーイングクレームタイプへのマッピング**で、**Eメールアドレス**として**Eメールアドレス**を選択してください。
    * **完了**をクリック
    * **OK**をクリック。
11. Nexthink の Web インターフェイスを表す信頼できるリライイングパーティエントリをもう一度右クリックします。
12. メニューから**プロパティ**を選択します。 リライイングパーティのプロパティを表示および変更するためのダイアログボックスが表示されます。
    * **Advanced** タブの下で、**セキュアハッシュアルゴリズム**として**SHA-256**を選択します。
    * プロパティダイアログボックスを閉じるには **OK** をクリックします。
13. **サービス**を展開し、**証明書**をクリックして、AD FS サーバーの署名証明書をダウンロードします。 **トークン署名**証明書をダブルクリックし、**詳細**タブに移動して、証明書エクスポートウィザードを開くには\*\*ファイルにコピー…\*\*をクリックします。
    * **Base-64 でエンコードされた X.509 (.CER)** を選択し、次へをクリックします。
    * 後で使用するためにファイルを保存します。
14. Nexthink 管理者として Nexthink ウェブインターフェイスに戻り、**シングルサインオン**設定ページに移動して **SSO 設定** タブを選択します。
15. AD FS 管理コンソールから取得した署名証明書をアップロードします。
16. 以下の通り属性値を設定します。
    * **グループ属性** を `http://schemas.xmlsoap.org/claims/Group` とします。
    * **フルネーム属性** を `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` とします。
    * **Eメールアドレス属性**を`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`とします。
    * **名前IDフォーマット属性**を `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` とします。
17. **保存**をクリックしてください。
18. [ユーザー プロビジョニング](#singlesign-on-userprovisioninguserprovisioning) に関する指示に従ってください。

#### **Entra ID をアイデンティティプロバイダーとして設定する**

1. Nexthink 管理者として Nexthink の web インターフェースに戻り、シングルサインオン設定ページに移動し、SSO 設定タブを選択します。
2. **SAML 2.0 認証**スイッチをトグルし、未有効化の場合は有効化します。
3. Nexthink サービスプロバイダーのメタデータファイル（metadata.xml）をダウンロードしてください。 このファイルを後で使用します。
4. [Azure ポータル](https://portal.azure.com/) にログインします。
5. **エンタープライズアプリケーション**、次に**新しいアプリケーション**、そして最後に**独自のアプリケーションを作成する**をクリックします。
6. **独自のアプリケーションを作成する**とラベル付けされた右側パネルで、例としてアプリケーション名として「Nexthink」と入力し、ギャラリーにない他のアプリケーションを統合します。
7. **シングルサインオンのセットアップ**、次に **SAML**、次に **メタデータファイルのアップロード**をクリックします。
8. ページの左上隅にある **メタデータファイルのアップロード** ボタンをクリックします。
9. `metadata.xml` ファイルを選択し、保存します。
10. **属性とクレーム**を編集するには、ページ右上のペンシルアイコンをクリックします。 クレームを編集するページが表示されます。
    * **一意のユーザー識別子**（Name ID）がメールフォーマットのユーザープリンシパル名（UPN）であることを確認してください:
      * **user.userprincipalname \[nameid-format:emailAddress]**
11. 発行される SAML アサーションにユーザーグループを含めるには、**グループクレームを追加**ボタンをクリックします。
    * ユーザーに関連付けられたグループがクレームで返されるよう、**アプリケーションに割り当てられたグループ**を選択します。
    * 返される**ソース属性**として**グループID**を選択します。
    * **高度なオプション**で、**グループクレームの名前をカスタマイズする**にチェックを入れます。
    * \*\*名前（必須）\*\*フィールドに`nexthink.groups`を使用します。
    * **保存**をクリックして**ユーザー属性とクレーム**ページに戻ります。
12. **新しいクレームを追加**ボタンをクリックし、発行された SAML アサーションでユーザーのフルネームを含めるには、**ユーザークレームの管理**ページを読み込みます。
    * **名前**フィールドに`nexthink.fullname`を使用します。
    * **ソースのタイプ**として**属性**を選択します。
    * **ソース属性**フィールドに`user.displayname`を使用します。
    * **保存**をクリックします。
13. 発行された SAML アサーションにユーザーのメールを含めるために、 **新しいクレームを追加** ボタンをクリックして、**ユーザークレームの管理**を読み込みます。
    * **名前**フィールドに`nexthink.email`を使用します。
    * **ソース属性**フィールドに`user.mail`または`user.userprincipalname`を使用します。
    * **保存**をクリックします。
14. **ログイン URL** と **Microsoft Entra Identifier** をメモしておいてください。 Nexthink インスタンスの SSO 設定時にこれらを使用します。
15. ページの三つ目のタイルで **SAML 署名証明書**、最初のエントリと関連する **証明書（Base64）** のダウンロードリンクをクリックします。
16. 後に Nexthink のロールにマッピングするために、Entra ID のグループの識別子を取得します。
    * Azure ポータルのメインページに戻り、左側のパネルで **Microsoft Entra ID** をクリックします。
    * **管理**の下にある **グループ**を選択します。 アクティブなグループのリストがページ **グループ － すべてのグループ** に表示されます。
    * Nexthink の役割にマッピングするグループの 1 つを選択します。
    * ページの左側メニューで、**管理**の下にある**プロパティ**を選択します。
    * **プロパティ** ページの **一般設定** セクションの **オブジェクト ID** 欄の右横にあるコピーアイコンをクリックしてグループ識別子をコピーします。
    * **オブジェクト ID** をどこか他の場所に貼り付け、例えばテキストエディターに保存して後で使用します。
    * グループの選択に戻るには、**プロパティ** ページの上部で**破棄**をクリックし、Nexthink のロールにマッピングする必要があるグループについてこの操作を必要なだけ繰り返します。
17. Nexthink 管理者として Nexthink の Web インターフェイスに戻り、**シングルサインオン** 設定ページに移動して **SSO 設定** タブを選択します。
18. メタデータの値を以下のように設定します。
    * **IdP 発行 URI**を以前に収集した`Microsoft Entra Identifier`として設定。

      場合によっては、最後に 「/」 を追加する必要があります。
    * **IdP シングルサインオン URL**を以前に収集した`ログイン URL`として設定。
19. Azure Portal からダウンロードした IdP 署名証明書をアップロードします。
20. 属性値を次のように設定します：
    * **グループ属性** as `nexthink.groups`
    * **フルネーム属性** as `nexthink.fullname`
    * **メール アドレス属性** as `nexthink.email`
    * **Name ID フォーマット属性** as `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`
21. **保存**をクリック。
22. [ユーザープロビジョニング](#singlesign-on-userprovisioninguserprovisioning)に関する指示に従ってください。

#### **汎用 SAML アイデンティティプロバイダーの設定**

市場に存在するすべての SAML アイデンティティプロバイダーの設定手順を詳細に説明することは不可能ですが、準拠したプロバイダーを設定する手順は上記の例と大きく異なる運びではありません。

<table data-full-width="false"><thead><tr><th width="194">メタデータ</th><th width="157">エンティティ ID</th><th width="130">Assertion Consumer Service (ACS)</th><th width="126">ACS バインディング</th><th>NameID フォーマット</th></tr></thead><tbody><tr><td><p>Nexthink 管理者として、**シングルサインオン**設定ページに移動して **SSO 設定**タブを選択してください。</p><p>**SAML 2.0 認証**スイッチをトグルし、未有効化の場合は有効化します。</p><p>Nexthink の <code>metadata.xml</code> ファイルをダウンロードしてください。</p></td><td><code>metadata.xml</code> ファイルを参照してください。</td><td><code>metadata.xml</code> ファイルを参照してください。</td><td><code>metadata.xml</code> ファイルを参照してください。</td><td><code>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</code></td></tr></tbody></table>

SSO が設定されると、[ユーザープロビジョニング](#singlesign-on-userprovisioninguserprovisioning)に関する指示に従ってください。

## 権限 <a href="#singlesign-on-permissionspermissions" id="singlesign-on-permissionspermissions"></a>

シングルサインオン管理に適切な権限を有効にするには：

* メインメニューから**管理**を選択します。
* ナビゲーションパネルから**役を押します。**
* **新しい役** ボタンをクリックして新しい役を作成するか、それにマウスをホバーさせて編集アイコンをクリックして役の設定を変更し、既存の役を編集します。
* **権限** セクションで、**管理** セクションまで下にスクロールし、**管理者権限**を有効にします。

権限オプションの詳細については、[ロール](https://github.com/nexthink/documentation.online-product-documentation/blob/develop/ja_docs/configuring_nexthink/configuring-your-platform/administration/account-management/roles/README.md) ドキュメントを参照してください。

## SSO (クラシック) からの移行 <a href="#singlesign-on-transitioningfromsso-classic-transitioning" id="singlesign-on-transitioningfromsso-classic-transitioning"></a>

2023年3月15日以前に SSO を構成した場合、再構成を求めるメッセージが表示される可能性があります。 クラシック SSO メカニズムのサポートは 2025 年 3 月 31 日で終了するため、できるだけ早く構成を行ってください。 Nexthink Community にログインし、[Infinity Transition](https://docs.nexthink.com/platform/ja/user-guide/administration/account-management/broken-reference) ガイドで定義された手順に従ってください。

***

関連タスク

* [監査証跡コードアプリケーション](https://docs.nexthink.com/platform/ja/security/exporting-audit-logs)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.nexthink.com/platform/ja/user-guide/administration/account-management/single-sign-on.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.