某些 Creative Cloud 应用程序、服务和功能在中国不可用。
注意：
SHA-2 認証のサポート：従来、ディレクトリでは常に SHA-1 プロトコルが使用されていました。新たに作成されたディレクトリでは、常により安全な SHA-2 プロトコルを使用します。
また SHA-2 認証は有効にする必要もなく、デフォルトで有効になります。
システム管理者として Admin Console で最初におこなうことが、エンドユーザーを認証するための ID システムの定義と設定です。アドビ製品とサービスのライセンスを購入した後、ライセンスをエンドユーザーにプロビジョニングする必要があります。そのためには、ユーザーを認証する方法が必要です。
アドビは、エンドユーザーの認証に使用できる次の ID タイプを提供しています。
- Adobe ID
- Enterprise ID
- Federated ID
組織が個別にアカウントを所有し、ドメイン内のユーザーを管理する場合は、Enterprise ID または Federated ID（シングルサインオン）を使用してください。
ここでは、Enterprise ID または Federated ID を使用してエンドユーザーを認証するために必要な ID システムの設定方法を説明します。
注意：
このドキュメントに記載されているディレクトリの設定とドメインの設定の手順は完全に切り離されています。つまり、これらの手順は順序を問わず、並行しておこなうこともできます。ただし、電子メールのドメインをディレクトリにリンクするためには、両方の手順を完了する必要があります。
組織の ID プロバイダーです。Active Directory、Azure、Ping、Okta、InCommon、Shibboleth などがあります。
一般に使用される IdP を使用して Creative Cloud の SSO を設定する方法について詳しくは、記事の最後のその他の関連ヘルプを参照してください。
エンドユーザーが作成、所有、管理します。認証はアドビが実行し、ID の管理はエンドユーザーがおこないます。ユーザーは、自分の ID に関連付けられたファイルやデータを完全に制御できます。ユーザーはアドビから追加の製品やサービスを購入することもできます。管理者は、ユーザーを組織に参加するよう招待したり、対象ユーザーを削除したりできますが、ユーザーを Adobe ID アカウントからロックアウトすることはできません。管理者がアカウントを削除したり、管理を引き継いだりすることもできません。Adobe ID の使用を開始するために必要な設定は特にありません。
次の要件やシナリオに該当する場合には、Adobe ID を使用することが推奨されます。
- ユーザーが ID を作成、所有、管理できるようにする場合
- ユーザーが他のアドビ製品やサービスを購入または新規登録できるようにする場合
- Enterprise ID や Federated ID を現在サポートしていない他のアドビサービスをユーザーが使用することが想定される場合
- ユーザーが既に Adobe 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 を使用することが推奨されます。
- 組織のエンタープライズディレクトリに基づいてユーザーをプロビジョニングする場合
- ユーザーの認証を管理する場合
- ユーザーが使用するアプリケーションやサービスを厳格に管理する必要がある場合
- Adobe ID の新規登録に使用する電子メールアドレスと同じアドレスの使用をユーザーに許可する場合
注意：
ID プロバイダーは TLS 1.2 に準拠している必要があります。
ユーザー 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 タイプの管理を参照してください。
注意：
アドビは現時点で、IdP-Initiated ワークフローをサポートしていません。
-
Admin Console にログインし、設定／ID に移動します。
-
Enterprise ID を選択して「ディレクトリを作成」をクリックするか、Federated ID を選択して「次へ」をクリックし、ステップ 5 に進みます。
Enterprise ID ディレクトリの作成を選択した場合は、これで終了です。Admin Console でドメインの設定に進んでください。
-
SAML プロファイルを追加画面を使用して、ID プロバイダー用の設定画面を開きます。
アイデンティティプロバイダー（IdP）によって、メタデータファイルをアップロードできる場合もあれば、ACS URL とエンティティ IDが必要な場合もあります。以下に例を示します。
- Azure Active Directory の場合：メタデータファイルをアップロードします。
- Google の場合：ACS URL とエンティティ ID をコピーし、Google IdP ソフトウェアでそれらを使用します。
- SalesForce の場合：メタデータファイルをダウンロードし、ファイルから証明書情報を抽出して、その証明書情報を SalesForce IdP ソフトウェアで使用します。
以下のいずれかの方法で操作します。
方法 1：
「アドビのメタデータファイルをダウンロード」をクリックします。
メタデータファイルがローカルディスクにダウンロードされます。このファイルを使用して、ID プロバイダーとの SAML 統合を構成します。
方法 2：
ACS URL とエンティティ ID をコピーします。
注意：
Admin Console に認証局（CA）の署名付き証明書がある場合、サポート／サポートの概要に移動し、サポートケースを作成します。
- Azure Active Directory の場合：メタデータファイルをアップロードします。
これでディレクトリが作成されます。
「他の SAML プロバイダー」オプションを使用してディレクトリを作成する場合、このディレクトリは SHA-2 認証を使用します。ただし、以前に作成されたディレクトリには SHA-1 認証が使用されています。
この後は、Admin Console でドメインの設定を開始してください。
エンドユーザーは、Admin Console で設定したドメインに対して認証されます。
ドメインを設定するには、次の操作をおこないます。
- Admin Console にドメインを追加する
- 特別な DNS レコードを追加して、ドメインの所有権を検証するための準備をする
- ドメインを検証する
Admin Console に追加するドメインは、同じ IdP で登録する必要はありません。ただし、これらのドメインをディレクトリにリンクするときに、各 IdP からそれぞれ別のディレクトリにドメインをリンクさせる必要があります。
ドメインが既に別の組織の Admin Console に追加されている場合は、Admin Console に追加できません。ただし、そのドメインへのアクセスを要求することはできます。
-
Admin Console にログインし、設定／ID に移動します。
組織はドメインの所有権を実証する必要があります。組織は、Admin Console に必要な数のドメインを追加できます。
Admin Console では、1 つの DNS トークンを使用してすべてのドメインの所有権を実証できます。また、Admin Console では、サブドメインの DNS 検証は不要です。つまり、DNS トークンを使用してドメインの所有権を実証すれば、そのドメインのサブドメインが Admin Console に追加されると同時に、すべて自動的に検証されます。
-
Admin Console にログインし、設定／ID に移動して、「ドメイン」タブに移動します。
-
クレームするドメインが自社の所有するドメインであることを証明するには、生成された DNS トークンを含む TXT レコードを追加する必要があります。正確な手順はドメインホストによって異なります。一般的なガイドラインについては、ドメイン所有権の確認を参照してください。
-
手順を完了するには、DNS サーバーに追加で情報を入力します。効率的に作業できるように、事前に DNS マネージャーに連絡してください。
アドビは、ドメインの DNS レコードを定期的にチェックします。そして、DNS レコードが正しい場合は、ドメインは自動的に検証されます。Admin Console にログインして、手動ですぐにドメインを検証することも可能です。ドメイン検証を参照してください。
ドロップダウンリストから「DNS トークンにアクセス」を選択します。
DNS の変更が有効になるまで最大 72 時間かかることがあるため、検証時にエラーメッセージが表示される場合があります。詳しくは、DNS レコードに関するよくある質問 を参照してください。
ドメインの所有権の検証後、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 を使用する場合は、組織に関連付けられたドメインを追加する必要があります。このドメインが既に別の組織によって追加されている場合、そのドメインに含まれるディレクトリへのアクセスを共同利用権所有者として要求する必要があります。
ディレクトリへのアクセスを要求するには、上のドメインの設定にある、ドメインを追加する手順を参照してください。
警告：
ディレクトリの所有者が、そのディレクトリへのアクセス要求を承認すると、共同利用権を所有する組織はそのディレクトリに関連付けられているすべてのドメインにアクセスできるほか、以後そのディレクトリに関連付けられるすべてのドメインにもアクセスできます。このように、ドメインとディレクトリのリンク計画は、組織の ID システムを設定する上で不可欠な手順です。
Admin Console に既存のドメインを追加する場合は、次のメッセージが表示されます。
このドメインへのアクセスを要求すると、送信者の名前、電子メール、組織名が所有者組織のシステム管理者と共有されます。
ディレクトリのタイプ（Enterprise または Federated）は、所有者組織がおこなった設定によって決まります。そのため、所有者組織によって選ばれたタイプのディレクトリを使用する必要があります。
ドメインは既に所有者によって設定されているため（詳しくは、ドメインの設定の「ドメインの所有権を実証する」を参照）、共同利用権所有者は特に何もおこなう必要がありません。アクセス要求が所有者によって承認されると、共同利用権を所有する組織は所有者組織が構成したとおりに、ディレクトリとすべてのドメインにアクセスできます。
所有者組織のシステム管理者は、所有しているディレクトリへのアクセス要求を承認するか拒否するかを選択できます。
所有するディレクトリへのアクセス要求の電子メールを受け取ったら、その電子メール内から要求の承認または拒否を選択できます。また、「アクセス要求」タブに移動してクレーム要求を管理することもできます。
Admin Console 内で、ドメインをソースディレクトリからターゲットディレクトリに移動することで、ディレクトリを構造化できます。ドメインからディレクトリへのリンクは、エンドユーザーが製品、サービス、保存されたアセットにアクセスできる状態を維持したまま、組織のニーズに基づいて再編成できます。同じ ID プロバイダーに対して設定されたドメインを 1 つの同じディレクトリに統合することで、IT チームの管理が合理化されます。
警告：
- 現在サポートされていないため、以下に説明する手順を使用して、ドメインを SHA-1 ディレクトリから SHA-2 ディレクトリに移動させないでください。この移行については、Admin Console からサポートケースを開き、アドビエンタープライズサポートにお問い合わせください。
- ユーザーはアカウントからログアウトされ、ドメイン転送中は新しいセッションにログインできなくなります。エンドユーザーへの影響を最小限に抑えるため、オフピーク時にディレクトリを編集することをお勧めします。
この機能は、次のシナリオで利用できます。
- 信頼関係にあるディレクトリがある場合、または信頼のためにディレクトリを共有したいが、信頼されるディレクトリ内の一部のドメインにのみアクセスを許可する場合
- 組織チームと部門に基づいてディレクトリをグループ化する必要がある場合
- 1 つのドメインにリンクされている複数のディレクトリがあり、それらを統合する場合
- 誤ってドメインを間違ったディレクトリにリンクした場合
- ドメインをセルフサービスで Enterprise ID から Federated ID または Federated ID から Enterprise ID に移動する場合
警告：
暗号化されたディレクトリおよびドメイン間の移動は現在サポートされていません。
-
Adobe Admin Console にログインし、「設定」に移動します。
ドメインが正常に移動されると、システム管理者にドメインの移動についての電子メールが送信されます。次に、ディレクトリ名を編集し、必要に応じて空のディレクトリを削除します。
Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。