ID の設定

検索

最終更新日 : 2021-08-31 | 次にも適用 : Creative Cloud for enterprise, Document Cloud for enterprise, Experience Cloud

アドビエンタープライズ版とグループ版：管理ガイド
デプロイメントの計画
1. 基本概念
2. デプロイメントガイド
  1. ユーザー指定デプロイメントガイド
  2. SDL デプロイメントガイド
3. Creative Cloud 教育機関向けのデプロイ
組織の設定
1. ID の設定
  1. ID タイプ | 概要
  2. Enterprise ID を使用した組織の設定
  3. Federated ID を使用した組織の設定
    1. SSO の概要
    2. Azure コネクタと Sync の設定
    3. Google Federation と Sync の設定
    4. 汎用 SAML
      1. 他の SAML プロバイダーとの SSO の設定
      2. Microsoft ADFS を使用した SSO の設定
      3. SSO のよくある質問
      4. SSO のトラブルシューティング
    5. 教育機関の SSO
  4. ドメインの所有権の確認
  5. ドメインの追加と管理
  6. ドメインをディレクトリにリンクする
  7. ディレクトリの信頼を使用した事前クレームされたドメインの追加
  8. 新しい認証プロバイダーへの移行
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 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 以前のアプリケーション）
アカウントの管理
レポートとログ
ヘルプを表示

警告：

2020 年 10 月 31 日をもって、Adobe は Adobe Admin Console 内のフェデレーションディレクトリに対する、非推奨の SHA-1 および SHA-256 パイロット証明書のサポートを終了します。警告アイコンが表示されているディレクトリは、移行が必要です。ディレクトリを選択して「編集」をクリックし、移行手順に従うだけで移行できます。

新しく作成したディレクトリはすべて、デフォルトで SHA-2 認証が有効になります。

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

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

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

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

SHA-1 ディレクトリを SHA-2 に移行する：古い SHA-1 認証済みディレクトリを SHA-2 プロファイルに更新します。
詳細情報 >

ディレクトリ全体にドメインを移動する：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 タイプの管理を参照してください。

SHA-1 と SHA-2 は、ディレクトリの認証プロファイルのセキュリティを担当する証明書モデルです。SHA-2 は従来型の SHA-1 証明書よりもセキュリティが優れているため、新しく移行された認証プロファイルはすべて SHA-2 証明書を使用します。

ディレクトリの作成

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

注意：

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

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

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

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

Enterprise ID
Azure または、Google 以外の SAML プロバイダー
Microsoft Azure または Google federation を使用しているが、Adobe のコネクタは使用していない場合。

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 コネクタを使用している場合は、Microsoft Azure AD コネクタの設定の手順に従います。
Google コネクタを使用している場合は、Google Federation（Google フェデレーションの設定）の手順に従います。

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

方法 1：

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

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

方法 2：

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

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

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

これでディレクトリが作成されます。

Enterprise ID を選択した場合、設定はこれで終了です。
「他の SAML プロバイダー」オプションを使用してディレクトリを作成した場合、このディレクトリでは自動的に SHA-2 認証が使用されます。これで、SHA-1 認証を使用して作成したディレクトリを SHA-2 に更新して、別の ID プロバイダーに移行できるようになりました。詳しくは、新しい認証プロバイダーへの移行を参照してください。

次に、Admin Console でドメインを設定します。

ディレクトリのプロビジョニング完了を通知する電子メールをアドビから受け取ったら、ディレクトリの SAML 設定を構成します。

組織がシングルサインオン（SSO）を構成して有効化すると、その組織のユーザーは企業の資格情報を使用してアドビのソフトウェアにアクセスできるようになります。ここでは、ユーザーは単一の資格情報を使用して、アドビのデスクトップアプリケーション、サービスおよびモバイルアプリにアクセスできます。

Adobe Admin Console を使用すると、企業ユーザーは既存の企業 ID を使用して認証をおこなえます。アドビの Federated ID は、シングルサインオン（SSO）ID 管理システムと連携します。シングルサインオンは、エンタープライズ ID 管理システムとアドビのようなクラウドサービスプロバイダーを結び付ける業界標準プロトコルである SAML を使用して有効化されます。

SSO により、サービスプロバイダー（ Adobe ）と貴社の ID プロバイダー（IdP）の間で認証情報を安全に交換することが可能になります。サービスプロバイダーがユーザー認証のため、IdP にリクエストを送信します。認証が完了したら、ユーザーログインのため IdP によってレスポンスメッセージが返されます。

SSO の要件

アドビソフトウェアに SSO をセットアップするには、IT 管理者は以下の要件を満たす必要があります。

SAML 2.0 の理解
ID プロバイダー（IdP）が SAML 2.0 をサポートし、少なくとも以下を備えていること
- IDP 証明書
- IDP ログイン URL
- IDP バインディング：HTTP-POST または HTTP-Redirect
- Assertion Consumer Service URL
- TLS 1.2 が有効
ドメインのクレーム処理のための DNS 構成へのアクセス

ユーザーがログインできるようにするために、IdP のログイン URL を外部からアクセス可能にする必要はありません。ただし、アクセスを組織の内部ネットワーク内に限定した場合、ユーザーがアドビ製品にログインできるのは、組織の内部ネットワークに直接接続しているか、WiFi や VPN 経由で接続しているときに限られます。ログインページへのアクセスを HTTPS 経由に限定することは必須ではありませんが、セキュリティ上の理由からは推奨しています。

注意：

現時点で、アドビは IdP-Initiated SSO をサポートしていません。

<ESAML>

アドビのクラウドサービスでは、Okta が提供する SaaS SAML 2.0 コネクタを使用して SSO を提供します。このコネクタを使用して、ID プロバイダーと通信し、認証サービスを提供します。Okta は多くの SAML 2.0 ID サービスプロバイダーに繋がっているため、お客様の ID プロバイダーサービスとして Okta を使用する必要はありません。詳しくは、シングルサインオン／一般的な質問を参照してください。

SSO 統合をテストする必要がある場合は、組織で所有するテストドメインをクレームすることをお勧めします。これは、ID がそのテストドメインで設定されている ID プロバイダーを組織が所有していれば実行できます。これによって、ドメインのクレームや構成プロセスに慣れるまで、統合をテストした後で、メインのドメインをクレームできます。

SAML 設定の構成

すでに ID プロバイダー（IdP）をお持ちの場合は、Okta が提供する SaaS SAML 2.0 コネクタを使用して SSO を簡単に構成できます。

注意：

Okta は、1 つの ID プロバイダーとして、多くのベンダーの中から選択できます。

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

「ディレクトリ」タブに移動します。

構成するディレクトリの「構成」をクリックします。

ディレクトリの構成画面で、次の操作をおこないます。

IDP 証明書：IdP が SAML レスポンスまたはアサーションの署名に使用する証明書（.cer）をアップロードするには「アップロード」をクリックします。

証明書がない場合は、証明書ファイルをダウンロードする手順について ID プロバイダーにお問い合わせください。

証明書に関する説明：

PEM（Base 64 encoded X.509）形式
.cer ファイル拡張子（.pem または .cert ではない）で指定
暗号化されていない
SHA-1
複数行形式（単一行は失敗する）
少なくとも 3 年の継続が必要（有効期間中のメンテナンスの手間を省き、セキュリティが確保される）

注意：

Federated ID ハンドシェイクのアドビ側で使用されている Okta 証明書は 20 年の証明書です。これにより、Adobe/Okta によって強制的におこなわれるのではなく、ユーザーの都合で証明書のローテーションを行えます。

IDP バインディング：SAML プロトコルメッセージの送信方法を選択します。

HTTP-Post を使用して、XHTML フォームを使い、ブラウザー経由で認証リクエストを送信します。IdP が、XHTML フォームを含むドキュメントにより応答します。
HTTP-Redirect を使用して、HTTP GET リクエストのクエリ文字列にある SAMLRequest 文字列パラメーターを通じて承認リクエストを送信します。IdP が、URL の SAMLResponse 文字列パラメーターにより応答します。

ユーザーログイン設定：このドメインのユーザーが自身を識別するのに、電子メールアドレスまたはユーザー名のいずれを使用するかを選択します。

IDP 発行者：SAML リクエストを発行する ID プロバイダーのエンティティ ID を入力します。

SAML アサーションはこの文字列を正確に参照する必要があります。スペル、文字または書式のいずれかが相違していると、エラーが発生します。

IDP ログイン URL：IDP ログイン URL / SSO アドレスを入力します。この URL は、ユーザーが認証時にリダイレクトされる場所です。

「保存」をクリックします。

「メタデータをダウンロード」をクリックします。

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

ID プロバイダーは、シングルサインオンを有効にするためにこのファイルが必要です。

警告：

一般的な SAML ID プロバイダー（OpenAthens、Shibboleth など）は、ユーザー名（通常、電子メールアドレス）を「指定なし」の形式の NameID として送信します。また、属性 FirstName、LastName、Email を送信します（大文字と小文字は区別されます）。

これらの属性は、Admin Console を使用して設定されたエントリに一致する必要があります。これらの属性が、SAML 2.0 コネクタ構成の一部として送信されるように IDP で構成されていない場合、認証は機能しません。

ID プロバイダー（IdP）との SSO 構成を完成させるには、ID プロバイダーのディレクトリマネージャーと共同作業します。

警告：

Federated ID がアクティブなときに構成を変更すると、エンドユーザーが SSO ログインに失敗する可能性があります。変更された構成によって新しいメタデータファイルが生成されます。このファイルは、IdP で再構成する必要があります。

ID プロバイダーとの SSO 構成が完了した後、Admin Console にログインし、設定／ID に移動します。

関連するディレクトリの「構成」をクリックします。

ディレクトリの設定画面で、ID プロバイダーとの構成が完了したことを確認し、「完了」をクリックします。

これでディレクトリがシングルサインオン用に構成されました。

Admin Console にドメインが追加されていない場合は、ここで追加できます。既に Admin Console にドメインが追加されている場合は、このディレクトリに必要なドメインをリンクすることができます。

ドメインのセットアップ

注意：

組織のディレクトリが Microsoft Azure AD コネクタまたは Google Federation の同期を介して設定されている場合、手動でドメインを追加する必要はありません。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 ユーザーとして追加されます。

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

警告：

ディレクトリの所有者が、そのディレクトリへのアクセス要求を承認すると、共同利用権を所有する組織はそのディレクトリに関連付けられているすべてのドメインにアクセスできるほか、以後そのディレクトリに関連付けられるすべてのドメインにもアクセスできます。このように、ドメインとディレクトリのリンク計画は、組織の 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／ユーザー／ユーザーを削除を選択して、ユーザーを削除します。削除されたユーザーのアセットはトラスティ組織に所有権があるため、組織が再利用できます。

暗号化キーの管理

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 内の新しい認証プロバイダーに移行できます。

警告：

IdP の既存の設定は、ディレクトリの 2～3 のアクティブなアカウントで新しい設定が正常におこなわれたことを確認するまで削除しないでください。

検証前に削除すると、以前の構成にロールバックできなくなり、問題が解決される間にダウンタイムが発生します。詳しくは、移行手順に従ってください。

アクセス要件

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

システム管理者の資格情報を使用して、組織の 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 の既存のユーザーに付与されたユーザー名の形式と一致することを確認します。

警告：

アドビは、2020 年 10 月 31 日をもって、Adobe Admin Console 内の統合ディレクトリに対する非推奨の SAML セットアップ（SHA-256 パイロットを含む）のサポートを終了します。

SAML アップデートを含む新しい認証プロファイルがアクティブになると、非推奨プロファイルは非アクティブのまま 7 日間使用できます。7 日が経過すると、非アクティブなプロファイルカードは、Adobe Admin Console のディレクトリから自動的に削除されます。削除された非推奨プロファイルは、Adobe Engineering でサポートリクエストを送信することによってのみ復元できます。

ディレクトリ設定を更新した後は、ドメインの移行を使用して、他の SHA-1 ディレクトリから新しいディレクトリにドメインを移動できます。移行されたドメインのユーザーは、新しいターゲットディレクトリで作業するように設定された 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 アプリを参照する同一のメタデータファイルをアップロードします。

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

警告：

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

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

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

古い SHA-1 をサポートするディレクトリにドメインがあり、SHA-2 でサポートされているディレクトリに移動する場合。
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 に移行する必要がある。	暗号化されたディレクトリとの間でのドメインの移動は現在サポートされていません。