アカウントを管理するためのドメインを検証する

現在、このページのコンテンツに影響する変更を公開中です。admin.atlassian.com で、ご利用の組織から [ユーザー] と [グループ] の各リストが [ディレクトリ] タブにある場合は、改善されたユーザー管理エクスペリエンスを利用できます。改善されたエクスペリエンスの変更については、以下のコンテンツをご参照ください。

[ユーザーとグループ] ではなく新しい [ディレクトリ] タブを表示する、新しい admin.atlassian.com ビューの図

アカウントを請求すると、プロファイルに移動したときに、そのドメインを使用し、組織がアカウントを管理していることをユーザーに知らせます。

組織管理者は、自社のドメインを認証して、そのドメインのすべてのユーザー アカウントを所有していることを証明できます。自社のドメインとは、ユーザー アカウントのメール アドレスの @ 記号に続くすべての文字列です。たとえば、アトラシアンは atlassian.com ドメインを所有しています。

組織のドメインを認証する際は、次の 2 つの手順に従います。1) 自社のドメインの所有権を認証して、2) そのドメインを持つユーザーのアカウントを要求します。ドメインの認証には、次の 2 つのメリットがあります。

  • 自社ドメインの Atlassian アカウントのさらなる制御。このようなアカウントは管理対象アカウントになり、管理者がこのようなアカウントを編集、削除、または無効にできます。

  • 管理対象アカウントへのセキュリティ ポリシーの適用機能。2 段階認証によるログインを要求したり、SAML シングル サインオンをセットアップして、ご利用の ID プロバイダーのポリシーをすべての Atlassian アカウントに適用したりすることができます。これらはいずれも、Atlassian Access をサブスクライブすることで行えます。

このビデオでドメインの検証の詳細をご確認ください

組織の認証済みドメイン

たとえば、自社が Acme Inc. という名前で、acme.comacme.co.uk のドメインを所有しているとします。両方のドメインを認証してアカウントを要求したら、Atlassian 組織の [管理対象アカウント] ページに移動してユーザーの詳細を編集できます。 

Atlassian Access のサブスクリプションでは、ユーザーの管理対象アカウントにセキュリティ ポリシーを適用できます。

sarah@vendor.com のような異なるドメインを持つユーザーにも製品アクセスを付与できます。これらのユーザーは管理対象アカウントではないので、セキュリティ ポリシーは適用できません。 

2 つのドメインにある管理対象アカウントで構成される組織。

アカウントを要求する際は、予想よりも多くのユーザーが自社ドメインのアカウントを保持している場合があります。自分の組織に、自社の Atlassian 製品を使用していないユーザーのアカウントが表示される場合があります。

ドメインの所有権の認証

自社ドメインの所有権は 2 とおりの方法で認証できます。

  • HTTPS — HTML ファイルを自身のドメインの Web サイトのルート フォルダにアップロードします。

  • DNS TXT — 自身のドメイン ネーム システム (DNS) に TXT レコードをコピーします。

HTTPS による認証

HTML ファイルをホストするには HTTPS が必須で、認証局が発行した有効な SSL 証明書が必要です (自己署名証明書は動作しません)。認証できるのは、www ドメインにリダイレクトが 1 つあるドメインのみです。たとえば、ドメインが example.com の場合は、https://example.com または https://www.example.com でのみドメインの認証に成功しますが、他のリダイレクトでは成功しません。

認証に成功したあとは、セキュリティのため、認証ファイルが定期的に確認されます。ファイルがドメインから削除されていた場合、ドメインの所有権が引き続き有効かどうかを確認できなくなるため、ドメインは認証ステータスを失い、SAML シングル サインオンを含むそのドメインのすべてのセキュリティ ポリシーは無効化されます。

HTTPS 経由でドメインを認証するには、次の手順を実行します。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [ディレクトリ] > [ドメイン] の順に選択します。
    改善されたユーザー管理エクスペリエンスをご利用の場合は、このステップは異なります[設定] > [ドメイン] の順に選択します。

  3. [HTTPS] タブで、atlassian-domain-verification.html ファイルをダウンロードします。

  4. HTML ファイルをドメインの web サーバのルート ディレクトリにアップロードします。

  5. アトラシアンの管理ページの [ドメイン] ページに戻り、[ドメインを認証] をクリックします。

  6. [HTTPS] メソッドの状態で、[ドメイン] フィールドに認証対象のドメインを入力し、[ドメインを認証] をクリックします。

ご利用の Web サーバーで HTML ファイルが確認された場合、ドメインが認証され、[アカウントの要求] 画面が開きます。次のセクションでは、[アカウントの要求] 画面での操作について説明します。

DNS による認証

認証の成功後、DNS ホストの txt レコードが定期的に確認されます。txt レコードが削除されたり、誤った情報で更新されたりした場合、その txt レコードを更新するための猶予期間がメールで通知されます。レコードが更新されない場合、ドメインは認証ステータスを失い、SAML シングル サインオンを含むそのドメインのすべてのセキュリティ ポリシーは無効化されます。

DNS を使用してドメインを認証するには、次の手順を実行します。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [ディレクトリ] > [ドメイン] の順に選択します。
    改善されたユーザー管理エクスペリエンスをご利用の場合は、このステップは異なります[設定] > [ドメイン] の順に選択します。

  3. [DNS] タブで、txt レコードをクリップボードにコピーします。

  4. DNS ホストに移動し、新しいレコードを追加するための設定ページを見つけます。

  5. 新しいレコードを追加するオプションを選択し、txt レコードを [Value] フィールド ([Answer] や [Description ] の場合もあります) にペーストします。

  6. DNS レコードは次のフィールドを持つ場合があります。

    • Record type: 「TXT」と入力します。

    • Name/Host/Alias: 既定のままにします (@ または空白)。

    • Time to live (TTL): 「86400」と入力します。

  7. レコードを保存します。

  8. アトラシアンの管理ページの [ドメイン] ページに戻り、[ドメインを認証] をクリックします。

  9. [TXT レコード] メソッドの状態で、[ドメイン] フィールドに認証対象のドメインを入力し、[ドメインを認証] をクリックします。

DNS ホストによっては、ドメインが認証されて DNS の変更が有効になるまで最大で 72 時間かかる場合があります。この間 [ドメイン] 表のドメインは UNVERIFIED ステータスになります。72 時間が経過してから、認証するドメインの横にある [ドメインを認証] をクリックして、表示されるダイアログから認証してください。

ドメインを認証すると、ドメインは認証済みのステータスになりますが、ユーザー アカウントの要求はまだ完了していません。次のセクションでは、[アカウントの要求] 画面での操作について説明します。

[ドメインを認証] 画面でドメインを入力すると、ドメインの所有権が確認されて認証される

HTTPS でファイル アップロードでの認証ができない場合

セキュリティ強化のため、ドメイン認証プロセスでは HTML ファイルのホストに HTTPS が必須です。ドメインには、認証局が発行した有効な SSL 証明書が必要です (自己署名証明書は使用できません)。

ドメイン プレフィクスwwwへの 1 回のリダイレクトのみを使用できます。たとえば、ドメインはhttps://example.comおよび/あるいはhttps://www.example.comでのみ正常に検証できます。2 番目のドメインにリダイレクトするドメインを検証することはできません。

ドメインのアカウント クレームとは?

ドメイン認証のプロセスの一環として、ドメインのすべてのアカウントを要求する必要があります。ドメイン内のすべてのユーザーが Atlassian アカウントを作成できるため、自社ドメインに予想よりも多くのユーザーが Atlassian アカウントを保持している可能性があります。ドメインのすべてのアカウントを参照したい場合、要求するアカウントのユーザー一覧をエクスポートして確認できます。

要求できるのは、認証されたドメインのアカウントのみです。[ドメイン] ページの下部にある表で、ドメインの横に VERIFIED ステータスが表示されます。UNVERIFIED ステータスが表示される場合は、ドメインを再認証する必要があります (DNS を使用している場合は 72 時間経過後)。

ドメインのアカウントを要求する

アカウントをエクスポートおよび要求するには、次の手順を実行します。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [ディレクトリ] > [ドメイン] の順に選択します。
    改善されたユーザー管理エクスペリエンスをご利用の場合は、このステップは異なります[設定] > [ドメイン] の順に選択します。

  3. [ドメイン] 表のドメインで、[アカウントを要求] をクリックします。

  4. [Claim accounts (アカウントを申請)] 画面で、ご利用のドメインのアカウント数が表示されます。[アカウントのエクスポート] を選択すると、ご利用のドメインにある個々のアカウントのメール アドレスと、それらのアカウントの製品アクセスの一覧を取得できます。

  5. [Claim accounts (アカウントを申請)] を選択してドメインの認証プロセスを完了し、それらのアカウントを組織に申請します。

  6. [管理対象アカウントを表示] を選択して、[管理対象アカウント] ですべての申請済みアカウントのリストを表示します。

  7. [管理対象アカウント] から、アカウントを編集、削除、または無効化できます。

認証済みドメインのアカウントを申請しない場合は、これらのユーザーに対してセキュリティ ポリシーの編集、無効化、削除、または適用を実行できません。

申請済みユーザー アカウントへの通知

組織がアカウントを管理していることをユーザーに知らせるメールは送信されなくなりました。

アカウントを申請または申請解除すると、組織がアカウントを管理していること、または管理しなくなったことを次の 2 つの方法でユーザーに通知します。

  1. 通知 — ユーザーは製品の更新を受け取ります。

  2. プロファイルとその公開範囲 – ユーザーが個人アカウントの情報を管理します。

管理対象アカウントの通知
管理者がアカウントを管理していることをユーザーに知らせるプロファイル ページのバナー

ドメイン名を変更する

会社の Web サイトやそのドメインに関連付けられたメールのアドレスを変更する必要がある場合は、ドメイン名を変更することをお勧めします。ドメインの変更を検討する一般的な理由には、次のようなものがあります。

  • 会社が別の会社を買収した

  • 自社がリブランディングしている

  • 自社が他の会社に売却された

ドメイン名とメール アドレスを変更する手順は、次の要因によって決まります。

  • Atlassian へユーザーをプロビジョニングする方法: クロスドメイン ID 管理システム (SCIM) を使用する ID プロバイダーの使用、またはユーザーを手動で招待

  • SAML シングル サインオンでログインする方法

  • 同一、新規、または異なる Atlassian 組織のドメインの変更が必要かどうか

ドメイン名を変更すると、ユーザーのメール アドレスのドメイン名も変更されます (例: abc@domain.com から abc@newdomain.com)。既存の Atlassian アカウント内でドメインを変更すると、同じアカウント履歴を保持できます。

ドメインの変更手順
変更をスムーズに行うために、ご自身に該当するセットアップに基づく手順に従ってください。これによって次を回避できます。

  • admin.atlassian.com で管理者コントロールへのアクセス権を失う

  • 「古い」ドメインとアカウントから履歴データにアクセスできない

  • SAML シングル サインオンでログインできない

  • 新しいドメイン名のアカウントへのアクセスに 14 日間を要する

ドメインの変更と移動の手順

ユーザーの管理方法に応じて、手順が異なります。手順には次の 2 種類があります。ご自身のプロビジョニング方法に適したものを選択してください。

  1. Atlassian にユーザーを手動で招待する

  2. SCIM を通じてユーザーを Atlassian に自動でプロビジョニングする

ユーザーを手動で招待してドメインを変更/移動する

ドメイン名とメール アカウントを変更するには、新旧のドメインを認証して、同じ Atlassian 組織でアカウントを要求する必要があります。

ドメイン名を変更するには、次の手順に従います。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [ディレクトリ] > [ドメイン] の順に選択します。
    改善されたユーザー管理エクスペリエンスをご利用の場合は、このステップは異なります[設定] > [ドメイン] の順に選択します。

  3. 新しいドメインを認証して、そのメール アカウントを要求します。

  4. 旧ドメインがまだ認証されていることを確認して、そのメール アカウントを要求します。

  5. 古いメールを新しいメールに手動で変更するには、次の手順に従います。

    1. [ディレクトリ] > [管理対象アカウント] の順に移動します。

    2. ユーザーを選択して、新しいメールに変更します。

  6. メールのドメイン名の変更を自動化するには、次の手順に従います。

    1. REST API セット メールを使用します

ドメインとそのメール アカウントを新しい組織に移動する

既存の組織から新しい組織にドメインを移動することをお勧めします。その際は、ダウンタイムの予定を立てる必要があります。ドメインを移動すると、既存の組織の同じアカウントには Atlassian Access のセキュリティ機能が適用されません。

ドメインを新しい組織に移動するには、次の手順に従います。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [ディレクトリ] > [ドメイン] の順に選択します。
    改善されたユーザー管理エクスペリエンスをご利用の場合は、このステップは異なります[設定] > [ドメイン] の順に選択します。

  3. 既存の組織から新しいドメインを削除します。

  4. 新しい組織で新しいドメインを認証して、そのメール アカウントを要求します。

SCIM でユーザーをプロビジョニングしてドメインを変更するか移動する

ドメイン名とメール アカウントを変更するには、新旧のドメインを認証して、同じ Atlassian 組織でアカウントを要求する必要があります。

ドメイン名を変更するには、次の手順に従います。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [ディレクトリ] > [ドメイン] の順に選択します。
    改善されたユーザー管理エクスペリエンスをご利用の場合は、このステップは異なります[設定] > [ドメイン] の順に選択します。

  3. メール アカウントの移動先となる新しいドメインを認証します。

  4. 古いドメインが認証されていることを確認して、そのメール アカウントを請求します。

  5. 古いメール アカウントが ID プロバイダーにあることを確認します。

  6. ID プロバイダーから古いアカウントを Atlassian に同期します。

  7. 同期後、アイデンティティ プロバイダーのメールを新しいドメインに変更して、旧アカウントの履歴を残します。

ドメインとそのメール アカウントを新しい組織に移動する

既存の組織から新しい組織にドメインを移動することをお勧めします。その際は、ダウンタイムの予定を立てる必要があります。ドメインを移動すると、既存の組織の同じアカウントには Atlassian Access のセキュリティ機能が適用されません。

ドメインを移動するには、次の手順に従います。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [ディレクトリ] > [ドメイン] の順に選択します。
    改善されたユーザー管理エクスペリエンスをご利用の場合は、このステップは異なります[設定] > [ドメイン] の順に選択します。

  3. 既存の組織から新しいドメインを削除します。

  4. 新しい組織で、移動するドメインのアカウントを認証して要求します。

  5. 新しいドメインのすべてのメール アカウントが ID プロバイダーにあることを確認します。

  6. ID プロバイダーを新しい組織に接続します。

  7. ID プロバイダーから Atlassian にメール アカウントを同期します。

SAML SSO でドメインを移動する

ユーザーが SAML でログインできるようにするには、新しい組織の新しいドメインで SAML SSO を有効にする追加ステップを行う必要があります。旧ドメインのすべてのユーザーの SAML ID を削除する際は、アトラシアン サポートに連絡することをお勧めします。

認証済みドメインを維持する

このセクションでは、ドメインのの認証時に発生する可能性がある問題について説明します。

複数のドメインまたはサブドメインがある場合

1 つの組織で複数のドメインおよびサブドメインを認証できます。要求したい各ドメインについて、このページのステップを繰り返します。us.acme.comeu.acme.com などのサブドメインの認証は自動的に行われないため、それぞれのサブドメインを手動で認証する必要があります。

ほかの組織がドメインを認証済みの場合

ほかのユーザーがドメインを認証済みの場合、それを通知する警告メッセージが表示されます。この場合、企業の誰かが別の組織で同じドメインを検証している可能性があります。組織の管理者を探し、認証済みドメインの一覧からそのドメインを削除するように依頼することをおすすめします。誰に依頼すべきかわからない場合、サポートにお問い合わせください

Web サイトが CMS で管理されている場合

Web サイトのルート フォルダにファイルを直接追加できない場合があります。これを回避するには、ダウンロードしたファイルから認証トークンをコピーして、同じ場所にある 256 kB 未満の既存のページ (https://example.com/atlassian-domain-verification.html) で公開すると、ドメインを認証できるはずです。

G Suite を使用している場合

ユーザーは Google で認証します。Google 連携の一部としてドメインを認証しているため、サイトでドメインを認証することはできません。ドメインの認証が必要な場合は、G Suite 連携との接続を解除する必要があります。

別のドメインのユーザーが G Suite 経由で接続されていない場合でも、そのドメインを認証して Atlassian Access サブスクリプションを利用し、ドメインにセキュリティ ポリシーを適用できます。

自身が所有していないドメインを認証したい場合

アトラシアン ユーザーのプライバシーとセキュリティを保護するため、自分が所有していないドメインを認証することはできません。

これらのユーザーに Atlassian Access のセキュリティ ポリシーを適用する場合は、メール アドレスを認証可能なドメインに変更してもらうか、そのドメインのメール アドレスを使用する Atlassian アカウントを作成してもらいます。

認証済みドメインの削除

認証済みドメインの一覧からドメインを削除すると、そのドメインのユーザーは管理されなくなり、[管理対象アカウント] ページに表示されなくなります。

認証済みドメインを削除するには、ドメインの横にある [削除] をクリックして削除の実行を確認します。組織がアカウントを管理しなくなったことが、次の 2 つでユーザーに知らされます。

  1. 通知 — ユーザーは製品の更新を受け取ります。

  2. プロファイルとその公開範囲 – ユーザーが個人アカウントの情報を管理します。

 

その他のヘルプ