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

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

自身の組織でドメインを認証すると、自社のドメインの所有権の証明と、そのドメインのユーザー アカウントの要求が行われます。ドメインの認証には、次の 2 つのメリットがあります。

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

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

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

組織の認証済みドメイン

あなたの会社の名前が Acme Inc. で、acme.com と acme.co.uk の各ドメインを所有しているとします。両方のドメインを検証してアカウントを請求後、アトラシアン組織の [アカウントを管理] ページに移動すると、ユーザーの詳細を編集できます。

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

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

ドメインの所有権の認証

自社ドメインの所有権は 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 で、ご利用の組織から、[ディレクトリ] > [ドメイン] をクリックします。

   改善されたユーザー管理エクスペリエンスを使用している場合は、ドメインを見つける方法が異なることに注意してください。admin.atlassian.com の組織から、[設定] > [ドメイン] の順に選択します。

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

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

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

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

Web サーバーに HTML ファイルが見つかると、ドメインが検証され、[アカウントの要求] 画面が開きます。次のセクションでは、[アカウントの要求] 画面が開いたときにすべき操作について説明します。

DNS による認証

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

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

1. admin.atlassian.com で、ご利用の組織から、[ディレクトリ] > [ドメイン] をクリックします。

   改善されたユーザー管理エクスペリエンスを使用している場合は、ドメインを見つける方法が異なることに注意してください。admin.atlassian.com の組織から、[設定] > [ドメイン] の順に選択します。

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

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

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

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

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

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

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

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

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

8. [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. [ドメイン] 表のドメインで、[アカウントを要求] をクリックします。

2. [アカウントを要求] 画面が開きます。対象のドメインのアカウントの数が表示されます。[アカウントのエクスポート] をクリックすると、自身のドメインの個々のアカウントのメール アドレスと、それらのアカウントの製品アクセスの一覧を取得できます。

3. [アカウントを要求] をクリックしてドメインの認証プロセスを完了し、それらのアカウントを組織に要求します。

[アカウントを管理] 画面で、すべてのアカウントを正常に要求できたことを確認できます。[管理対象アカウントを表示] をクリックすると、[管理対象アカウント] 画面ですべての要求済みアカウントのリストを表示できます。個々のアカウントを編集、削除、または無効化するには、この画面に戻ります。

この時点で、ユーザーは [プロファイルと公開設定] ページで、アカウント状況の変更とその影響について通知するメッセージを受け取ります。

アカウントを要求しない場合、ドメインの認証ステータスは維持されますが、アカウントを編集、無効化、または削除したり、それらのユーザーにセキュリティ ポリシーを適用したりすることはできません。

ドメイン名を変更する

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

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

• 会社がリブランディングを行っている

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

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

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

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

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

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

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

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

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

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

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

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

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

1. admin.atlassian.com に移動して、[ディレクトリ] > [ドメイン] の順に選択します。

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

3. 古いドメインがまだ認証済みであることを確認して、そのメール アカウントを請求します。

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

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

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

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

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

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

既存の組織から新しい組織にドメインを移動することをお勧めします。この場合は、ダウンタイムをスケジュールする必要があります。ドメインを移動する際に、既存の組織にある古いアカウントには Atlassian Access のセキュリティ機能は適用されません。

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

1. admin.atlassian.com に移動して、[ディレクトリ] > [ドメイン] の順に選択します。

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

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

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

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

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

1. admin.atlassian.com に移動して、[ディレクトリ] > [ドメイン] の順に選択します。

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

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

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

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

6. 同期したら、ID プロバイダーのメール アドレスを新しいドメインに変更して、古いアカウントの履歴を保持します。

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

既存の組織から新しい組織にドメインを移動することをお勧めします。この場合は、ダウンタイムをスケジュールする必要があります。ドメインを移動する際に、既存の組織にある古いアカウントには Atlassian Access のセキュリティ機能は適用されません。

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

1. admin.atlassian.com の組織から、[ディレクトリ] > [ドメイン] の順に選択します。

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

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

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

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

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

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

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

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

1 つの組織で複数のドメインおよびサブドメインを認証できます。要求したい各ドメインについて、このページのステップを繰り返します。us.acme.com や eu.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 のセキュリティ ポリシーを適用したい場合、彼らのメールアドレスを認証可能なドメインに変更するよう求めるか、そのドメインを使用したメールアドレスに招待メールを送信します。

認証済みドメインの削除

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

認証済みドメインを削除するには、ドメインの横にある [削除] をクリックし、削除を確認します。ドメインのユーザーに対し、アカウントが管理対象ではなくなったことを知らせるメールは送信されません。