ロール管理に関する FAQSummaryこの記事の目的は、ロールの問題に関連して ServiceNow テクニカルサポートに寄せられる一般的な要求/質問に回答することです。フォローアップの質問がある場合は、テクニカルサポートにお問い合わせください。 目次 Contextual Security: Role Management V2 プラグインをアクティブ化する前に考慮すべき重要な事項は何か?ユーザーのロールを削除できないのはなぜですか?このロールがどこから継承されたかはどうすればわかりますか?グループからロールを削除しましたが、まだアクセス権を持っているユーザーが表示されますか?インスタンスへのアクセスを許可するとセッションがロックされますが、セッションをロックしないようにこれを実行できますか?snc_internalロールとsnc_externalロールは何ですか?snc_internalロールとsnc_externalロールは充電可能ですか?管理者でもあるのに管理者ロールを付与できないのはなぜですか?グループまたはロールを削除するとトランザクションがタイムアウトしますか?g_user.hasRoles がユーザーに対して false を返すのはなぜですか?hasRoles() メソッドユーザーが実際の名前ではなくsys_idとして表示されていますか?sys_user_has_role、sys_group_has_role、sys_user_role_containsなどのテーブルでロールが空と表示されるのはなぜですか?License.role.testing というユーザーとは何か。削除されたレコードで毎日多数の削除が見つかるsys_user_has_role理由を教えてください。セキュリティ管理者がいないのはなぜですか? どうすればこのロールを元に戻すことができますか?[Elevate Role] が機能しなくなったのはなぜですか? Contextual Security: Role Management V2 プラグインをアクティブ化する前に考慮すべき重要な事項は何か? Role Management V2 プラグインは、正当な理由により、既存の顧客インスタンスに対してデフォルトでは有効になっていません。以前のロール管理システム (以降、レガシーと呼びます) と V2 メカニズムの間には大きな違いがあります。 従来のシステムでは、ユーザーは複数のレコードを使用してロールを付与できます。顧客のユーザー、グループ、およびロール構成の複雑さに応じて、明らかに重複する多数のレコードがユーザーに同じロールを付与されている場合があります。 従来のメカニズムでは、次の 3 つのフィールドを使用してロールの継承元を追跡するため、これらは実際には重複していません。 granted_by:ユーザーが継承したロールを持つ、ユーザーがメンバーであるグループincluded_in_role:ロールは別のロールから継承されており、これは親ロールのsys_user_has_role内のユーザーのレコードへの参照です。included_in_role_instance:ユーザーにこのロールを付与したsys_user_role_containsレコードへの参照 Role Management V2 プラグインが有効になると、3 つのフィールドはすべて廃止され、その内容はクリアされます (granted_byフィールドのコンテンツは [適用外] に変更されます)。これについては、「 エントリの防止 Contextual Security: Role Management V2 による重複エントリの防止」のドキュメントで説明されていますが、目的がよくわからない場合にのみ重複しているように見えるため、タイトルが誤解を招く可能性があります。 最も大きな影響は [granted_by] フィールドの廃止です。これは、多くのお客様がグループの管理や組織内のロールへのアクセスに関するカスタマイズで [] フィールドを使用しています。したがって、Role Management V2 プラグインが有効になっている場合、これらのカスタマイズが正しく機能しない可能性があります。 従来のメカニズムでは、これはsys_user_has_roleテーブルが非常に大きくなる可能性があることを意味します。これにより、sys_user_has_roleから多数のレコードを追加または削除する必要があるため、グループ/ロール関連の変更にかかる時間に影響する可能性があり、インスタンスのすぐに利用可能なロールが変更された場合にアップグレードにかかる時間に影響を与える可能性があります。 Role Management V2 メカニズムでは、ユーザーは 1 つのロールに対して最大で 2 つのレコードを持つことができます。1 つは直接付与されたロール用で、もう 1 つはロールがグループまたは他のロールから継承された場合です。継承されたロールでは、ロールが継承された回数を記録する新しいフィールドinh_count、テーブルにその数の個別レコードがある必要性を効果的に置き換えます。レコードが 1 つしかないため、[granted_by] フィールドはロールが属するグループを追跡しなくなり、代わりにロールがユーザーに委任された場合にのみ [granted_by] フィールドが使用されるのはこのためです。つまり、Role Management V2 プラグインがアクティブ化されると、sys_user_has_roleテーブルが大幅に小さくなる可能性があり、ロール関連の操作にメリットをもたらし、クローン作成とアップグレードの期間が長くなる可能性があります。 したがって、Role Management V2 プラグインを有効にする前に、評価を通じて、廃止された 3 つのフィールドのいずれかがインスタンスのカスタマイズで使用されているかどうかを判断する必要があります。 ユーザーのロールを削除できないのはなぜですか? ユーザーロール [sys_user_has_role] テーブルを見ると、「継承」列が表示されます。これは、このロールがロールまたはグループから継承されたことを意味します。これが false の場合、ロールは直接ユーザーにアサインされています。そのロールを削除する場合は、inherited = false の場合にのみレコードを削除できます。true の場合、ロールを直接削除することはできません。継承を削除する必要があるため、グループ/ロールからロールまたはユーザーを削除すると、継承されたすべてのレコードが更新され、そのアクセス権が削除されます。次のようなメッセージが表示されます。 一部のユーザーには、継承されたロールまたはグループを介してアクセス権が付与されています。[システムセキュリティ:グループ>]または正しいロールに移動して、ユーザーのアクセス権を削除してください。 このロールがどこから継承されたかはどうすればわかりますか? ロールが継承された場所を知りたい場合は、ユーザーロール [sys_user_has_role] のリストビューに [継承マップ] フィールドを追加できます。[ロール継承マップ] リンクをクリックすると、このロールがどのように継承されたかが表示されます。 この UI から、ロールの継承元を確認できます。 グループからロールを削除しましたが、まだアクセス権を持っているユーザーが表示されますか? これは、問題を検証するのに最適ないくつかのことである可能性があります。継承されていない場合は、ロール/ユーザーを直接削除する必要があります。継承されている場合はロール継承マップをクリックできます。マップが壊れているように見える場合は、無効な継承レコードであるため削除する必要があります。 この問題は、グループからロールを削除し、そのトランザクションがタイムアウトまたはキャンセルされたために、すべてのアクションが完全に完了しなかった場合に発生する可能性があります。これらの壊れた参照が表示された場合は、テクニカルサポートに連絡してください。 インスタンスへのアクセスを許可するとセッションがロックされますが、セッションをロックしないようにこれを実行できますか? これは非常によく聞かれる質問です。多数のユーザーにグループまたはロールへのアクセス権を付与すると、それらのロールを付与するのに時間がかかり、完了するまで現在のセッションがロックアウトされ、その間は何もできなくなります。 これには別の問題があり、セッションを使用している間、トランザクションは現在の UI クォータルール (デフォルトでは 298 秒) に従います。そのため、ロールを追加/削除するトランザクションに時間がかかりすぎると、トランザクションが完全には完了せず、インスタンス全体で参照とアクセスが壊れてしまいます。 これに対する解決策があります: フォアグラウンドジョブの代わりにバックグラウンドジョブを使用するようにロールとグループの許可を調整する方法 これは、セッションがロックされないことを意味し、トランザクションはバックグラウンド処理を使用するため、タイムアウトすることなく長時間実行でき、ユーザー/ロールの問題を修正する必要があります。 snc_internalロールとsnc_externalロールは何ですか? これらのロールはプラグイン「com.glide.explicit_roles」から取得され、インスタンスに新しいsnc_internalロールとsnc_externalロールを提供し、外部ユーザーが内部データにアクセスできないようにします。エンタープライズユーザー (従業員) には内部ロールが必要ですが、非エンタープライズユーザー (非従業員) には外部ロールが必要です。snc_internal:このロールは、すべての内部ユーザー (従業員または組織の内部) に割り当てられます。追加された新しいユーザーは、snc_external ロールがまだ割り当てられていない場合、初回のログイン/代理操作中にもこのロールを取得します。ロールのない既存のすべての ACL には、「snc_internal」ロールが適用されます。新しい ACL の場合、ACL がロールなしで保存されると、Now Platform によってこのロールが自動的に追加されます。 snc_external このロールは、ユーザーが組織の外部にあり、次の場合を除きリソースにアクセスできないことを示します。 snc_external ロールに対して ACL によるアクセスを明示的に許可している場合、または追加のロールを明示的に付与した場合。 デフォルトでは、snc_external ロールを持つユーザーは、プロセッサーや UI ページなどの非レコードタイプのリソースにもアクセスできません。[Reference (参照)] :https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/security/reference/explicit-role-plugin.html snc_internalロールとsnc_externalロールは充電可能ですか? これらは無料のロールであり、追加費用はかかりません。詳細については、 SNC 内部ロールと外部ロールを参照してください。 管理者でもあるのに管理者ロールを付与できないのはなぜですか? この問題は、admin ロールにアタッチされたスコープ対象のロールが原因である可能性があります。このロールにアクセスできない可能性があるため、この問題の原因となっている可能性があります。admin から継承されたロールを確認すると、自分自身にはないスコープ対象のロールが付与されている可能性があります。Newyork では、ロールを割り当てているユーザーが特権ロールであるか、特権ロールを含んでいるかがチェックされるという変更があります。特権ロールがある場合、ユーザーはその特権ロールを持っていない限りロールを追加できません。 このシナリオの 1 つはロールです。sn_templated_snip.template_snippet_admin は「admin」ロールに含まれており、このロールは特権ロールです。これが管理者にリンクされた理由は、この特定のアプリケーションを使用する際の問題を回避するためです。詳細情報はここにあります: 「admin」ロールに「sn_templated_snip.template_snippet_admin」ロールが含まれている場合、システムユーザーは「admin」ロールを追加できません。 グループまたはロールを削除するとトランザクションがタイムアウトしますか? ロール、グループ、および継承を変更すると、トランザクションが現在の UI クォータルール (デフォルトでは 298 秒) に従うという問題が発生します。そのため、ロールを追加/削除するトランザクションに 298 秒以上かかる場合、トランザクションはキャンセルされて完全には完了せず、インスタンス全体で参照とアクセスが壊れてしまいます。 これに対する解決策があります: フォアグラウンドジョブの代わりにバックグラウンドジョブを使用するようにロールとグループの許可を調整する方法 これは、セッションがロックされないことを意味し、トランザクションはバックグラウンド処理を使用するため、タイムアウトすることなく長時間実行でき、ユーザー/ロールの問題を修正する必要があります。 それ以外の場合は、スクリプトを使用してロール/グループを削除し、スクリプト (バックグラウンドまたは修正スクリプト) で実行できます。これはバックグラウンド処理も使用するため、298 秒のクォータルールはありません。 g_user.hasRoles がユーザーに対して false を返すのはなぜですか? g_user.hasRoles は、ユーザーが内部ロールを持っている場合でも false を返します。これは、ユーザーが外部ロールも持っているためです。ユーザーが snc_external や sn_customerservice.customer などのロールを「itil」などの他の内部ロールと組み合わせている場合でも、false が返されます。これは、インスタンスでは、ユーザーが外部ロールを持っているため、ロールがないと見なされるためです。 ここに記載されています。: https://docs.servicenow.com/bundle/rome-customer-service-management/page/administer/contextual-security/concept/explicit-roles-in-csm.html?cshalt=yes hasRoles() メソッド hasRoles() メソッドは引き続き使用できますが、Geneva リリースで廃止されました。代わりに hasRole(role name) メソッドを使用してください。 hasRoles() メソッドを使用する場合は、次の変更点に注意してください。 この方法では、ロールをチェックする際にデフォルトの snc_internal ロールが自動的に除外されます。つまり、ユーザーがsnc_internalロールのみを持っている場合でも、hasRoles() メソッドは false を返します。ユーザーがsnc_externalロールを持っている場合、インスタンスは外部ユーザーにロールがないと見なすため、メソッドは false を返します。 これは正常な動作です。snc_external または sn_customerservice.customer は、ユーザーが外部ユーザーであることを示すために使用される特別なロールです。定義上、外部ユーザーはインスタンスに対するロールを持たないため、外部ユーザーの getRoles() は常に false を返します。 ユーザーが実際の名前ではなくsys_idとして表示されていますか? これは、sys_idに対応するsys_user_roleエントリが削除されたか、インスタンスから欠落した結果です。いくつかの原因が考えられます。 sys_user_roleは削除されましたが、sys_user_role_containsまたはsys_group_has_roleに含まれているレコードとしてまだ存在します。含まれているロール (sys_group_has_role または sys_user_role_contains) は削除されましたが、UI トランザクションがタイムアウトし、孤立したsys_user_has_roleレコードが残ります。sys_user_has_roleには空の参照がありますが、上記の原因の 1 つが原因でないか、この空の参照が存在する理由が不明です。 これが上記の原因 1 による場合は、親グループまたはロールを編集し、(空の) 参照を削除できます。その後、空のsys_user_has_role参照が削除されます。これが原因 2 の場合は、「フォアグラウンドジョブの代わりにバックグラウンドジョブを使用するようにロールとグループの付与を調整する方法UI トランザクションがタイムアウトしないようにし、ロールまたはグループの変更を元に戻す/やり直す方法。含まれているロールではなく、直接付与されたロールである場合は、sys_user_has_roleから直接削除できます。これが明確でない場合 (原因 3)、さらにサポートや説明が必要な場合は、ServiceNow テクニカルサポートケースを作成してください。 参考: KB0781684 sys_user_has_role、sys_group_has_role、sys_user_role_containsなどのテーブルでロールが空と表示されるのはなぜですか? これは、sys_user_roleレコードが削除されて UI トランザクションがタイムアウトし、sys_user_has_role (フィールド:ロール)、sys_group_has_role (フィールド:ロール)、sys_user_role_contains (フィールド:ロールおよび含む) のフィールドに壊れた参照が残るため、前のエントリと似ています。 これらは管理者ユーザーが削除でき、これらのテーブルで適切なフィルターを使用して簡単に見つけることができます。同様の問題は、グループが削除され、トランザクションがタイムアウトした場合にsys_user_grmemberで発生する可能性があります。 壊れた参照を含むレコードはもはや役に立たないため、以下の参照記事で詳述されているように削除する必要があります。 参考: KB0860107 License.role.testing というユーザーとは何か。削除されたレコードで毎日多数の削除が見つかるsys_user_has_role理由を教えてください。 スケジュールされたアイテム UA ライセンスのダウンロード [毎日] は、Paris 以降の新しいライセンスフレームワークの一部であり、24 時間ごとに実行される本番インスタンスのライセンスチェックの一時ユーザー [license.role.testing] を作成します。新しい Paris ライセンスフレームワークでは、一時ユーザー [license.role.testing] が作成され、本番インスタンスライセンスチェックのすべてのロールがこのユーザーに割り当てられます。チェックが完了すると、このスケジュール済みジョブの実行時に、この一時ユーザーと [sys_user_has_role] 内のすべての関連レコードが 24 時間ごとに削除されます。この一時ユーザーの詳細については、KB0861074を参照してください。licensing.role.testing ユーザーとは何ですか?また、なぜそれがインスタンスにあるのですか? セキュリティ管理者がいないのはなぜですか? どうすればこのロールを元に戻すことができますか? セキュリティアドミンロールをインストールすると、システムアドミンアカウントにリンクされます。場合によっては、このアカウントが削除され、他のユーザーがこのロールを持たず、そのロールを持つ別のユーザーからのみセキュリティアドミンを付与できます。このような状況にある場合は、テクニカルサポートにケースを提出してください。アドミンアカウントを復旧し、セキュリティアドミンロールを付与します。 ロールがそのユーザーにのみアサインされている場合、ユーザーの削除を停止するルールがありますが、それでも削除が発生し、ロールが失われる可能性があります。 [Elevate Role] が機能しなくなったのはなぜですか? これは通常、アドミンのsys_user_roleレコードの調整にリンクされています。 管理者ロールを確認し、昇格された権限にチェックが入っているかどうかを確認します。その場合、予期しない動作が発生する可能性があります 詳細については、「 昇格された権限ロール」を参照してください。 警告:adminロールでの昇格された権限の使用はサポートされておらず、予期しない動作が発生する可能性があります。アドミニストレーターに手動での昇格を要求するには、次を参照してくださいアドミニストレーターに手動で昇格を強制。