> For the complete documentation index, see [llms.txt](https://docs.nexthink.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexthink.com/platform/ja/user-guide/administration/account-management/single-sign-on.md). # シングルサインオン {% hint style="warning" %} Nexthink classic プラットフォームをご利用のお客様は、クラウドネイティブの SSO メカニズムに移行する必要があります。 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）ソリューションを導入しています。この手法は、*s*iングルサインオン（SSO）アクセス制御と呼ばれます。 SSO により、従業員が記憶して入力する必要のあるパスワードが減り、組織のセキュリティが向上します。 Security Assertion Markup Language（SAML）は、当事者間で認証および認可情報を安全に交換するための標準です。具体的には、ユーザーの認証を必要とするアプリケーションであるサービスプロバイダーと、ユーザー ID に関するアサーションを発行するシステムである ID プロバイダーの間で使用されます。 SAML は、組織で SSO を実装するために広く使用されています。 SAML を活用することで、既存の企業 ID プロバイダーを介して Nexthink ユーザーが Nexthink Web インターフェースおよび Finder（classic）にログインできるようにします。 ## 前提条件 Nexthink ユーザーの SAML ベースの認証を有効にするには、シングルサインオン認証方式を提供する SAML 対応の企業 IAM ソリューションが必要です。 ID プロバイダー（IdP）として、このシステムは Nexthink インスタンスで SSO 認証を開始するための HTTP リダイレクトバインディングをサポートしている必要があります。 認証フローでは、Nexthink インスタンスへの接続を試行するシステムがまだ認証されていない場合、認可済みアクセスを取得するためにセキュアゲートウェイへリダイレクトされます。 IT インフラストラクチャから次の URL にアクセスできることを確認してください： `https://-login..nexthink.cloud` * `` は Nexthink インスタンスの名前です * `` はインスタンスのローカリゼーション名です * `us` はアメリカ合衆国を指します * 欧州連合を表す `eu` * アジア太平洋地域向けの `pac` * 中東、トルコ、アフリカ向けの `meta` また、次のものがあることを確認してください： * Nexthink Web インターフェースにアクセスするためのローカル管理者アカウント * Nexthink インスタンス内の 1 つ以上の Nexthink ユーザー[ロール](/platform/ja/user-guide/administration/account-management/roles.md) * SAML ID プロバイダー内のユーザーおよびユーザーグループ ## シングルサインオン管理へのアクセス 1. メインメニューから **Administration** モジュールを選択します。 2. **Account management** セクションで **Single sign-on** を選択します。 メニュー項目が表示されない場合は、ロールに適切な[権限](#singlesign-on-permissionspermissions)があることを確認してください。
## アカウントプロビジョニング デフォルトでは、ユーザーインターフェースのページに SSO グループのリストが表示されます。手動でユーザーを追加するとローカルアカウントのみが作成されるため、アカウントプロビジョニングは必須です。 SSO コンフィギュレーションを完了するまで、**Account provisioning** タブはグレーアウトされたままになります。
IdP で定義されたグループを Nexthink ユーザーロールにマッピングします： 1. 管理者権限を持つローカルユーザーアカウントを使用して Nexthink Web インターフェースに接続します。 2. **Single sign-on** コンフィギュレーションページに移動し、**Account provisioning** タブを選択します。 3. ページ右上の **New SSO group** ボタンをクリックします。 * **SSO group** フィールドにグループ名を入力します。 * Azure AD を IdP として使用する場合は、グループ名ではなく \_グループ識別子\_を使用します。 * Active Directory Federation Services（AD FS）を使用する場合は、グループ名の先頭にドメインを付けます：`\`。 * **Role** で、リストからユーザーロールを選択します。 4. 必要に応じて前の手順を繰り返し、マッピングを追加します。 5. **Save** をクリックします。 ログイン時に、Nexthink Web インターフェースは、マッピングされたグループの少なくとも 1 つに所属するすべてのユーザーにアクセスを許可します。メインロールと追加ロールによって、ユーザーの正確な権限が決まります。 #### マッピングの優先順位の決定 ユーザーは複数のSSOグループに所属できます。システムはロールを次の2つの部分で割り当てます。 * **メインロール:** メインロールは、システムがユーザーに対して最初に見つけたSSOグループからのみ取得されます。グループマッピングをリストする順序によって、最初に見つかるグループが決まります。メインロールを設定するグループをリストの先頭に配置します。他のグループのメインロールは適用されません。 * **追加ロール:** システムは、メインロールに追加ロールを重ねます。最初に見つかったグループを含め、ユーザーが所属するすべてのSSOグループからこれらのロールを累積します。 {% hint style="warning" %} *Everyone* という名前のSSOグループは、システムのみが使用できるため、マッピングできません。システムは、*Everyone* という名前のグループのマッピングを拒否します。 {% endhint %} ## SSO コンフィギュレーション Nexthink 管理者として SSO を有効化および設定するには： * **Single sign-on** コンフィギュレーションページに移動します * [SSO コンフィギュレーション](#singlesign-on-ssoconfigurationssoconfiguration)タブを選択します。 Nexthink の SSO メカニズムは、[Okta](https://www.okta.com) が提供するテクノロジーに依存しています。セットアップ中に、たとえば Nexthink Web インターフェースが提供する `metadata.xml` ファイル内で、`*.okta.com` および `*.oktacdn.com` ドメイン名が参照される場合があります。そのため、Nexthink ではファイアウォールルールで Okta URL を許可することを推奨します。 [接続要件](/platform/ja/configuring_nexthink/before-you-begin/technical-requirements/connectivity-requirements.md) のドキュメントを参照してください。 {% hint style="info" %} 有効化後、新しい設定が各アプリケーションレイヤーに反映され、Nexthink インスタンスが新しい認証プロセスに切り替わるまでに数分かかる場合があります。 {% endhint %}
**SSO configuration** タブを次のように設定します： 1. **SAML 2.0 authentication** スイッチをオンにします。 2. **Upload IdP metadata** セクションで、ID プロバイダーの情報を使用して各フィールドを設定します。 * **IdP Issuer URI**：ID プロバイダーの発行者 URI。通常、この値は ID プロバイダーの `EntityDescriptor` の SAML メタデータ `entityID` です。 * **IdP Single sign-on URL**：Nexthink インスタンスからの SAML `AuthnRequest` メッセージを受信する、バインディング固有の ID プロバイダー認証リクエストプロトコルエンドポイント。 Nexthink は `AuthnRequest` に HTTP-GET を使用します。 HTTP-POST ではなく HTTP-Redirect バインディングを選択してください。 * **IdP Signature Certificate**：SAML メッセージおよびアサーションの署名を検証するために使用する、ID プロバイダーの PEM または DER エンコードされた公開キー証明書。 Base64 エンコードされている必要があります。 3. Nexthink の `metadata.xml` ファイルをダウンロードし、ID プロバイダーで SSO アクセスを設定するために使用します。 4. SAML オプションを選択します。 SAML メッセージは、**bindings** と呼ばれる異なる方法で送信できます： * **HTTP Redirect** は、HTTP リダイレクト方式で SAML メッセージを送信します。コンテンツは URL パラメーターを使用して送信されます。これがデフォルトのオプションです。 * **HTTP POST** は、HTML フォームを使用して POST リクエスト経由で SAML メッセージを送信します。 SAML メッセージのコンテンツが大きすぎて URL パラメーターでは送信できない場合に、このオプションを選択します。 5. ユーザー情報を取得するために、ユーザーのプロビジョニング時に使用する **Attributes names** を設定します。 ID プロバイダーが、指定した名前でこれらの値を SAML 属性として送信するように設定する必要があります。 ID プロバイダーが Nexthink の名前に一致するカスタム属性名をサポートしていない場合は、次のように調整します： * **Group attribute**：ユーザーグループのリストを取得するための SAML 属性。 Nexthink にアクセスするには、ユーザーはユーザープロビジョニングセクションで定義されたグループに一致するグループに少なくとも 1 つ所属している必要があります。デフォルト値は `nexthink.groups` です。 * **Full name attribute**：ユーザーのフルネームを取得するための SAML 属性。デフォルト値は `nexthink.fullname` です。 * **Email address attribute**：ユーザーのメールアドレスを取得するための SAML 属性。デフォルト値は `nexthink.email` です。 * **Name ID format attribute**：名前の想定形式。一部の ID プロバイダーでは、`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 インターフェースへのログイン](/platform/ja/getting-started/logging-in-to-the-web-interface.md)のドキュメントを参照してください。 {% endhint %} ## SSO コンフィギュレーションの例 #### **ID プロバイダーとして Active Directory Federation Services（AD FS）を設定する** 1. Nexthink 管理者として、**Single sign-on** コンフィギュレーションページに移動し、**SSO Configuration** タブを選択します。 2. まだ有効になっていない場合は、**SAML 2.0 authentication** スイッチをオンにします。 3. メタデータ値を次のように設定します： * **IdP Issue URL** を `https:///adfs/services/trust/` に設定し、`` を AD FS サーバーの完全修飾ドメイン名（FQDN）に置き換えます。 * **IdP Single sign-on URL** を `https:///adfs/ls/` に設定し、`` を AD FS サーバーの完全修飾ドメイン名（FQDN）に置き換えます。 {% hint style="warning" %} AD FS メタデータによっては、値に `https` ではなく `http` が含まれる場合があります。 {% endhint %} 1. Nexthink の `metadata.xml` ファイルをダウンロードします。 2. 管理者として、AD FS を実行している Windows Server システムにログインします。 3. AD FS 管理コンソールを開きます。 4. **Relying Party Trusts** を右クリックし、**Add Relying Party Trust...** を選択して、信頼された証明書利用者を追加するウィザードを開始します。 * **Welcome** ステップで、**Claims aware** 証明書利用者を選択します。 * **Start** をクリックします。 * **Select Data Source** ステップで、**Import data about the relying party from a file** オプションを選択します。 * **Browse...** をクリックして、`metadata.xml` ファイルの場所を指定します。 * `metadata.xml` ファイルを選択し、**Open** をクリックします。 * **Next** をクリックします。 * **Specify Display Name** ステップで、証明書利用者に適切な名前を入力します。 * （任意）**Notes** に証明書利用者に関する追加情報を入力します。 * ウィザードの最後のステップに到達するまで、**Next** を繰り返しクリックして残りのステップをスキップします。 * **Close** をクリックしてプロセスを完了します。 5. 左側のツリーで **Relying Party Trusts** をクリックし、信頼された証明書利用者のリストを表示します。 6. 新しく追加した Nexthink Web インターフェースを表す信頼された証明書利用者のエントリを右クリックします。 7. コンテキストメニューから、要求発行ポリシーを編集するエントリを選択します： * Windows Server 2016 では、**Edit Claim Issuance Policy...** を選択します。 * Windows Server 2012 では、**Edit Claim Rules...** を選択します。 8. **Issuance Transform Rules** タブで **Add rule...** をクリックし、認証時に Nexthink Web インターフェースがユーザー名フィールドと照合する Name ID にユーザーの UPN をマッピングします。 * **Choose Rule Type** で、**Claim rule template** の **Send LDAP Attributes as Claims** を選択します。 * **Next** をクリックします。 * **Configure Claim Rule** では： * **Claim rule name** に、たとえば `Map UPN to Name ID` のような適切なルール名を入力します。 * **Attribute store** で **Active Directory** を選択します。 * **Mapping of LDAP attributes to outgoing claim types** で、**LDAP Attribute** に **User-Principal-Name**、**Outgoing Claim Type** に **Name ID** を選択します。 * **Finish** をクリックします。 9. **Issuance Transform Rules** タブに戻り、**Add rule...** をクリックして、メール形式の Name ID として UPN を送信する新しいルールを追加します。 * **Choose Rule Type** で、**Claim rule template** の **Transform an Incoming Claim** を選択します。 * **Next** をクリックします。 * **Configure Claim Rule** では： * **Claim rule name** に、たとえば `UPN as Name ID in email format` のような適切なルール名を入力します。 * **Incoming claim type** で **UPN** を選択します。 * **Outgoing claim type** で **Name ID** を選択します。 * **Outgoing name ID format** で **Email** を選択します。 * **Pass through all claim values** オプションはオンのままにします。 * **Finish** をクリックします。 10. 再度、**Issuance Transform Rules** タブで **Add rule...** をクリックして要求を追加します。 * **Choose Rule Type** で、**Claim rule template** の **Send LDAP Attributes as Claims** を選択します。 * **Next** をクリックします。 * **Configure Claim Rule** では： * **Claim rule name** に、たとえば `Nexthink claims` のような適切なルール名を入力します。 * **Attribute store** で **Active Directory** を選択します。 * **Mapping of LDAP attributes to outgoing claim types** で、**Token-Groups - Qualified by Domain Name** を選択し、**Outgoing Claim Type** として **Group** を選択します。 * 新しい行を追加し、**Mapping of LDAP attributes to outgoing claim types** で **Display-Name** を選択し、**Outgoing Claim Type** として **Surname** を選択します。 * 新しい行を追加し、**Mapping of LDAP attributes to outgoing claim types** で **E-Mail-Addresses** を選択し、**Outgoing Claim Type** として **E-Mail Address** を選択します。 * **Finish** をクリックします * **OK** をクリックします。 11. Nexthink Web インターフェースを表す信頼された証明書利用者のエントリを再度右クリックします。 12. メニューから **Properties** を選択します。証明書利用者のプロパティを確認および変更するためのダイアログボックスが表示されます。 * **Advanced** タブで、**Secure hash algorithm** に **SHA-256** を選択します。 * **OK** をクリックしてプロパティダイアログボックスを閉じます。 13. **Service** を展開して **Certificates** をクリックし、AD FS サーバーの署名証明書をダウンロードします。 **Token-signing** 証明書をダブルクリックし、**Details** タブに移動して **Copy to File...** をクリックし、証明書のエクスポートウィザードを開きます： * **Base-64 encoded X.509 (.CER)** を選択し、**Next** をクリックします。 * 後で使用するためにファイルを保存します。 14. Nexthink 管理者として Nexthink Web インターフェースに戻り、**Single sign-on** コンフィギュレーションページに移動して、**SSO Configuration** タブを選択します。 15. AD FS 管理コンソールから取得した署名証明書をアップロードします。 16. 属性値を以下のように設定します。 * **Group attribute** を `http://schemas.xmlsoap.org/claims/Group` に設定します。 * **Full name attribute** を `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` に設定します。 * **Email address attribute** を `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` に設定します。 * **Name ID format attribute** を `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` に設定します。 17. **Save** をクリックします。 18. 次に、[ユーザープロビジョニング](#singlesign-on-userprovisioninguserprovisioning)に関する手順に従います。 #### **ID プロバイダーとして Entra ID を設定する** 1. Nexthink 管理者として、**Single sign-on** コンフィギュレーションページに移動し、**SSO Configuration** タブを選択します。 2. まだ有効になっていない場合は、**SAML 2.0 authentication** スイッチをオンにします。 3. Nexthink サービスプロバイダーのメタデータファイル（metadata.xml）をダウンロードします。このファイルは後で使用します。 4. [Azure ポータル](https://portal.azure.com/)にログインします。 5. **Enterprise applications**、**New Application**、**Create your own application** の順にクリックします。 6. 右側の **Create your own application** パネルで、**Input** **Name** フィールドにアプリケーション名を入力します。たとえば、`Nexthink` と入力し、**Integrate any other application you don't find in the gallery (Non-gallery)** を選択します 7. **Set up a single sign on**、**SAML**、**Upload metadata file** の順にクリックします。 8. ページ左上にある **Upload metadata file** ボタンをクリックします。 9. `metadata.xml` ファイルを選択して保存します。 10. 二番目のタイルの右上にある鉛筆アイコンをクリックして、**Attributes & Claims** を編集します。要求を編集するページが表示されます。 * **Unique User Identifier** (Name ID) が、メール形式のユーザープリンシパル名 (UPN) であることを確認します： * **user.userprincipalname \[nameid-format:emailAddress]** 11. **Add a group claim** ボタンをクリックして、発行される SAML アサーションにユーザーグループを含めます。 * ユーザーに関連付けられたグループを要求で返すには、**Groups assigned to the application** を選択します。 * 返す **Source attribute** に **Group ID** を選択します。 * **Advanced options** で、**Customize the name of the group claim** をオンにします。 * **Name (required)** フィールドに `nexthink.groups` を使用します。 * **Save** をクリックして **User Attributes & Claims** ページに戻ります。 12. **Add new claim** ボタンをクリックして、発行される SAML アサーションにユーザーのフルネームを含め、**Manage user claims** ページを開きます。 * **Name** フィールドに `nexthink.fullname` を使用します。 * **Source** のタイプとして **Attribute** を選択します。 * **Source attribute** フィールドに `user.displayname` を使用します。 * **Save** をクリックします。 13. **Add new claim** ボタンをクリックして、発行される SAML アサーションにユーザーのメールアドレスを含め、**Manage user claims** を開きます。 * **Name** フィールドに `nexthink.email` を使用します。 * **Source attribute** フィールドに `user.mail` または `user.userprincipalname` を使用します。 * **Save** をクリックします。 14. **Login URL** と **Microsoft Entra Identifier** をメモします。これらは後で Nexthink インスタンスの SSO を設定するときに使用します。 15. **SAML Signing Certificate** ページの三番目のタイルで、最初のエントリである **Certificate (Base64)** に関連付けられた **Download** リンクをクリックします。 16. 後で Nexthink ロールにマッピングするため、Entra ID のグループ識別子を取得します。 * Azure ポータルのメインページに戻り、左側のパネルで **Microsoft Entra ID** をクリックします。 * **Manage** で **Groups** を選択します。アクティブなグループのリストが **Groups - All groups** ページに表示されます。 * Nexthink ロールにマッピングするグループを 1 つ選択します。 * ページの左側メニューで、**Manage** の **Properties** を選択します。 * **Properties** ページの **General settings** セクションで、**Object ID** フィールドの右にある紙のアイコンをクリックしてグループ識別子をコピーします。 * **Object ID** をテキストエディターなどに貼り付け、後で使用するために保存します。 * **Properties** ページ上部の **Discard** をクリックしてグループ選択に戻り、Nexthink ロールにマッピングする必要があるすべてのグループに対してこの操作を繰り返します。 17. Nexthink 管理者として Nexthink Web インターフェースに戻り、**Single sign-on** コンフィギュレーションページに移動して、**SSO Configuration** タブを選択します。 18. メタデータ値を次のように設定します： * **IdP Issue URI** を、先ほど取得した `Microsoft Entra Identifier` に設定します。 場合によっては、末尾に `/` 文字を追加する必要があります。 * **IdP Single sign-on URL** を、先ほど取得した `Login URL` に設定します。 19. Azure ポータルからダウンロードした IdP 署名証明書をアップロードします。 20. 属性値を次のように設定します： * **Group attribute** を `nexthink.groups` に設定します * **Full name attribute** を `nexthink.fullname` に設定します * **Email address attribute** を `nexthink.email` に設定します * **Name ID format attribute** を `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` に設定します 21. **Save** をクリックします。 22. 次に、[ユーザープロビジョニング](#singlesign-on-userprovisioninguserprovisioning)に関する手順に従います。 #### **汎用 SAML ID プロバイダーを設定する** 市場で利用可能なすべての SAML ID プロバイダーの設定手順を詳述することはできませんが、準拠プロバイダーの設定手順は上記の例と大きく異なることはありません。
メタデータエンティティ IDアサーションコンシューマーサービス（ACS）ACS バインディングNameID 形式

Nexthink 管理者として、Single sign-on コンフィギュレーションページに移動し、SSO Configuration タブを選択します。

まだ有効になっていない場合は、SAML 2.0 authentication スイッチをオンにします。

Nexthink の metadata.xml ファイルをダウンロードします。

metadata.xml ファイルを参照してください。metadata.xml ファイルを参照してください。metadata.xml ファイルを参照してください。urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
SSO の設定後、[ユーザープロビジョニング](#singlesign-on-userprovisioninguserprovisioning)に関する手順に従います。 ## 権限 シングルサインオン管理に適切な権限を有効にするには： * メインメニューから **Administration** を選択します。 * ナビゲーションパネルで **Role** をクリックします。 * **New Role** ボタンをクリックして新しいロールを作成するか、既存のロールにカーソルを合わせて編集アイコンをクリックし、ロール設定を変更します。 * **Permissions** セクションで **Administration** セクションまでスクロールし、**Administrator rights** を有効にします。 権限オプションの詳しい説明については、[ロール](/platform/ja/user-guide/administration/account-management/roles.md)のドキュメントを参照してください。 ## SSO（classic）からの移行 2023年3月15日より前に SSO を設定済みの場合、再度設定するよう求めるメッセージが表示されることがあります。 Classic SSO メカニズムのサポートは 2025年3月31日に終了するため、できるだけ早く設定を進めてください。 Nexthink Community にログインし、[Infinity Transition](broken://spaces/h7lLhrMjsSACP8jSdZ6s/pages/xck8Sgto9a7Ij30wlGg5#step-6-transition-to-the-cloud-native-single-sign-on-sso) ガイドで定義されている手順に従ってください。 *** 関連タスク * [監査証跡コードアプリケーション](/platform/ja/security/exporting-audit-logs.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.nexthink.com/platform/ja/user-guide/administration/account-management/single-sign-on.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.