管理対象アカウントのメール アドレス一括変更を予定
プラットフォームについて: Cloud のみ - この記事は クラウド プラットフォームのアトラシアン製品に適用されます。
目的
会社のリブランディングや合併などの特定の変更が発生すると、多数のエンド ユーザーのメール アドレスの更新が必要になります。メール アドレスの変更は、クラウド内のエンド ユーザーの Atlassian アカウントにも適用し、新しいメール アドレスでデータに引き続きアクセスできるようにする必要があります。一般的なユース ケースを次に挙げます。
会社が別の会社と合併することになり、メール アドレスのドメインを変更する必要があります (つまり、user@companyA.com → user@companyB.com)。
エンド ユーザーのメール アドレスの形式を切り替えます(つまり、abc123@company.com → firstname.lastname@company.com )。
背景
クラウド製品の製品アクセスと履歴データは、特定のメール アドレスではなく、Atlassian アカウントにリンクされています。各 Atlassian アカウントは、一意 (不変) の ID とメール アドレスで識別されます。Atlassian アカウントのメール アドレスが更新されても、エンド ユーザーは新しいメール アドレスで既存の製品アクセスとデータを引き続き使用できます。
メール アドレスは、一度に Atlassian Cloud の 1 つの Atlassian アカウントでのみ使用できます。アカウントのメール アドレスを変更するには、ターゲットのメール アドレスが別の Atlassian アカウントで使用されていてはなりません。
管理者および ID プロバイダーが Atlassian アカウントのメール アドレスを変更できるのは、メール アドレスのドメインが検証され、Atlassian アカウントが 1 つの組織内で申請された場合のみです。
ID プロバイダーに Atlassian Access が設定されている場合、メール アドレスの変更は、SAML-SSO とユーザー プロビジョニングを介して ID プロバイダーから Atlassian Cloud に反映されます。
SAML-SSO を設定するには、「ID プロバイダーを使用して SAML シングル サインオンを設定する」のガイドに従ってください。
ユーザー プロビジョニングを設定するには、「ユーザー プロビジョニングについて 」のガイドに従ってください。
プロビジョニングによって ID プロバイダーにリンクされた管理対象アカウントは、アトラシアン側で編集できないようにロックされます。Atlassian アカウントのメール アドレスは、ID プロバイダーを介してのみ更新できます。
Prerequisites
ソースとターゲットのメール アドレスのドメインは、同じ Atlassian Cloud 組織内で申請されている必要があります。
ターゲットのメール アドレスを保持している可能性のある Atlassian アカウントをクリーンアップします。
- 利用するターゲット メール アドレスのリストを生成します (つまり、ID プロバイダーから取得)
https://admin.atlassian.com に移動します。
組織の管理対象アカウントの管理画面を開きます。
アカウントをエクスポートします。
ターゲット メール アドレスをすでに使用している Atlassian アカウントがあるかどうかを確認します。ID プロバイダーのターゲット メール アドレスのリストと管理対象アカウントのエクスポートを比較します。
ターゲット メール アドレスが別の Atlassian アカウントですでに使用されている場合は、競合するアカウントのメール アドレスを別のものに変更します (つまり、targetemail_FREE@domain.com)。
メール アドレスは、管理対象アカウントの管理 Web インターフェイスまたはメール組織の設定 API を使用して更新できます。これらのアカウントは、後で変更が完了したときに非アクティブ化 / 削除できます。
切り替え中は、新たに競合アカウントが生成されないように、Atlassian Cloud 内のどこでもターゲットのメール アドレスを使用しないようにエンド ユーザーに伝えてください。
2 つの Atlassian アカウントを 1 つにマージすることはできません。競合アカウントに製品アクセスがある場合は、ID-240 をチェックして、競合アカウントからエンド ユーザーのメイン Atlassian アカウントにデータを移動する場合の提案事項を確認してください。
- アカウント #1: 古いメール アドレスにリンクされています。
- アカウント #2: ターゲットのメール アドレスを使用しており、Jira と Confluence にアクセスできる競合アカウントです。
代わりに競合アカウントを残しておく場合は、次のようにしてください。
- アカウント #2 は一切変更しません。
- IDP 側で切り替えが完了すると、ID が一致すれば、SSO は競合アカウントにリンクできるようになります (後述のシナリオ 2 を参照)。
- アカウント #1 がプロビジョニングによってリンクされた場合 (ロック)、ユーザー プロビジョニングのためにアカウントの再リンクが必要になることがあります。状況を詳しく分析するために、アトラシアン サポートに連絡してください。
ソリューション
シナリオ 1: SAML-SSO とユーザー プロビジョニングの両方が組織で有効になっていない
管理対象アカウントの管理画面から Atlassian アカウントのメール アドレスを更新するか、メール組織の設定 API を使用してメール アドレスの一括変更を実行します。
管理対象アカウントをエクスポートして、API による更新に使用できる Atlassian アカウント ID を特定します。
ソーシャル ログイン (つまりMicrosoft や Google) を使用している場合は、アカウントのメール アドレスがそれらのプロバイダーで更新されていることを確認してください。プロバイダー側で変更が行われない場合は、エンド ユーザーが Atlassian Cloud に次回ソーシャル ログインしたときに、アトラシアン側で行われたメール アドレスの変更が元に戻ります。
シナリオ 2: SAML-SSO は組織で有効になっているが、ユーザー プロビジョニングは有効になっていない
メール アドレスの変更は、ユーザーが Atlassian Cloud に次回ログインしたときに、ID プロバイダーのアカウントから Atlassian アカウントに反映されます。ただし、強制 SSO を介してログインしていることが前提条件となります。ただし、組織のアイドル セッションの期間によっては、エンド ユーザーがすぐに Atlassian Cloud に再ログインするよう求められない場合があります。
ステップ 1: SAML-SSO 経由でログインするときに、Atlassian アカウントのメール アドレスとして使用される IDP 属性を特定します。
アイデンティティ プロバイダー | 属性 |
|---|---|
Azure AD | Atlassian Cloud アプリのシングル サインオン設定で設定された一意のユーザー ID にマッピングされた IDP 属性。 |
Okta | Atlassian Cloud アプリのシングル サインオン設定で設定されたアプリ ユーザー名形式にマッピングされた IDP 属性。 |
その他 | IDP attribute that is mapped to the NameID attribute of the SAML Response:
|
ステップ 2: ステップ 1 で特定した IDP 属性をターゲットのメール アドレスに更新します。エンド ユーザーが Atlassian Cloud に次回ログインしたときに、新しいメール アドレスが既存の Atlassian アカウントに反映されます。
ターゲットのメール アドレスを持つ重複した管理対象アカウントがある場合は、SSO によって再リンクされ、エンド ユーザーは重複アカウントにログインすることになります。
ステップ 3: すべての管理対象アカウントがすぐに Atlassian Cloud に再ログインすることを保証できないため、管理対象アカウントのメール アドレスをターゲットのメール アドレスに更新するのが最善です。上記のシナリオ 1 に従ってください。
シナリオ 3: SAML-SSO とユーザー プロビジョニングの両方が組織で有効になっている
ステップ 1: SAML-SSO 経由でログインするときに、Atlassian アカウントのメール アドレスとして使用される IDP 属性を特定します。上記のシナリオ 2 を参照してください。
ステップ 2: アカウントを同期するときに、Atlassian アカウントのメール アドレスとして使用される IDP 属性を特定します。
アイデンティティ プロバイダー | 属性 |
|---|---|
Azure AD | mail IDP attribute mapped to emails[type eq “work”].value in the Provisioning configuration on the Atlassian cloud app. |
Okta | Primary email IDP attribute mapped to Primary Email in the Provisioning configuration on the Atlassian cloud app. |
その他 | プロビジョニング アプリの emails[type eq "work"].value にマッピングされた IDP 属性。 |
ステップ 3: ステップ 1 およびステップ 2 で特定した IDP 属性について、ターゲットのメール アドレスを使用するように更新します。プロビジョニングを通じて、リンクされた Atlassian アカウントに変更が自動的に同期されます。
SSO またはユーザー プロビジョニングの属性の更新を忘れると、エンド ユーザーの Atlassian アカウントが古いメール アドレスと新しいメール アドレスを切り替えてしまう可能性があります。
ステップ 4: プロビジョニングされていない管理対象アカウントについて、上記のシナリオ 1 に従ってメール アドレスを更新します。
シナリオ 4: Google Workspace の統合が有効になっている (SAML-SSO でも SCIM ユーザー プロビジョニングでもない)
There are two types of integration with Google:
- Google Workspace は、組織と Google が直接統合したものです。SSO とユーザー プロビジョニングがサポートされており、ドメインは自動的に申請されます。
- Google ID プロバイダーは、SAML-SSO と SCIM ユーザー プロビジョニングを利用した統合であり、ドメインは手動で申請します。これが設定されている場合は、上記のシナリオ 2 および 3 に従ってください。
ステップ 1: Google のプライマリ メール アドレス属性を更新します。これは、リンクされた (ロックされた管理対象アカウント) Atlassian アカウントに反映されるはずです。
ステップ 2: プロビジョニングされていない管理対象アカウントについて、上記のシナリオ 1 に従ってメール アドレスを更新します。