セルフ サインアップ ユーザーが Atlassian Guard に対して請求対象と見なされないように、既定の請求対象外ポリシーを設定する
プラットフォームについて: Cloud のみ - この記事は クラウド プラットフォームのアトラシアン製品に適用されます。
「セルフ サインアップ」アカウント / ユーザーとは
このコンテキストで、Atlassian 組織が申請 (管理) している Atlassian アカウントにログインできるユーザーは、"セルフ サインアップ" ユーザーと見なされます。独自の Atlassian アカウントを作成できるユーザーは、管理者コントロール外で任意の Atlassian Cloud サービスにサインアップできます (シャドー IT)。参照: ACCESS-1468 - 管理対象ユーザーの関連サイトや製品を管理する権限を管理者に許可する
現在の製品サブスクリプションによっては、エンド ユーザーの Atlassian Cloud サービスへのサインアップを停止できない場合があります。新しいユーザーが自分で Atlassian Cloud サービスにサインアップした場合、そのユーザーは Atlassian Guard に対して請求対象と見なされます。新しい "セルフ サインアップ" ユーザーが既定で Atlassian Guard に対して請求対象と見なされないようにするには、既定のローカル ディレクトリ ポリシーを請求対象外に設定します。この記事は、Cloud サイトの管理者によって招待されたユーザーにも当てはまります。
セルフ サインアップのデモ
このデモでは、エンド ユーザーが id.atlassian.com に移動して、独自のアカウントを作成しました。ユーザーが trello.com または bitbucket.org に移動したシナリオでも、同じ結果になります。
新規作成したユーザーが既定の請求対象外 (ローカル ディレクトリ) ポリシーにすぐに表示されなくても心配しないでください。変更が反映されるまでに数分かかることがあります。
セルフ サインアップ画面の例
次の表は、各製品のセルフ サインアップ画面 / エクスペリエンスのスクリーンショットです。
製品 | 例 |
|---|---|
Trello |
|
Cloud サイト |  |
Bitbucket |
|
Atlassian Guard の請求の計算方法
Atlassian Guard の請求の計算方法は製品アクセスに基づきます。製品にアクセスできないユーザーは、Atlassian Guard に対して請求対象外と見なされます。エンド ユーザーが Atlassian Cloud サービス (Jira、Confluence、Trello、Bitbucket など) にセルフ サインアップした場合、そのエンド ユーザーは Atlassian Guard に対して請求対象と見なされます。
Prerequisites
請求対象外に設定できるのは、ローカル ディレクトリのポリシーのみです。
Atlassian 組織ごとに設定できる請求対象外ポリシーは 1 つだけです。
請求対象外ポリシーのメンバーであるユーザーは、強制 SSO や強制 2 段階認証などの Atlassian Guard 機能を使用できません。
認証ポリシーを使用するには、ドメインを申請する必要があります (「アカウントを管理するためのドメインを検証する」)。
このタスクを実行するには、ドメインを申請するアトラシアン組織の組織管理者である必要があります。
既定の請求対象外ポリシーを設定し、ドメインをリンクして、セルフ サインアップ ユーザーが請求対象外ポリシーに自動的に追加されるようにする方法
パート A: 既定ポリシーを請求対象外にするには
アトラシアン製品 / サービスにセルフ サインアップするユーザーが既定のローカル ディレクトリ ポリシーに表示されるようにするには、次の手順に従います。
既定のローカル ポリシーには、すでに「請求対象外」ラベルが付いている可能性があります。
https://admin.atlassian.com > [該当するアトラシアン組織] (この例では「dnguyen4」) に移動します。
[セキュリティ] > [認証ポリシー] に移動します。
既定のローカル ディレクトリ ポリシーが上記のスクリーンショットのようにすでに請求対象外になっている場合は、「パート B: ドメインをリンクする」に進んでください。そうでない場合は、次の手順を参照してください。
既定以外のポリシーや請求対象外の他のポリシーがある場合は、そのポリシーを編集して、[すべてのセキュリティ設定をポリシーに追加] をクリックします (次のビデオを参照)。それ以外の場合は、手順 2 までスキップしてください。
既定のローカル ディレクトリ ポリシーで [編集] をクリックします。
[...] をクリックします。
[ポリシーを更新] をクリックして変更を確定します。
パート B: ドメインをリンクする
ドメインがローカル ディレクトリにリンクされていることを確認します。そのためには、次の手順に従います。
該当するアトラシアン組織の [セキュリティ] > [ID プロバイダー] に移動します。
ディレクトリ (この例では「AAD」) を選択します。
[...] (ページの右上) をクリックし、[ドメインをリンク] を選択します。
ローカル ディレクトリにリンクするドメインを探し、[別のディレクトリにリンクする] をクリックします。
[ローカル (ID プロバイダー未接続)] を選択し、変更を確定します。
これで、Atlassian Cloud サービス/製品にサインアップする「kumatsumotors.com」ドメイン上のユーザーは、Atlassian Guard に対して請求対象外と見なされるようになりました。
ドメインのリンクに関するデモ ビデオ
注意
ドメインをローカル ディレクトリにリンクしても、自動プロビジョニング (SCIM) でプロビジョニングされるユーザーには影響しません。SCIM プロビジョニングで同期されたユーザーは、既定の「IdP ディレクトリ」に追加されます。
組織でジャスト イン タイム プロビジョニング [JIT] (SAML) が設定されている場合は、JIT を強制 SSO で正しく機能させるために、ドメインを「IdP ディレクトリ」にリンクする必要があります。ドメインがローカル ディレクトリにリンクされている場合、ユーザーは Atlassian アカウントへのサインアップを求められ、既定の「IdP ディレクトリ」ポリシーではなく、ローカルの既定の (請求対象外) ポリシーに表示されます。