ロール管理の FAQSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } この記事の目的は、ロールの問題に関連して 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レコードへの参照 Role Management V2 プラグインが有効になると、3 つのフィールドはすべて廃止され、その内容はクリアされます (granted_by フィールドの内容は「not-applicable」に変更されます)。これについては、「Contextual Security: Role Management V2 による重複エントリの防止」ドキュメントで説明されています。ただし、これらのエントリはその目的を理解していない場合にのみ重複しているように見えるため、このタイトルは誤解を招く可能性があります。 最も大きな影響は、granted_byフィールドが廃止されたことです。これは、多くのお客様がこのフィールドをグループの管理と組織内のロールへのアクセスに関するカスタマイズに使用しているためです。したがって、Role Management V2 プラグインがアクティブ化されている場合、これらのカスタマイズが正しく機能しない可能性があります。 従来のメカニズムでは、sys_user_has_roleテーブルが非常に大きくなる可能性があり、多数のレコードを追加または削除する必要がある場合があるため、グループ/ロール関連の変更にかかる時間に影響を与える可能性があり、インスタンスのすぐに利用可能なロールに変更がある場合はアップグレードにかかる時間に影響を与える可能性があります。 Role Management V2 メカニズムでは、ユーザーは 1 つのロールに対して最大 2 つのレコードを持つことができます。1 つは直接付与されたロール用で、もう 1 つはグループまたは他のロールからロールが継承されている場合です。継承されたロールでは、新しいフィールド inh_count でロールが継承された回数が記録されるため、テーブルにその数の個々のレコードを含める必要がなくなります。レコードが 1 つしかないため、granted_byフィールドはロールの所属グループを追跡しなくなり、代わりにgranted_byフィールドはロールがユーザーに委任された場合にのみ使用されます。つまり、ロール管理 V2 プラグインがアクティブ化されると、sys_user_has_roleテーブルが大幅に小さくなり、ロール関連の操作にメリットがもたらされ、クローン作成とアップグレードの期間が短縮される可能性があります。 したがって、Role Management V2 プラグインをアクティブ化する前に、徹底的な評価を実行して、3 つの廃止されたフィールドのいずれかがインスタンスのカスタマイズで使用されているかどうかを判断する必要があります。 また、sys_user_has_roleテーブル内のデータの管理は、ビジネスルールとスクリプトインクルードの組み合わせから離れ、GlideRecord が動作するよりも低い永続レイヤーで処理されるため、sys_user_grmember などのテーブルにスクリプトを介して変更を加えたときにビジネスルールを無効にしても、sys_user_has_role テーブルへの変更の伝播を防ぐことはできません。関連するビジネスルールおよび RoleManagement スクリプトインクルードの一部は、RoleManagement V2 プラグインがアクティブかどうかをチェックし、アクティブである場合は何も実行せず、下位レベルのロール管理リスナーに委ねます。 ユーザーのロールを削除できないのはなぜですか? ユーザーロール [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://www.servicenow.com/docs/csh?topicname=explicit-roles-plugin.html&version=latest snc_internal ロールと snc_external ロールは課金対象ですか? これらは無料のロールであり、追加費用はかかりません。詳細情報はSNC 内部ロールと外部ロールを参照してください。 自分がアドミンである場合、アドミンロールを付与できないのはなぜですか? この問題は、admin ロールに関連付けられたスコープ対象のロールに起因する可能性があります。そのロールへのアクセス権がないことが原因です。したがって、admin から継承されたロールを確認すると、ご自身が持っていないスコープ付きロールがある可能性があります。New York リリースでは、割り当てるロールが特権ロールであるか、特権ロールを含んでいるかをシステムがチェックする変更が導入されています。割り当てるロールに特権ロールが含まれている場合、ユーザーはその特権ロールを自身が持っていない限りロールを追加できません。 このシナリオの 1 つは、「admin」ロールに含まれるロール 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://www.servicenow.com/docs/csh?topicname=explicit-roles-in-csm.html&version=latest hasRoles() メソッド hasRoles() メソッドは引き続き使用できますが、Geneva リリースで廃止されました。代わりに hasRole(role name) メソッドを使用してください。 hasRoles() メソッドを使用する場合は、次の変更点に注意してください。 このメソッドでは、ロールをチェックする際にデフォルトの snc_internal ロールが自動的に除外されます。つまり、ユーザーが snc_internal ロールのみを持っている場合でも、hasRoles() メソッドは false を返します。ユーザーがsnc_externalロールを持っている場合、インスタンスは外部ユーザーがロールを持たないと見なすため、このメソッドは false を返します。 この動作は想定どおりです。snc_externalまたは sn_customerservice.customer は、ユーザーが外部ユーザーであることを示すために使用される特別なロールです。定義上、外部ユーザーにはインスタンスに対するロールがないため、外部ユーザーの hasRoles() は常に 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)、またはさらに支援や説明が必要な場合は、テクニカルサポートにケースを提出してください。 参照: 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 Licensing Framework では、一時ユーザー [license.role.testing] が作成され、本番インスタンスのライセンスチェックのためにこのユーザーにすべてのロールが割り当てられます。チェックが完了すると、このスケジュール済みジョブが実行される 24 時間に 1 回、この一時ユーザーと [sys_user_has_role] 内のすべての関連レコードが削除されます。この一時ユーザーの詳細については、次のKB0861074を確認してください。licensing.role.testing ユーザーとは何ですか?なぜそれが自分のインスタンスにあるのですか? セキュリティアドミンロールがないのはなぜですか?このロールを取り戻すにはどうすればよいですか? セキュリティアドミンロールがインストールされると、システムアドミンアカウントにリンクされます。このアカウントが削除されることがあり、その場合、このロールを持つ他のユーザーがいなくなります。セキュリティアドミンは、そのロールを持つ別のユーザーからのみ付与できます。このような状況に陥った場合は、テクニカルサポートにケースを提出してください。アドミンアカウントを回復し、セキュリティアドミンロールを付与します。 ロールがそのユーザーにのみ割り当てられている場合にユーザーの削除を防止するルールがありますが、それでも削除が発生し、ロールが失われる可能性があります。 「ロールの昇格」が機能しなくなったのはなぜですか? これは通常、admin の sys_user_role レコードの調整に関連しています。 admin ロールを確認し、昇格された権限がオンになっているかどうかを調べます。オンになっている場合、予期しない動作が発生する可能性があります。 詳細については、「昇格された権限のロール」を参照してください。 警告: admin ロールで昇格した権限の使用はサポートされていないため、予期しない動作が発生する可能性があります。アドミニストレーターに手動での昇格を要求するには、「アドミニストレーターに手動での昇格を強制する」を参照してください。 ユーザーロール管理にアクセスするにはどうすればよいですか? ServiceNow のユーザーロール管理では、ユーザーにロールを割り当てて、プラットフォーム内の機能やデータへのアクセスを制御します。これにより、ユーザーは自分のタスクに対する適切な権限を持つことが保証され、セキュリティが強化され、ワークフローが簡素化されます。ロールは通常、ServiceNow のメインブラウザーウィンドウの[ユーザー管理] > [ユーザー] モジュールを介してアサインされます。 以下からユーザー、ロール、グループを管理できます。 sys_user - ユーザーレコード sys_user_group:グループ sys_user_role:ロール ユーザーとグループ/ロール間のリンクは次のテーブルにあります。sys_user_grmember:グループにリンクされているユーザー sys_user_has_role:ロールにリンクされたユーザー Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } .