グループ数の過多による ID プロバイダーからの同期への影響
このインサイトでは、ご利用のグループの総数が SCIM を使用する ID プロバイダーから同期できるグループ数の制限を超えているかどうかをチェックします。
グループ数が同期に及ぼす影響
Atlassian Cloud では、ID プロバイダーから単一のユーザー ディレクトリに同期できるグループの数が制限されています。グループ数が増えると、Jira のパフォーマンスとユーザーのアクションに影響する可能性があります。制限を超えるグループが存在する場合でも、(同じパフォーマンスの問題が発生するリスクがあるものの) グループを移行できますが、制限を超えるグループ (とそのユーザー) はクラウド側で同期/更新されません。
推奨事項
同期が正しく機能し、今後パフォーマンスの問題が発生しないように、グループの数を制限以下に減らす必要があります。それができない場合は、組織の制限を引き上げるようリクエストできます。
実行できるアクションは次のとおりです。
空または未使用のグループを削除する
プロジェクトで参照されているユーザーのみを移行する
クラウド側のユーザー プロビジョニング フィルターを変更する
制限を引き上げるようリクエストする
空のグループを削除する
空または未使用のグループを特定する
ダッシュボードからこの推奨事項を確認する際には、[View all groups in Jira (Jira のすべてのグループを表示)] を選択します。Jira インスタンスのユーザー管理ページに移動します。
または、[管理] > [ユーザー管理] > [グループ] に移動してもかまいません。
空または未使用のグループを削除する
空のグループを削除するには、次の手順に従います。
On the Groups page, review the groups that have 0 or few users.
削除できるグループのリストを作成します。
空のグループには、入れ子グループが含まれる場合があります。入れ子グループの上位レベルのコンテナーとして機能するという理由だけで、空として扱われます。このようなグループが必要な場合は削除しないようにしてください。
空または未使用のグループを Jira で直接削除できますが、グループがクラウドにプロビジョニングされないように、外部ディレクトリでも同じ変更を行う必要があります。
Migrate only users referenced in projects
Jira Cloud Migration Assistant でプロジェクトを移行する際には、それらのプロジェクトで参照されているユーザーのみを移行し、他のユーザーはすべて除外するという選択肢があります。
移行を実行しなくても、参照されているユーザーとグループの数を確認して、除外できるユーザーの数を把握できます。
選択したプロジェクトで参照されているユーザーのみを移行する
移行計画にプロジェクトを追加した後に、参照されているユーザーを移行することもできます。
参照されているユーザーのみを移行するには、次の手順に従います。
Jira Cloud Migration Assistant で新しい移行計画を作成します。
方法として [移行する内容を選択] を選択して、データを手動で選択できるようにします。
[プロジェクト] カードで、計画に含めるプロジェクトをいくつか選択します。
[ユーザーとグループ] カードで、[選択されたプロジェクトに関連するユーザーとグループのみ] オプションを選択します。選択できるオプションの詳細をご確認ください。
You can skip selecting data in other cards, such as Roadmap plans or Apps.
参照されているユーザーとグループの数を確認する
参照されているユーザーとグループの数は、移行前レポートで確認できます。
移行前のレポートをダウンロードするには、次の手順に従います。
1. Continue through the pre-migration checks until you reach the Review your migration screen.
2. In the Logs and reports tab, download the pre-migration report.
3. Extract the archive, and look at the following files:
Summary: このファイルには、移行対象のユーザーとグループの数が含まれています。Users and groups: このファイルには、参照されているユーザーとグループ、およびそれらを参照しているプロジェクトの詳細が含まれています。
クラウドに実際に必要なユーザー数を把握するために、移行するすべてのプロジェクトでこれらの手順を繰り返します。移行前レポートを確認する際には、参照されているユーザーとグループのリストを作成して、クラウド側のプロビジョニングおよび同期フィルターから除外できるようにします。
クラウド側のユーザー プロビジョニング フィルターを変更する
ユーザー プロビジョニングと同期フィルターの構成方法によっては、不要になったユーザーやログインすらしていないユーザーなど、必要以上に多くのユーザーやグループを同期している可能性があります。
これを回避する方法の例は次のとおりです。
LDAP (サーバー) または SCIM (クラウド) のフィルターを変更して、不要になった、またはその他の推奨事項で修正されたユーザーやグループを除外します
Jira ディレクトリだけでなく、外部ディレクトリのユーザーやグループも変更します。これにより、更新または削除されたユーザーやグループがクラウドにプロビジョニングされなくなります
Atlassian Cloud の SCIM フィルター
外部ディレクトリを Atlassian Cloud に直接接続することはできません。間で ID プロバイダーを使用する必要があります。フィルターを変更する場合は、ID プロバイダーで行う必要があります。
Microsoft でこれを行う方法についてのアイデアは次のとおりです。
これは Atlassian Cloud を ID プロバイダーに接続するためのドキュメントです。Okta のように、この接続を設定する際に同期するユーザーを指定できるものもあります。
OneLogin: OneLogin のユーザー プロビジョニングを構成する方法をご確認ください。
Azure AD: Azure AD のユーザー プロビジョニングを構成する方法をご確認ください。
Google Cloud: Google Cloud を使用してユーザー プロビジョニングを構成する方法をご確認ください。
Google Workspace: Google Workspace のユーザー プロビジョニングを構成する方法をご確認ください。
PingFederate: PingFederate のユーザー プロビジョニングを構成する方法をご確認ください。
JumpCloud: JumpCloud のユーザー プロビジョニングを構成する方法の詳細
Data Center の LDAP フィルター
クラウド側でフィルターを更新する方が重要ですが、Data Center でも更新できます。これにより、一部のユーザーをより簡単に削除 (たとえば、Jira にコンテンツがないユーザーは、同期から除外された後に自動的に削除されます) する、既存のユーザー ベースでいくつかの変更を試すなどができます。
制限を引き上げるようリクエストする
制限数を下回るように調整できないお客様に対しては、アトラシアン側で対象組織の制限を手動で引き上げています。このオプションはパフォーマンスに影響する可能性があるため、最後の手段として利用してください。
引き上げをリクエストする前に、必ず次のリスクを承諾してください。
パフォーマンスの問題
ユーザー インターフェイスの問題
ユーザー エクスペリエンスの問題
大規模なグループへの権限適用に関する問題
制限を引き上げるには、問い合わせフォームで [技術的な問題やバグ] を選択し、次のデータを添えてクラウド サポート宛てのサポート チケットを起票してください。
ユーザー制限の例外リクエスト
制限超過: ユーザー数、グループ数、またはグループあたりのユーザー数
結果: 現在のグループ数
確認: リスクを受け入れ、制限の引き上げの実行を確定します。
この内容はお役に立ちましたか?