マニュアルキャンセル

ID の設定

検索

最終更新日 : Jun 23, 2022 01:39:34 PM GMT | 次にも適用 : Creative Cloud for enterprise, Document Cloud for enterprise

アドビエンタープライズ版とグループ版：管理ガイド
デプロイメントの計画
1. 基本概念
2. デプロイメントガイド
3. Creative Cloud 教育機関向けのデプロイ
組織の設定
1. ID の設定
  1. ID タイプ | 概要
  2. Enterprise ID を使用した組織の設定
  3. Federated ID を使用した組織の設定
    1. SSO の概要
    2. Azure Connector と Sync の設定
    3. Google Federation と Sync の設定
    4. 汎用 SAML
    5. 教育機関の SSO
      1. 教育委員会ポータルと LMS 用の SSO の構成
      2. よくある質問
  4. ドメインの所有権の確認
  5. ドメインの追加と管理
  6. ドメインをディレクトリにリンクする
  7. 既存のドメインとディレクトリの管理
  8. ディレクトリの信頼を使用した事前クレームされたドメインの追加
  9. 新しい認証プロバイダーへの移行
2. アセットの設定
3. 認証の設定
4. プライバシーとセキュリティの担当者
5. Console の設定
6. 暗号化の管理
製品および使用権限の管理
1. ユーザーの管理
2. 製品および製品プロファイルの管理
3. 共有デバイスライセンスの管理
ストレージとアセットの管理
1. ストレージ
2. アセットの移行
3. ユーザーのアセットの再利用
4. 学生アセットの移行 | 教育機関のみ
  1. 学生アセットの自動移行
  2. アセットの移行
Managed Services
1. Adobe Stock
2. カスタムフォント
3. Adobe Asset Link
4. Adobe Acrobat Sign
5. Creative Cloud エンタープライズ版 – 無料メンバーシップ
  1. 概要
  2. はじめに
アプリおよびアップデートのデプロイ
1. 概要
2. パッケージの作成
3. パッケージのカスタマイズ
  1. Creative Cloud デスクトップアプリのカスタマイズ
  2. パッケージへのエクステンションの格納
4. パッケージのデプロイ
5. アップデートの管理
  1. Adobe のエンタープライズ版およびグループ版のお客様向け変更の管理
  2. アップデートのデプロイ
6. Adobe Update Server Setup Tool（AUSST）
7. Adobe Remote Update Manager（RUM）
8. トラブルシューティング
9. Creative Cloud Packager を使用したパッケージの作成（CC 2018 以前のアプリ）
アカウントの管理
レポートとログ
ヘルプを表示

ID とシングルサインオンの設定 | YouTube ビデオ

ディレクトリをセットアップする：Enterprise ID または Federated ID を使用するにはまず、ドメインをリンクできるディレクトリを設定します。詳細情報 >

ドメインをセットアップする：エンドユーザーは、Admin Console で設定したドメインに対して認証されます。 詳細情報 >

ディレクトリにドメインをリンクする：ディレクトリとドメインを設定した後は、ドメインをディレクトリにリンクしてグループ化します。
詳細情報 >

ディレクトリの信頼性：ディレクトリの信頼性を使用して、他の組織のシステム管理者を信頼します。
詳細情報 >

新しい認証プロバイダーへの移行：確立されたディレクトリを Adobe Admin Console 内の新しい認証プロバイダーに移行します。
詳細情報 >

ディレクトリ全体にドメインを移動する：Admin Console 内のディレクトリ全体にドメインを移動することでディレクトリを構造化します。
詳細情報 >

システム管理者として Admin Console で最初に行うことが、エンドユーザーを認証するための ID システムの定義と設定です。Adobe 製品とサービスのライセンスを購入した後、ライセンスをエンドユーザーにプロビジョニングする必要があります。そのためには、ユーザーを認証する方法が必要です。

Adobe は、エンドユーザーの認証に使用できる次の ID タイプを提供しています。

Business ID
Enterprise ID
Federated ID
Adobe ID

組織が個別にアカウントを所有し、ドメイン内のユーザーを管理する場合は、Enterprise ID または Federated ID（シングルサインオン）を使用してください。

注意：

アドビでは、エンタープライズストレージなど、エンタープライズレベルの機能をはじめとするメリットを提供するため、既存のすべての Adobe ID を Business ID に移行しています。企業の新規のお客様はすべて、チームメンバーに Business ID を使用することになります。

お客様の組織のこのアップグレードスケジュールが確定した際に、事前にお知らせします。詳しくは、「Business ID と新しいストレージ機能の概要」を参照してください。お客様は、組織が移行されるまで、引き続き Adobe ID タイプを使用して組織にアクセスできます。移行後は、個人のお客様以外 Adobe ID を利用できなくなります。

ここでは、Enterprise ID または Federated ID を使用してエンドユーザーを認証するために必要な ID システムの設定方法を説明します。

注意：

このドキュメントに記載されているディレクトリの設定とドメインの設定の手順は完全に切り離されています。つまり、これらの手順は順序を問わず、並行して行うこともできます。ただし、メールのドメインをディレクトリにリンクするためには、両方の手順を完了する必要があります。

主要な用語と概念

手順に進む前に、基本的な概念と用語をご確認ください。

Admin Console のディレクトリは、ユーザーや認証ポリシーなどのリソースを保持する場所です。LDAP やアクティブディレクトリと似ています。

組織の ID プロバイダーです。Active Directory、Microsoft Azure、Ping、Okta、InCommon、Shibboleth などがあります。

一般に使用される IdP を使用して Creative Cloud の SSO を設定する方法について詳しくは、記事の最後のその他の関連ヘルプを参照してください。

法人が作成および所有します。エンドユーザーが管理します。Business ID（およびこの ID に関連付けられたすべてのアセット）は、ビジネスによって所有されます。エンドユーザーは新規登録して個人用 Business ID を作成したり、Business ID を使用して Adobe からの追加製品およびサービスを利用したりすることはできません。

Business ID の使用を開始するために必要な設定は特にありません。管理者は、ユーザーを組織に参加するよう招待したり、対象ユーザーを削除したりすることができます。管理者はアカウントを削除したり、引き継いだりすることができます。Business ID は、管理者が作成してユーザーに発行します。管理者は、アカウントを借用するか、Business ID を削除して関連するデータへのアクセスを完全にブロックすることにより、製品およびサービスへのアクセスを取り消すことができます。

Business ID が推奨される場合のいくつかの要件およびシナリオを次に示します。

管理者がユーザーの ID を作成し、所有する場合
Enterprise ID や Federated ID を現在サポートしていない他のアドビサービスをユーザーが使用することが想定される場合
ユーザーが既に Adobe ID とビジネス関連のデータ（ファイル、フォント、設定など）を持っている場合
教育用環境で学生が卒業後も Adobe ID を保持できる場合
管理者が契約社員やフリーランサーのアカウントを作成して管理する場合
アドビグループ版の契約がある場合
ユーザーのファイルとデータに緊急にアクセスする必要がある場合
ユーザーアカウントを完全にブロックまたは削除する機能が必要な場合

注意：

組織によって作成、所有、管理されます。Enterprise ID のホストと認証は Adobe が行いますが、ID は組織が保持します。エンドユーザーは新規登録して Enterprise ID を作成したり、Enterprise ID を使用して Adobe からの追加製品およびサービスを利用したりすることはできません。

Enterprise ID は、管理者が作成してユーザーに発行します。管理者は、アカウントを借用するか、Enterprise ID を削除して関連するデータへのアクセスを完全にブロックすることにより、製品およびサービスへのアクセスを取り消すことができます。

次の要件やシナリオに該当する場合には、Enterprise ID を使用することが推奨されます。

ユーザーが使用するアプリやサービスを厳格に管理する必要がある場合
ID に関連付けられたファイルやデータに緊急にアクセスする必要がある場合
ユーザーアカウントを完全にブロックまたは削除する機能が必要な場合

組織によって作成、所有され、フェデレーションを通じてエンタープライズディレクトリにリンクされます。資格情報は組織が管理し、SAML2 ID プロバイダー（IdP）を使用してシングルサインオンを処理します。

次の要件やシナリオに該当する場合には、Federated ID を使用することが推奨されます。

組織のエンタープライズディレクトリに基づいてユーザーをプロビジョニングする場合
ユーザーの認証を管理する場合
ユーザーが使用するアプリやサービスを厳格に管理する必要がある場合

注意：

ID プロバイダーは TLS 1.2 に準拠している必要があります。

エンドユーザーが作成、所有、管理します。認証は Adobe が実行し、ID の管理はエンドユーザーが行います。ユーザーは、自分の ID に関連付けられたファイルやデータを完全に制御できます。ユーザーは Adobe から追加の製品やサービスを購入することもできます。管理者は、ユーザーを組織に参加するよう招待したり、対象ユーザーを削除したりすることができます。ユーザーを Adobe ID アカウントからロックアウトすることはできません。管理者がアカウントを削除したり、管理を引き継いだりすることもできません。Adobe ID の使用を開始するために必要な設定は特にありません。

次の要件やシナリオに該当する場合には、Adobe ID を使用することが推奨されます。

ユーザーが ID を作成、所有、管理できるようにする場合
ユーザーが他の Adobe 製品やサービスを購入または新規登録できるようにする場合
Enterprise ID や Federated ID を現在サポートしていない他の Adobe サービスをユーザーが使用することが想定される場合
ユーザーが既に Adobe ID を所有し、ファイル、フォント、設定などのデータが関連付けられている場合
教育用環境で学生が卒業後も Adobe ID を保持できる場合
組織が管理するドメインのメールアドレスを使用していない契約社員やフリーランサーがいる場合
Adobe グループ版契約がある場合は、この ID タイプを使用する必要があります

メールアドレスの @ 記号より後の部分です。Enterprise ID または Federated ID でドメインを使用するには、まずそのドメインの所有権を検証する必要があります。

例えば、組織が複数のドメインを所有し（geometrixx.com、support.geometrixx.com、contact.geometrixx.com）、従業員の認証には geometrixx.com を使用する場合があります。このような場合、Admin Console では geometrixx.com ドメインを使用して ID を設定します。

システム管理者

Admin Console で、IdP ディレクトリマネージャー、DNS マネージャーと共に、ID を設定します。このドキュメントは、Admin Console へのアクセス権を持つシステム管理者を対象とします。このユーザーには、（通常）Admin Console へのアクセス権を持たないユーザーの代わりに作業することが求められます。

DNS マネージャー

DNS トークンを更新して、ドメインの所有権を検証します

ID プロバイダー（IdP）ディレクトリマネージャー

IdP コネクタを作成します

ユーザー ID は、認証ソースに対して検証されます。Enterprise ID や Federated ID を使用するには、ドメインを追加して固有の認証ソースを設定します。例えば、メールアドレスが john@example.com の場合、example.com がドメインですが、ドメインを追加すると、そのドメイン上のメールアドレスを使用して Enterprise ID や Federated ID を作成できるようになります。ドメインは、Enterprise ID か Federated ID のいずれかで使用できますが、両方に同じドメインを使用することはできません。ただし、複数のドメインを追加することはできます。

組織はドメイン管理を検証する必要があります。組織では、複数のドメインを追加することもできます。ただし、同じドメインは 1 回しか追加できません。一部のパブリックドメインや一般的なドメイン（gmail.com や yahoo.com など）は追加できません。

ID タイプについて詳しくは、ID タイプの管理を参照してください。

ディレクトリの作成

Enterprise ID または Federated ID を使用するにはまず、ドメインをリンクできるディレクトリを作成します。デフォルトでは、組織には設定を必要としない Business ID ディレクトリがあります。

注意：

Adobe は現時点で、IdP-Initiated ワークフローをサポートしていません。

お客様の組織が Microsoft Azure を SSO プロバイダーとして設定している（または予定している）場合は、Azure フェデレーションによる認証を使用することをお勧めします。また、Microsoft Azure でのユーザー認証：ディレクトリの作成のセクションで説明した手順に従います。

お客様の組織が Google フェデレーションを SSO プロバイダーとして設定している（または予定している）場合は、Google フェデレーションによる認証を使用することをお勧めします。また、Google フェデレーションを使用したユーザー認証：Adobe Admin Console でディレクトリを作成するセクションに記載されている手順に従います。

組織で次の 1 つ以上を使用している場合は、次の手順に従います。

Enterprise ID
Azure または、Google 以外の SAML プロバイダー
SCIM 経由の Microsoft Azure または Google フェデレーション。

Admin Console にログインし、設定／ID に移動します。

「ディレクトリ」タブに移動し、「ディレクトリを作成」をクリックします。

ディレクトリ作成画面で、ディレクトリ名を入力します。

「Federated ID」を選択し、「次へ」をクリックして手順 5 に進みます。

Enterprise ID を選択して、「ディレクトリを作成」をクリックします。

Enterprise ID ディレクトリを作成する場合、このディレクトリの手順はここで終了です。

ドメインの設定に進んでください。

（Federated ID のみ）「その他の SAML プロバイダー」を選択し、「次へ」をクリックします。

SAML プロファイルを追加画面を使用して、ID プロバイダー用の設定画面を開きます。

アイデンティティプロバイダー（IdP）によって、メタデータファイルをアップロードできる場合もあれば、ACS URL とエンティティ ID が必要な場合もあります。以下に例を示します。

Azure Active Directory の場合：メタデータファイルをアップロードします。
Google の場合：ACS URL とエンティティ ID をコピーし、Google IdP ソフトウェアでそれらを使用します。
SalesForce の場合：メタデータファイルをダウンロードし、ファイルから証明書情報を抽出して、その証明書情報を SalesForce IdP ソフトウェアで使用します。

注意：

上記の Azure と Google のオプションは、それぞれ Azure または Google フェデレーションを使用しないことを選択した場合に必要です。

Azure AD と OIDC（Open ID Connect）を使用している場合は、Microsoft Azure でのユーザー認証の記事の手順に従います。
「他の SAML プロバイダー」オプションを使用して SAML で Azure AD を構成した場合は、Azure AD SSO と Adobe Identity Management（SAML）の統合の記事の手順に従います。
Google フェデレーションを使用している場合は、Google フェデレーションを使用したユーザー認証の手順に従います。

以下のいずれかの方法で操作します。

方法 1：

「Adobe のメタデータファイルをダウンロード」をクリックします。

メタデータファイルがローカルディスクにダウンロードされます。このファイルを使用して、ID プロバイダーとの SAML 統合を構成します。

方法 2：

ACS URL とエンティティ ID をコピーします。

IdP アプリケーションウィンドウに切り替え、メタデータファイルをアップロードするか、ACS URL とエンティティ ID を指定します。完了したら、IdP メタデータファイルをダウンロードします。

Adobe Admin Console に戻り、SAML プロファイルを追加ウィンドウで IdP メタデータファイルをアップロードして「完了」をクリックします。

ドメインのセットアップ

注意：

組織のディレクトリが Microsoft Azure AD コネクタまたは Google フェデレーションを介して設定されている場合、手動でドメインを追加する必要はありません。ID プロバイダーの設定内で検証された選択したドメインは、Adobe Admin Console に自動的に同期されます。

エンドユーザーは、Admin Console で設定したドメインに対して認証されます。

ドメインを設定するには、次の操作を行います。

Admin Console にドメインを追加する
特別な DNS レコードを追加して、ドメインの所有権を検証するための準備をする
ドメインを検証する

Admin Console に追加するドメインは、同じ IdP で登録する必要はありません。ただし、これらのドメインをディレクトリにリンクするときに、各 IdP からそれぞれ別のディレクトリにドメインをリンクさせる必要があります。

ドメインが既に別の組織の Admin Console に追加されている場合は、Admin Console に追加できません。ただし、そのドメインへのアクセスを要求することはできます。

Admin Console にログインし、設定／ID に移動します。

「ドメイン」タブで、「ドメインを追加」をクリックします。

ドメインを追加画面で、1 つ以上のドメインを入力して、「ドメインを追加」をクリックします。一度にクレームして検証できるドメインは 15 個までで、その後残りのドメインを追加することができます。

ドメインを追加画面でドメインのリストを確認し、「ドメインを追加」をクリックします。

これでドメインが Admin Console に追加されました。次に、これらのドメインの所有権を実証します。

組織はドメインの所有権を実証する必要があります。組織は、Admin Console に必要な数のドメインを追加できます。

Admin Console では、1 つの DNS トークンを使用してすべてのドメインの所有権を実証できます。また、Admin Console では、サブドメインの DNS 検証は不要です。つまり、DNS トークンを使用してドメインの所有権を実証すれば、そのドメインのサブドメインが Admin Console に追加されると同時に、すべて自動的に検証されます。

Admin Console にログインし、設定／ID に移動して、「ドメイン」タブに移動します。

クリックして、ドロップダウンリストから「DNS トークンにアクセス」を選択します。

DNS マネージャーと協力して、追加したドメイン用の特別な DNS レコードを追加します。

クレームするドメインが自社の所有するドメインであることを証明するには、生成された DNS トークンを含む TXT レコードを追加する必要があります。正確な手順はドメインホストによって異なります。一般的なガイドラインについては、ドメイン所有権の確認を参照してください。

手順を完了するには、DNS サーバーに追加で情報を入力します。効率的に作業できるように、事前に DNS マネージャーに連絡してください。

Adobe は、ドメインの DNS レコードを定期的にチェックします。DNS レコードが正しい場合、ドメインは自動的に検証されます。Admin Console にログインして、手動ですぐにドメインを検証することも可能です。次に、ドメインを検証する必要があります。

Admin Console では、追加されたドメインの検証を 1 日に数回行います。このため、DNS レコードが正しく構成されていれば、ドメインを手動で検証する必要はありません。

ドメインを手動で検証する

すぐにドメインを検証する必要がある場合は、Admin Console で行います。ドメインを手動で検証するには、次の操作を行います。

Admin Console にログインします。

設定／ID に移動し、「ドメイン」タブを選択します。

「検証」をクリックします。

ドメインの所有権を検証画面で、「今すぐ検証」をクリックします。

DNS の変更が有効になるまで最大 72 時間かかることがあるため、検証時にエラーメッセージが表示される場合があります。詳しくは、DNS レコードに関するよくある質問を参照してください。

ドメインの所有権の検証後、Admin Console の必要なディレクトリに検証されたドメインをリンクできます。

ドメインをディレクトリにリンクする

Admin Console でディレクトリとドメインを設定した後、Admin Console では、ドメインをディレクトリにリンクする必要があります。

複数のドメインを同じディレクトリにリンクできます。ただし、1 つのディレクトリにリンクするすべてのドメインが、同一の SSO 設定を共有する必要があります。

Admin Console にログインし、設定／ID に移動します。

「ドメイン」タブに移動します。

ドメイン名の左側にあるチェックボックスをクリックして、「ディレクトリへリンク」をクリックします。

複数のドメインから同じディレクトリにリンクするには、設定するすべてのドメインのチェックボックスを選択します。

ディレクトリへリンク画面で、ドロップダウンからディレクトリを選択し、「リンク」をクリックします。

ユーザーの管理

Enterprise ID または Federated ID の設定が完了したら、購入した Adobe 製品とサービスをユーザーに提供することができます。

Admin Console については、ユーザー向けの概要を参照してください。または、次のいずれかの方法を使用して、すぐに Admin Console にユーザーを追加することもできます。

Azure フェデレーションが設定されている場合は、Azure AD でユーザーとグループをセットアップする方法を確認します。
Google フェデレーションが設定されている場合は、Google Admin Console でユーザープロビジョニングを認証および設定する方法を確認します。
または、個人ユーザーを追加したり、CSV バルクアップロード、User Sync ツール、または User Management REST API を使用したりすることができます。

Admin Console にユーザーを追加したら、ユーザーを製品プロファイルに割り当ててプロビジョニングします。

ディレクトリの信頼性

1 つのドメインの所有権をクレームできるのは 1 つの組織のみです。そこで、次のシナリオについて考えてみます。

Geometrixx という会社には複数の部署があり、各部署には独自の Admin Console があります。また、いずれの部署でも、geometrixx.com ドメインを使用した Federated ID をユーザー ID として使用したいと考えています。この場合、各部署のシステム管理者は、このドメインを認証のためクレームする必要があります。Admin Console は、ある組織のドメインが他の組織の Admin Console に追加されるのを防ぎます。ただし、1 つの部署により追加された後、他の部署は、組織の Admin Console に代わってそのドメインがリンクされているディレクトリへのアクセスを要求することができます。

ディレクトリの信頼性により、ディレクトリの所有者は他のシステム管理者（共同利用権所有者）を信頼することができます。その後、Admin Console の共同利用権を所有する組織は、信頼されたディレクトリ内の任意のドメインにユーザーを追加できます。

つまり、Admin Console で Enterprise ID または Federated ID を使用する場合は、ドメインを追加する必要があります。このドメインが既に別の組織によって追加されている場合、そのドメインが含まれているディレクトリへのトラスティアクセスを要求する必要があります。ただし、トラスティ組織が信頼できるドメインにユーザーを追加した場合、そのユーザーは Business ID ユーザーとして追加されます。Business ID ユーザーとして構成されている場合でも、所有する組織の認証フレームワークによって認証されます。

ディレクトリへのアクセスを要求する方法については、「ドメインの設定」でドメインの追加手順を参照してください。

警告：

ディレクトリの所有者が、そのディレクトリへのアクセス要求を承認すると、共同利用権を所有する組織はそのディレクトリに関連付けられているすべてのドメインにアクセスできるほか、以後そのディレクトリに関連付けられるすべてのドメインにもアクセスできます。このように、ドメインとディレクトリのリンク計画は、組織の ID システムを設定する上で不可欠な手順です。
信頼リクエストの追加、リクエスト、取り消し、撤回を行う場合は、変更を行う前に、Admin Console または関係するコンソールからユーザーリストを書き出すことを強くお勧めします。このリストは、ロールバックが必要な場合に備えて、名前、メールアドレス、割り当てられた製品プロファイル、割り当てられた管理者ロールなど、すべてのユーザーデータのスナップショットを提供します。
信頼関係を含むドメインを移行するには、特定の手順に従う必要があります。トラスティ組織でユーザーアカウントや製品アクセスが失われるのを防ぐため、信頼されたドメインの移行時に信頼関係を取り消さないでください。
異なるストレージモデルの下にある組織間でディレクトリの信頼を設定することはできません（ユーザーストレージモデルとエンタープライズストレージモデル）。エンタープライズストレージとレガシーのユーザーベースストレージの両方にユーザーがアクセスするときの問題の記事を参照してください。

ドメインの共同利用権所有者

Admin Console に既存のドメインを追加する場合は、次のメッセージが表示されます。

このドメインへのアクセスを要求すると、送信者の名前、メール、組織名が所有者組織のシステム管理者と共有されます。

新しいディレクトリタイプは Business ID であり、ユーザー認証は所有する組織が設定した方式に依存します。

ドメインは既に所有者によって設定されているため（詳しくは、「ドメインの設定」の「ドメインの所有権を実証する」を参照）、トラスティは特に操作を行う必要はありません。アクセス要求が所有者によって承認されると、共同利用権を所有する組織は所有者組織が設定したとおりに、ディレクトリとすべてのドメインにアクセスできます。

Admin Console にログインし、設定／ID に移動します。

「アクセス要求」タブに移動し、アクセスを要求した各ディレクトリのステータスを確認します。

また、アクセス要求リスト内の項目をクリックすれば、「リクエストを再送信」または「要求のキャンセル」をクリックできます。

ディレクトリへのアクセスの要求が所有者組織から承認されると、通知がメールで届きます。信頼の要求が表示されなくなり、代わりに、信頼できるディレクトリとそのドメインが、ディレクトリとドメインのリストにアクティブ（信頼済み）状態で表示されます。

続けて、ユーザーとユーザーグループを追加し、製品プロファイルに割り当てます。

共同利用権を所有する組織が信頼済みディレクトリにアクセスする必要がなくなった場合は、いつでも共同利用権を取り消すことができます。

Admin Console にログインし、設定／ID に移動します。

「ディレクトリ」タブで、アクセスを取り消す共有ディレクトリをクリックします。

ディレクトリの詳細メニューで、「取り消す」をクリックします。

信頼できるディレクトリへのアクセスを取り消すと、そのディレクトリのドメインに関連付けられているユーザーが組織から削除されます。ただし、これらのユーザーは、割り当てられたアプリ、サービス、ストレージに引き続きアクセスできます。

ユーザーがソフトウェアを使用できないようにするには、Admin Console／ユーザー／ユーザーを削除を選択して、ユーザーを削除します。削除されたユーザーのアセットは組織に所有権があるため、組織が再利用できます。

ドメインの所有者

所有者組織のシステム管理者は、所有しているディレクトリへのアクセス要求を承認するか拒否するかを選択できます。

所有するディレクトリへのアクセス要求のメールを受け取ったら、そのメール内から要求の承認または拒否を選択できます。また、「アクセス要求」タブに移動してクレーム要求を管理することもできます。

Admin Console にログインし、設定／ID に移動します。

「アクセス要求」タブに移動します。

すべての要求を承認するには、「すべてを承認」をクリックします。

または、特定のクレームの要求を承認するには、行の左側にあるチェックボックスをクリックして、「承認」をクリックします。

アクセス要求を承認画面で、「承認」をクリックします。

共同利用権を所有する組織のシステム管理者にメール通知が送信されます。

所有しているディレクトリへのアクセス要求を拒否することもできます。

Admin Console にログインし、設定／ID に移動します。

「アクセス要求」タブに移動します。

行の左側にあるチェックボックスをクリックし、「拒否」をクリックします。

アクセス要求拒否画面で拒否する理由を入力し、「拒否」をクリックします。

入力した理由は、メールによって要求元の組織と共有されます。ただし、メール、名前、組織の情報は公開されません。

既にアクセス権を付与した共同利用権を所有する組織のアクセス権を取り消すことができます。

Admin Console にログインし、設定／ID に移動します。

「共同利用者」タブに移動します。

行の左側にあるチェックボックスをクリックし、「取り消す」をクリックします。

取り消す共同利用者の画面で、「取り消し」をクリックします。

信頼できるディレクトリへのアクセスを取り消すと、そのディレクトリのドメインに関連付けられているユーザーが信頼できるディレクトリから削除されます。ただし、これらのユーザーは、割り当てられたアプリ、サービス、ストレージに引き続きアクセスできます。

ユーザーがソフトウェアを使用できないようにするためには、トラスティの管理者が Admin Console／ユーザー／ユーザーを削除を選択して、ユーザーを削除します。削除されたユーザーのアセットはトラスティ組織に所有権があるため、組織が再利用できます。

ディレクトリの信頼性：よくある質問

ユーザーがトラスティ組織に追加されると、そのユーザーは常に Business ID ユーザーとして追加されます。これは、トラスティ組織の新規ユーザーにも、所有者組織の既存ユーザーにも当てはまります。ユーザーは、所有者組織で Federated ID または Enterprise ID タイプのユーザーとして、またすべてのトラスティ組織で Business ID ユーザーとして利用できます。ただし、トラスティ組織のユーザーがアドビアプリまたはサービスにログインするときには、所有者組織の設定に従い、Federated ID または Enterprise ID のログインワークフローが表示されます。

また、ユーザーは所有者組織またはトラスティ組織のいずれかから使用権限を与えられる場合があります。この場合、ユーザーが所属する組織（所有者またはトラスティ）ごとにプロファイルを作成します。プロファイルを作成することで、各組織から権限やアセットを分離しておくことができます。特定のプロファイルの下でユーザーが作成したアセットは、その組織に属することになります。ユーザーが組織を去った場合は、その組織の管理者によってアセットが再クレームされます。

全文表示:

アドビプロファイルを管理する方法。
アセットを再クレームする方法。

トラスティ組織の移行後、すべてのユーザーはアカウントからログアウトされているため、再度ログインする必要があります。これらのユーザーは所有者組織のユーザーでもあるため、所有者組織だけでなく、トラスティ組織からも使用権限が与えられる場合があります。この場合、ユーザーのプロファイルを設定します。アカウントに再度ログインすると、ユーザーにプロファイルを選択するプロンプトが表示される場合があります。

ユーザーは、必要に応じてこちらで、アドビプロファイルの管理方法を確認することができます。

暗号化キーの管理

Creative Cloud または Document Cloud エンタープライズ版を使用すると、ユーザーはファイルを安全かつセキュアに格納できます。他のユーザーとファイルを共有したり、共同作業したりすることもできます。ユーザーは Creative Cloud web サイト、Creative Cloud デスクトップアプリ、Creative Cloud モバイルアプリを利用してファイルにアクセスできます。ストレージは、組織と Adobe との契約に含まれている場合にのみ、Creative Cloud または Document Cloud エンタープライズ版で利用できます。

Creative Cloud および Document Cloud 上で制御とセキュリティの追加レイヤーのすべてのデータを暗号化する際、組織内の専用暗号化キーを生成するよう Adobe に求めることができます。次に、コンテンツは、専用の暗号化キーによる標準の暗号化により暗号化されます。暗号化キーは、必要に応じて Admin Console から無効にすることができます。

専用の暗号化キーは、ストレージとサービスが含まれた Creative Cloud または Document Cloud エンタープライズ版の共有サービスプランでのみ利用できます。

詳しくは、Admin Console でキーの暗号化を管理する方法を参照してください。

新しい認証プロバイダーへの移行

セルフサービスオプションを使用して、確立されたディレクトリを Adobe Admin Console 内の新しい認証プロバイダーに移行できます。

アクセス要件

新しい認証プロバイダーに移行するには、次の要件を満たす必要があります。

システム管理者の資格情報を使用して、組織の Admin Console にアクセスする
Admin Console に、フェデレーション用に構成された既存のディレクトリが存在する
組織の ID プロバイダーを構成するためのアクセス権がある（Microsoft Azure Portal、Google Admin Console など）

詳しくは、実装に関する考慮事項を参照してください。

移行手順

アクセス要件および実装に関する考慮事項に適合していることを確認した後、次の手順に従って認証プロファイルを編集し、ディレクトリを移行します。

Adobe Admin Console で、設定／ディレクトリに移動します。

目的のディレクトリで「編集」アクションを選択します。次に、Details ディレクトリで「新しい IdP を追加」を選択します。

ID プロバイダーを選択して、新しい認証プロファイルを設定します。お客様の組織がユーザーの認証に使用している ID プロバイダー（IdP）を選択します。「次へ」をクリックします。

選択した ID プロバイダーに応じて、次のいずれかの手順に従います。

Azure の場合：
Microsoft Azure Active Directory のグローバル管理者の資格情報を使用して、Azure にログインし、権限プロンプトに同意します。Admin Console のディレクトリの詳細に戻ります。

注意：

Microsoft グローバル管理者のログインは、組織の Azure ポータルでアプリケーションを作成する場合にのみ必要です。グローバル管理者のログイン情報は保存されず、アプリケーションを作成するためのワンタイム権限についてのみ使用されます。
上記の手順 3 で ID プロバイダーを選択する場合、Microsoft Azure オプションは、Adobe Admin Console のユーザー名フィールドが Azure Portal の UPN フィールドと一致しない場合は使用しないでください。
既存のディレクトリがユーザーログイン設定としてユーザー名を渡すように設定されている場合は、「他の SAML プロバイダー」オプションの下で新しい IdP を確立する必要があります。ログイン設定は、「ユーザーログイン設定」の下の現在のディレクトリで「編集」オプションを選択して確認できます。

手順 3 で Microsoft Azure のオプションを選択した場合、現時点では、ID プロバイダーのみが設定され、ディレクトリ同期サービスは含まれません。

Google の場合：

SAML 設定の編集画面の表示から、ACS URL とエンティティ ID をコピーします。
別のウィンドウで、Google 管理者資格情報を使用して Google Admin Console にログインし、アプリ／SAML アプリに移動します。
「+」記号を使用して新しいアプリを追加し、Adobe アプリを選択します。次に、「オプション 2」で IDP メタデータをダウンロードし、Adobe Admin Console の「SAML 設定の編集」にアップロードします。その後、「保存」をクリックします。
Adobe の基本情報を確認します。前にコピーした ACS URL とエンティティ ID を「サービスプロバイダーの詳細」に入力します。 ユーザープロビジョニングは設定不要です。既存のディレクトリでは、現在サポートされていないためです。
最後に、アプリ／SAML アプリ／Adobe の設定／サービスの状況に移動します。「サービスの状況」を「すべてのユーザーに対してオン」に設定し、「保存」を選択します。

他の SAML プロバイダーの場合：

別のウィンドウで ID プロバイダーのアプリケーションにログインし、新しい SAML アプリを作成します（移行のダウンタイムを避けるために、既存の SAML アプリを編集することはできません。）
ID プロバイダーの設定に基づいて、Adobe Admin Console から ID プロバイダーの設定にメタデータファイルをコピーするか、ACS URL とエンティティ ID をコピーします。
ID プロバイダーの設定から Adobe Admin Console にメタデータファイルをアップロードします。その後、「保存」をクリックします。

Adobe Admin Console のディレクトリの詳細に、新しい認証プロファイルが作成されます。テストを使用して、すべてのエンドユーザーが SAML アプリにアクセスできるように、設定が正しく指定されているかどうかを確認します。

テスト機能は、IdP の新しい認証プロファイルのユーザー名の形式が、ユーザーログイン用の既存のプロファイルのユーザー情報と一致することを確認します。

「アクティベート」をクリックして、新しい認証プロファイルに移行します。完了すると、新しいプロファイルに「In use」（使用中）と表示されます。

ライセンス認証を行う前に、Adobe Admin Console のディレクトリユーザーに移動し、ID プロバイダーのユーザー名が Admin Console のユーザー名と一致することを確認します。

SAML の場合、新しい設定にあるアサーションの Subject（サブジェクト）フィールドの値が、Admin Console の既存のユーザーに付与されたユーザー名の形式と一致することを確認します。

ディレクトリ設定を更新した後は、ドメインの移行を使用して、既存のディレクトリから新しいディレクトリにドメインを移動できます。移行されたドメインのユーザーは、新しいターゲットディレクトリで作業するように設定された ID プロバイダーに属している必要があります。

制限事項の詳細と、設定時に発生する可能性のあるエラーの回避については、よくある質問を参照してください。

ディレクトリ間でのドメインの移動

Admin Console 内で、ドメインをソースディレクトリからターゲットディレクトリに移動することで、ディレクトリを構造化できます。ドメインからディレクトリへのリンクは、エンドユーザーが製品、サービス、保存されたアセットにアクセスできる状態を維持したまま、組織のニーズに基づいて再編成できます。同じ ID プロバイダーに対して設定されたドメインを 1 つの同じディレクトリに統合することで、IT チームの管理が合理化されます。

1 つのディレクトリから、SHA-2 認証を備えた新しい ID プロバイダー（Azure、Google、または他の SAML）を含む別のディレクトリに移行する場合は、両方のディレクトリに新しい IdP 設定を複製する必要があります。新しい IdP を設定することで、ディレクトリ内のすべてのドメインのユーザーについてテストログインが可能になります。新しい ID プロバイダーに応じて、次のいずれかの操作を行います。

Microsoft Azure の場合：新しい Azure IdP をディレクトリに追加し、同じ Azure テナントにログインします。
他の SAML プロバイダー（Google を含む）の場合：IdP 上の同じ SAML アプリを参照する同一のメタデータファイルをアップロードします。

ドメインの移行が完了した後も、新しいディレクトリに属するユーザーはログインできます。これにより、ダウンタイムが回避され、割り当てられた Adobe のアプリやサービスに即座にアクセスできるようになります。

警告：

ユーザーはアカウントからログアウトされ、ドメイン転送中は新しいセッションにログインできなくなります。エンドユーザーへの影響を最小限に抑えるため、オフピーク時にディレクトリを編集することをお勧めします。
信頼関係を含むドメインを移行するには、特定の手順に従う必要があります。- トラスティ組織でユーザーアカウントや製品アクセスが失われるのを防ぐため、信頼されたドメインの移行時に信頼関係を取り消さないでください。
ドメインを移行する場合は、変更を行う前に、Admin Console または関係するコンソールからユーザーリストを書き出すことを強くお勧めします。このリストは、ロールバックを実行する必要がある場合に備えて、名前、メールアドレス、割り当てられた製品プロファイル、割り当てられた管理者ロールなど、すべてのユーザーデータのスナップショットを提供します。
現在、ソースディレクトリと宛先ディレクトリの両方がアドビのユーザーストレージモデルにあるディレクトリ間でのみ、ドメインを移動できます。

ドメインの移動が必要な理由

この機能は、次のシナリオで利用できます。

SHA-2 認証プロファイルを使用して、既存のディレクトリを別の ID プロバイダーに移行する場合。
信頼関係にあるディレクトリがある場合、または信頼のためにディレクトリを共有したいが、信頼されるディレクトリ内の一部のドメインにのみアクセスを許可する場合
組織チームと部門に基づいてディレクトリをグループ化する必要がある場合
1 つのドメインにリンクされている複数のディレクトリがあり、それらを統合する場合
誤ってドメインを間違ったディレクトリにリンクした場合
ドメインをセルフサービスで Enterprise ID から Federated ID または Federated ID から Enterprise ID に移動する場合

暗号化されたディレクトリまたは信頼できるディレクトリの取り扱い

ソースディレクトリまたはターゲットディレクトリが暗号化されているか信頼関係にある場合、ドメインを直接移動することはできません。次の場合は、説明に従ってドメインを移動します。

使用例	例	推奨されるアプローチ
同じ信頼関係にあるディレクトリ間でドメインを移動する	ディレクトリ 1 とディレクトリ 2 がコンソール A で構成されていて、両方がコンソール B と信頼関係を確立している。	ドメインの移動プロセスに従います。
信頼関係にあるディレクトリ間でドメインを移動する *プロセス図については図 A を参照してください	ディレクトリ 1 がコンソール A で構成されていて、かつコンソール B と信頼関係を確立している。以内にコンソール A 内にあるディレクトリ 1（ドメイン X）のドメインをディレクトリ 2 に移動する必要がある。	変更を行う前に、信頼を所有するコンソールおよびすべてのトラスティコンソールからユーザーリストを書き出します。すべてのトラスティとコンソール A の宛先ディレクトリ（ディレクトリ 2）の間に信頼を確立します。現在のディレクトリ（ドメイン 1）からコンソール A の宛先ディレクトリ（ディレクトリ 2）にドメインを移動します。コンソール A のディレクトリ 1 にあるトラスティから信頼関係を取り消します。トラスティが、コンソール B から取り消されたドメインを削除します（残りのトラスティについてこの手順を繰り返します）。ディレクトリ 1 がドメインや信頼のない空の状態の場合は、空のディレクトリを削除できます。
複数のドメインを含むドメインまたはディレクトリを組織内の別の Admin Console に移動する	ディレクトリ 1 がコンソール A で構成されている。しかし、ディレクトリ 1 とそのクレームされたドメインを所有権のためにコンソール B に移動する必要がある。	アドビカスタマーサポートにご連絡ください。
同じ Admin Console 内の暗号化されたディレクトリとの間でドメインを移動する	ディレクトリ 1 で暗号化がオンになっていて、同じ Admin Console にあるディレクトリ 2 のドメインをディレクトリ 1 に移行する必要がある。	暗号化されたディレクトリとの間でのドメインの移動は現在サポートされていません。