ロール管理の 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削除されたレコードで大量の削除が見つかるのか?セキュリティアドミンがいないのはなぜですか? どうすればこのロールを元に戻すことができますか?「ロールの昇格」が機能しなくなったのはなぜですか?ユーザーロール管理にアクセスする方法は? Contextual Security: Role Management V2 プラグインを有効にする前に考慮すべき重要な考慮事項は何ですか? ロール管理 V2 プラグインは、正当な理由により、既存の顧客インスタンスに対してデフォルトで有効になっていません。以前のロール管理システム (以下、レガシーと呼びます) と V2 メカニズムの間には大きな違いがあります。 従来のシステムでは、ユーザーはロールを付与する複数のレコードを持つことができます。顧客のユーザー、グループ、およびロール構成の複雑さによっては、明らかに重複しているレコードが多数あるユーザーに同じロールが付与されることを意味します。 従来のメカニズムでは 3 つのフィールドを使用してロールの継承元を追跡するため、これらは実際には重複していません。 granted_by:ユーザーが継承したロールを持つ、ユーザーがメンバーであるグループincluded_in_role:ロールは別のロールから継承されており、これは親ロールの sys_user_has_role にあるユーザーのレコードへの参照ですincluded_in_role_instance:このロールをユーザーに付与したsys_user_role_containsレコードへの参照 ロール管理 V2 プラグインがアクティブ化されると、3 つのフィールドはすべて廃止され、その内容はクリアされます (granted_byフィールドの内容は「該当なし」に変更されます)。これについては、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] テーブルを見ると、「inherited」列が表示されます。これは、このロールがロールまたはグループから継承されたことを意味します。これが 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 ページなどの非レコードタイプのリソースにもアクセスできません。情報元 :https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/security/reference/explicit-role-plugin.html ロールはsnc_internalおよびsnc_external充電可能ですか? これらは無料のロールであり、追加コストはかかりません。詳細については、 SNC 内部ロールと外部ロール。 自分もアドミンである場合にアドミンロールを付与できないのはなぜですか? この問題は、admin ロールに添付されたスコープ対象ロールが原因で発生する可能性があり、このロールにはアクセス権がない可能性があります。これがこの問題の原因です。管理者から継承されたロールを見ると 自分自身には付与されないスコープ対象のロールがあるかもしれませんNew York では、ロールをアサインするユーザーが特権ロールであるか、または特権ロールが含まれているかがチェックされるという変更があります。特権ロールがある場合、ユーザーはその特権ロールを持っていない限り、そのロールを追加できません。 このシナリオの 1 つは、ロールです。sn_templated_snip.template_snippet_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 によるものである場合は、親グループまたはロールを編集して、(空の) 参照を削除できます。その後、空の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] を作成し、本番インスタンスライセンスチェックのすべてのロールをこのユーザーに割り当てます。チェックが完了すると、このスケジュール済みジョブが実行されると、24 時間に 1 回、この一時ユーザーと [sys_user_has_role] 内のすべての関連レコードが削除されます。この一時ユーザーの詳細については、KB0861074を参照してください。licensing.role.testing ユーザーとはどのようなもので、なぜインスタンスに存在するのか? セキュリティアドミンがいないのはなぜですか? どうすればこのロールを元に戻すことができますか? セキュリティアドミンロールをインストールすると、システムアドミニストレーターアカウントにリンクされます。このアカウントが削除されると、他のユーザーがこのロールを持っていなくなり、そのロールを持つ別のユーザーからのみセキュリティアドミンを付与されてしまうことがあります。このような状況にある場合は、テクニカルサポートにケースを提出してください。アドミンアカウントを復旧し、セキュリティアドミンロールを付与します。 ロールがそのユーザーにのみ割り当てられている場合、ユーザーの削除を停止するルールがありますが、それでも削除は発生し、ロールが失われる可能性があります。 「ロールの昇格」が機能しなくなったのはなぜですか? これは通常、アドミンのsys_user_roleレコードの調整にリンクされています。 admin ロールを確認し、昇格した権限がチェックされているかどうかを確認します。その場合、予期しない動作が発生する可能性があります 詳細については、以下を参照してください。 昇格 昇格された権限ロール 警告:admin ロールで昇格した権限の使用はサポートされていないため、予期しない動作が発生する可能性があります。管理者に手動での昇格を要求するには、「アドミニストレーターに手動での昇格を強制します。 ユーザーロール管理にアクセスする方法は? ServiceNow のユーザーロール管理では、ユーザーにロールをアサインして、プラットフォーム内の機能やデータへのアクセスを制御します。これにより、ユーザーがタスクに対する適切な権限を持つようになり、セキュリティが強化され、ワークフローが合理化されます。ロールは通常、ServiceNow のメインブラウザーウィンドウの [User Administration] > Users モジュールからアサインされます。 ユーザー、ロール、グループを sys_user - ユーザー レコード sys_user_group - グループ sys_user_role:ロール。 これで、ユーザーとグループ/ロール間のリンクが次のようになります。sys_user_grmember - グループにリンクされたユーザー sys_user_has_role:ロールにリンクされたユーザーRelease.