グループあたりのユーザー数の過多による ID プロバイダーからの同期への影響

このインサイトでは、ご利用のグループが SCIM を使用する ID プロバイダーから同期できるユーザー数の制限を超えているかどうかをチェックします。これにはネストされたグループのユーザーも含まれます。こうしたグループは移行中にフラット化され、親グループのサイズが大きくなるからです。 

ユーザー数が同期に及ぼす影響

Atlassian Cloud では、IdP から単一のグループに同期できるユーザーの数に制限があります。グループのユーザー数が増えるほど、Jira のパフォーマンスやユーザーのアクションに影響したり、権限を適用する際に問題が発生したりする可能性があります。ユーザー数が制限を超えるグループが存在する場合でも、(同じパフォーマンスの問題が発生するリスクがあるものの) ユーザーを移行できますが、制限を超えているユーザーはクラウド側で同期/更新されません。

クラウド ユーザー プロビジョニングの制限の詳細を確認する

入れ子グループのユーザーが含まれる理由

Atlassian Cloud では入れ子グループはサポートされていません。外部ディレクトリでは入れ子構造を維持できますが、クラウドに配置する前にフラット化する必要があります。クラウドでは、すべてのグループのレベルが同じになります。

フラット化は次の 2 つの場合に行われます。

• 移行: 移行すると、移行アシスタントによってすべての入れ子グループがフラット化されます。

• IdP からの同期: ほとんどの IdP ではフラット化がネイティブにサポートされています。その場合は、すでにフラット化された構造を同期します。Microsoft Azure AD など、それ以外の IdP 向けには、同期時に入れ子グループをフラット化するカスタム統合が用意されています。

フラット化すると、入れ子グループのすべてのユーザーが親グループの直接のメンバーになり、親グループのサイズが大きくなります。制限に対して結果の入れ子グループのユーザーがカウントされるのは、そのためです。

IdP から同期する場合の仕組みの例を次に示します (移行も同じように機能します)。

入れ子グループとフラット化の詳細を確認する

推奨事項

同期が正しく機能し、今後パフォーマンスの問題が発生しないように、対象のグループのユーザーの数を制限以下に減らす必要があります。それができない場合は、組織の制限を引き上げるようリクエストできます。

Review affected groups

SQL クエリを使用する

ダッシュボードからこの推奨事項を確認する際には、SQL クエリをコピーしてデータベースで実行します。

クエリによって次の情報が返されます。

• Names of groups with 35k or more users

• グループごとのユーザー数

評価パッケージのグループ ID を確認する

ダッシュボードにアップロードする評価パッケージには、対象のグループに関する情報も含まれています。ただし、含まれているのはグループ ID とユーザー数だけです。

このデータを表示するには、次の手順に従います。

1. ダッシュボードにアップロードした評価パッケージを展開します。

2. Open the jira-entitires-[date].csv file.

3. GROUPS_WITH_35K_OR_MORE_USER_MEMBERSHIPS エンティティを検索します。

4. In the query_result column, you’ll see the list of groups in the JSON format. The syntax is groupId: userCount, and looks similar to the one below:

一度もログインしていないユーザーを削除する

ダッシュボードからこのインサイトを確認する際には、データベースからログインしたことがないユーザーのリストを返す SQL クエリをコピーできます。

SQL クエリを使用してユーザーを確認する

SQL クエリでユーザーのリストを取得するには、次の手順に従います。

1. ダッシュボードから SQL クエリをコピーしてデータベースで実行します。

2. 返されたユーザーのリストを確認し、削除する準備を行います。

3. ユーザーを削除します。

   1. 手動で削除するには、[管理] > [ユーザー管理] に移動します。

   2. より適切な方法は、対象のユーザーをプロビジョニングおよび同期フィルターから除外することです。ユーザーが Jira にコンテンツやアクティビティをまったく持っていない場合、フィルターを変更すると自動的に削除されます。

ユーザーを手動で確認する

このようなユーザーを Jira で確認することもできますが、そのためには手動で確認する必要があり、数が多い場合は最適な選択肢ではありません。

Jira でユーザーを確認するには、次の手順に従います。

1. [管理] > [ユーザー管理] に移動します。

2. [ログインの詳細] でユーザーを確認します。[ログイン履歴なし] または [最終ログイン] の日付を確認します。

ユーザー管理ページでのフィルタリング

ユーザー管理ページの次のフィルターを使用すると、削除する候補を見つけやすくなります。

• [ステータス]: [非アクティブ]: 非アクティブ化されたユーザーが返されますが、ログインしたことがないユーザーまたは長期間ログインしていないユーザーは返されません。

• [アプリケーション アクセス]: [なし]: Jira にアクセスできないユーザーが返されます。移行後もアクセスできなくなり、ライセンスにはカウントされません。

ユーザーを削除する

ユーザーは次のいずれかの方法で削除できます。

• 外部ディレクトリのユーザーを直接削除します。これにより、移行後にクラウドにプロビジョニングされなくなります。

• プロビジョニング フィルターと同期フィルターからユーザーを除外します。ユーザーが Jira にコンテンツを持っていない場合、ユーザーは Jira の内部ディレクトリから自動的に削除されます。

• Manually delete users from the User management page. Note that if you delete users only in the Jira internal directory, they might be later provisioned to cloud, which is something you want to avoid.

Fix invalid and duplicated emails (former users and merge)

移行アシスタントでユーザー評価を実行して、無効なメール アドレスや重複するメール アドレスを持つユーザーを見つけることができます。このようなメールを持つユーザーは移行を妨げるため、とにかく修正する必要があります。

ユーザー評価を実行して、不適切なメールを持つユーザーを特定する

ユーザー評価を実行するには、次の手順に従います。

1. [管理] > [クラウドに移行] に移動して、Jira Cloud Migration Assistant を開きます。

2. ホーム画面で、[ ユーザーを評価して準備する] カードを見つけて [ 評価を開始] を選択します。

3. 評価が完了すると、不適切なメールを持つユーザーの数が表示されます。

結果には、無効なメール アドレスまたは重複するメール アドレスを持つユーザーの数が表示されます。これらのユーザーは削除の候補になりますが、確認が必要です。

該当するユーザーを旧ユーザーとして移行して、無効なメールを修正する

無効なメールを持つユーザーを修正するには、次の手順に従います。

1. 評価結果を確認する際には、[Fix invalid emails (無効なメールを修正)] を選択します。

2. ユーザーを修正するための自動オプションがいくつか表示されます。[ユーザーを CSV ファイルに基づいて更新] を選択し、CSV ファイルをダウンロードします。

CSVファイルを編集する方法

CSV ファイルには、無効なメールを持つすべてのユーザーが含まれています。詳細な説明は readme ファイルに記載されています。

ユーザーを旧ユーザーとして扱ってユーザー数を減らすには、次の手順に従います。

1. 非アクティブ化できる各ユーザーについて、Tombstone の値を true に変更します。

2. 維持するユーザーについて、メール アドレスを機能しているものに変更します。

3. ファイルを保存して、移行アシスタントにアップロードします。

該当するユーザーをマージして、重複するメールを修正する

無効なメールを修正したら、[Fix duplicated emails (重複するメールを修正)] を選択します。同じような画面に移動し、重複するメールを持つユーザーを修正できます。

重複するメールを持つユーザーをマージするには、次の手順に従います。

1. [Merge duplicate users (重複するユーザーをマージ)] オプションを選択します。

変更を確認し、変更されたユーザーのリストを作成する

無効なメールや重複するメールを修正するオプションを選択したら、[Review and apply (確認して適用)] を選択します。

信頼できないドメインのユーザーを削除する

移行アシスタントでドメイン評価を実行して、ユーザーが使用しているすべてのメール ドメインを特定できます。これは、見覚えのないドメインや信頼できないドメイン、または疑わしくてアトラシアンによってブロックされているドメインを見つけるのに役立ちます。

ドメイン評価を実行する

ドメイン評価を実行するには、次の手順に従います。

1. [管理] > [クラウドに移行] に移動して、Jira Cloud Migration Assistant を開きます。

2. ホーム画面で、[ドメインを確認] カードを見つけて [評価を開始] を選択します。

3. 評価が完了すると、ユーザー ディレクトリにあるメール ドメインのリストが表示されます。

For every domain, you can select the number in Active / Inactive users to view the filtered list of users in Jira.

ブロックされているドメインを確認する

アトラシアンでは、不審なドメインを見つけたらブロックしています。まず、このようなドメインがあるかどうかを確認してください。これらのドメインのユーザーは削除の候補として最も妥当です。

これらのドメインのユーザー数を選択して、表示したり削除したりできます。このようなユーザーは Jira で削除できますが、外部ディレクトリから削除したり、プロビジョニング フィルターから除外したりする必要もあります。

残りのドメインを確認する

残りのドメインについては、ユーザー インターフェイスで確認するか、CSV ファイルをダウンロードして確認できます。移行アシスタントでは、すべてのドメインを信頼できるドメインとしてマークする必要があります。見覚えのないドメインや信頼できないドメインを見つけたら、そのユーザーを削除して、ドメインがリストから消えるようにする必要があります。

これらのドメインのユーザー数を選択して、表示したり削除したりできます。このようなユーザーは Jira で削除できますが、外部ディレクトリから削除したり、プロビジョニング フィルターから除外したりする必要もあります。

メール ドメインの確認に関する詳細を確認する

Migrate only users referenced in projects

Jira Cloud Migration Assistant でプロジェクトを移行する際には、それらのプロジェクトで参照されているユーザーのみを移行し、他のユーザーはすべて除外するという選択肢があります。

移行を実行しなくても、参照されているユーザーとグループの数を確認して、除外できるユーザーの数を把握できます。

選択したプロジェクトで参照されているユーザーのみを移行する

移行計画にプロジェクトを追加した後に、参照されているユーザーを移行することもできます。

参照されているユーザーのみを移行するには、次の手順に従います。

1. Jira Cloud Migration Assistant で新しい移行計画を作成します。

2. 方法として [移行する内容を選択] を選択して、データを手動で選択できるようにします。

3. [プロジェクト] カードで、計画に含めるプロジェクトをいくつか選択します。

4. [ユーザーとグループ] カードで、[選択されたプロジェクトに関連するユーザーとグループのみ] オプションを選択します。選択できるオプションの詳細をご確認ください。

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 でこれを行う方法についてのアイデアは次のとおりです。

• Microsoft でプロビジョニングされるユーザーとグループのスコープ設定

これは Atlassian Cloud を ID プロバイダーに接続するためのドキュメントです。Okta のように、この接続を設定する際に同期するユーザーを指定できるものもあります。

• Okta: 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 にコンテンツがないユーザーは、同期から除外された後に自動的に削除されます) する、既存のユーザー ベースでいくつかの変更を試すなどができます。

LDAP から Jira に同期されるユーザーの数を減らす

制限を引き上げるようリクエストする

制限数を下回るように調整できないお客様に対しては、アトラシアン側で対象組織の制限を手動で引き上げています。このオプションはパフォーマンスに影響する可能性があるため、最後の手段として利用してください。

引き上げをリクエストする前に、必ず次のリスクを承諾してください。

• パフォーマンスの問題

• ユーザー インターフェイスの問題

• ユーザー エクスペリエンスの問題

• 大規模なグループへの権限適用に関する問題

制限を引き上げるには、移行サポート宛てにサポート チケットを起票するか、MOVE チケットに次のデータを添えてコメントを残してください。