セルフ サインアップ ユーザーが Atlassian Access に対して請求対象と見なされないように、既定の請求対象外ポリシーを設定する

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: Cloud のみ - この記事は、 クラウド プラットフォームのアトラシアン製品にのみ適用されます。

所属組織が管理している既存の Atlassian アカウントを保有しているユーザーについては、該当するアトラシアン組織管理者が適宜手動で請求対象外ポリシーに移行する必要があります。このドキュメントは、エンド ユーザーがまだ Atlassian アカウントを保有しておらず、新しい Atlassian Cloud 製品 / サービスにサインアップするユース ケースのみを対象としています。

「セルフ サインアップ」アカウント / ユーザーとは

このコンテキストでは、アトラシアン組織が請求 (管理) している Atlassian アカウントにログインできるユーザーは、「セルフ サインアップ」ユーザーと見なされます。独自の Atlassian アカウントを作成できるユーザーは、管理者コントロール外で任意の Atlassian Cloud サービスにサインアップできます(シャドー IT)。アトラシアンの製品チームは、エンド ユーザーにアクセスを許可する製品を管理者がコントロールできるように取り組んでいます。

CLOUD-11072 - 課題情報を取得中... ステータス

エンド ユーザーによる Atlassian Cloud サービスへのサインアップを禁止することはできませんが、既定のローカル ディレクトリ ポリシーを請求対象外にすることは可能です。新しいユーザーが自分で Atlassian Cloud サービスにサインアップした場合、そのユーザーは Atlassian Access に対して請求対象と見なされます。

新しい「セルフ サインアップ」ユーザーが既定で Atlassian Access に対して請求対象と見なされないようにするには、既定のローカル ディレクトリ ポリシーを請求対象外に設定できます。この記事は、Cloud サイトの管理者によって招待されたユーザーにも当てはまります。

セルフ サインアップのデモ

このデモでは、エンド ユーザーが id.atlassian.com に移動して、独自のアカウントを作成しました。ユーザーが trello.com または bitbucket.org に移動したシナリオでも、同じ結果になります。

新たに作成されたユーザーが既定の請求対象外 (ローカル ディレクトリ) ポリシーにすぐに表示されなくても心配しないでください。変更が更新されるまでに数分かかることもあります。

セルフ サインアップ画面の例

次の表は、各製品のセルフ サインアップ画面 / エクスペリエンスのスクリーンショットです。

製品

Trello


Cloud サイト

Bitbucket

Atlassian Access の請求の計算方法

Atlassian Access の請求の計算方法は製品アクセスに基づきます。製品にアクセスできないユーザーは、Atlassian Access に対して請求対象外と見なされます。エンド ユーザーが Atlassian Cloud サービス (Jira、Confluence、Trello、Bitbucket など) にセルフ サインアップした場合、そのエンド ユーザーは Atlassian Access に対して請求対象と見なされます。

Atlassian Access の請求の管理

認証ポリシーについて理解する

Prerequisites

  • 請求対象外に設定できるのは、ローカル ディレクトリのポリシーのみです。

  • アトラシアン組織ごとに設定できる請求対象外ポリシーは 1 つだけです。

  • 請求対象外ポリシーのメンバーであるユーザーは、強制 SSO や強制 2 段階認証などの Atlassian Access 機能を使用できません。

  • 認証ポリシーを使用するには、ドメインを申請する必要があります (「アカウントを管理するためのドメインを検証する」)。

  • このタスクを実行するには、ドメインを申請するアトラシアン組織の組織管理者である必要があります。

既定の請求対象外ポリシーを設定し、ドメインをリンクして、セルフ サインアップ ユーザーが請求対象外ポリシーに自動的に追加されるようにする方法

未設定の場合は、「既定のポリシーを請求対象外にする」を参照してください。次の手順は、上記のドキュメントを補足するためのものです。
このドキュメントに記載されているポリシー名は一例です。アトラシアン組織のポリシー名は異なる場合がありますが、手順は同じです。

パート A: 既定のローカル ポリシーを請求対象外にする

アトラシアン製品 / サービスにセルフ サインアップするユーザーが既定のローカル ディレクトリ ポリシーに表示されるようにするには、次の手順に従います。

既定のローカル ポリシーには、すでに「請求対象外」ラベルが付いている可能性があります。

  • https://admin.atlassian.com > [該当するアトラシアン組織] (この例では「dnguyen4」) に移動します。

  • [セキュリティ] > [認証ポリシー] に移動します。

  • 既定のローカル ディレクトリ ポリシーが上記のスクリーンショットのようにすでに請求対象外になっている場合は、「パート B: ドメインをリンクする」に進んでください。そうでない場合は、次の手順を参照してください。


  1. 既定以外のポリシーや請求対象外の他のポリシーがある場合は、そのポリシーを編集して、[すべてのセキュリティ設定をポリシーに追加] をクリックします (次のビデオを参照)。それ以外の場合は、ステップ 2 までスキップしてください。



  2. 既定のローカル ディレクトリ ポリシーで [編集] をクリックします。

  3. [...] をクリックします。

  4. [ポリシーを更新] をクリックして変更を確定します。

パート B: ドメインをリンクする

ドメインがローカル ディレクトリにリンクされていることを確認します。そのためには、次の手順に従います。

  • 該当するアトラシアン組織の [セキュリティ] > [ID プロバイダー] に移動します。

    1. ディレクトリ (この例では「AAD」) を選択します。

    2. [...] (ページの右上) をクリックし、[ドメインをリンク] を選択します。

    3. ローカル ディレクトリにリンクするドメインを探し、[別のディレクトリにリンクする] をクリックします。

    4. [ローカル (ID プロバイダー未接続)] を選択し、変更を確定します。

これで、Atlassian Cloud サービス / 製品にサインアップする「kumatsumotors.com」ドメイン上のユーザーは、Atlassian Access に対して請求対象外と見なされるようになりました。

ドメインのリンクに関するデモ ビデオ

注意

  • ドメインをローカル ディレクトリにリンクしても、自動プロビジョニング (SCIM) でプロビジョニングされるユーザーには影響しません。SCIM プロビジョニングで同期されたユーザーは、既定の「IdP ディレクトリ」に追加されます。

  • 組織でジャスト イン タイム プロビジョニング [JIT] (SAML) が設定されている場合は、JIT を強制 SSO で正しく機能させるために、ドメインを「IdP ディレクトリ」にリンクする必要があります。ドメインがローカル ディレクトリにリンクされている場合、ユーザーは Atlassian アカウントへのサインアップを求められ、既定の「IdP ディレクトリ」ポリシーではなく、ローカルの既定の (請求対象外) ポリシーに表示されます。

Last modified on Mar 21, 2024

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.