Support for SHA-2 Authentication: Previously, directories were always based on the SHA-1 protocol. Now, any newly created directories will always use the more secure SHA-2 protocol.
Also, you're not required to enable SHA-2 authentication, it is on, by default.
As a system admin on the Admin Console, one of your first tasks is to define and set up an identity system against which your end users will be authenticated. As your organization purchases licenses for Adobe products and services, you will need to provision those licenses to your end users. And for this, you will need a way to authenticate these users.
Adobe provides you with the following identity types that you can use to authenticate your end users:
- Adobe ID
- Enterprise ID
- Federated ID
If you want to have separate accounts owned and controlled by your organization for users in your domain, you must use either Enterprise ID or Federated ID (for Single- Sign-On) identity types.
This article provides the details required to set up the identity system that you will need if you plan to use Enterprise ID or Federated ID to authenticate your end users.
The set up directory and set up domain procedures described in this document are completely decoupled. This means that you can do these procedures in any order or in parallel. However, the procedure to link email domains to directories will be done only after you have completed both these procedures.
Organization identity provider such as Active Directory, Azure, Ping, Okta, InCommon, or Shibboleth.
To know more about setting up SSO for Creative Cloud with some of the commonly used IdPs, see More like this at the end of the article.
Created, owned and managed by the end user. Adobe performs the authentication and the end user manages the identity. Users retain complete control over files and data associated with their ID. Users can purchase additional products and services from Adobe. Admins invite users to join the organization, and can remove them. However, users cannot be locked out from their Adobe ID accounts. The admin can't delete or take over the accounts. No setup is necessary before you can start using Adobe IDs.
The following are a few requirements and scenarios, where Adobe IDs are recommended:
- If you want to enable users to create, own, and manage their identities.
- If you want to allow users to purchase or sign up for other Adobe products and services.
- If users are expected to use other Adobe services, which do not currently support Enterprise or Federated IDs.
- If users already have Adobe IDs, and associated data such as files, fonts, or settings.
- In educational setups, where students can retain their Adobe ID after they graduate.
- If you have contractors and freelancers who do not use email addresses on domains you control.
- If you have an Adobe teams contract, you will need to use this identity type
Created, owned, and managed by an organization. Adobe hosts the Enterprise ID and performs authentication, but the organization maintains the Enterprise ID. End users cannot sign up and create an Enterprise ID, nor can they sign up for additional products and services from Adobe using an Enterprise ID.
Admins create an Enterprise ID and issue it to a user. Admins can revoke access to products and services by taking over the account, or deleting the Enterprise ID to permanently block access to associated data.
The following are a few requirements and scenarios where Enterprise IDs are recommended:
- If you need to maintain strict control over apps and services available to a user.
- If you need emergency access to files and data associated with an ID.
- If you need the ability to completely block or delete a user account.
Created and owned by an organization, and linked to the enterprise directory via federation. The organization manages credentials and processes Single Sign-On via a SAML2 Identity Provider (IdP).
The following are a few requirements and scenarios where Federated IDs are recommended:
- If you want to provision users based on your organization's enterprise directory.
- If you want to manage authentication of users.
- If you need to maintain strict control over apps and services available to a user.
- If you want to allow users to use the same email address to sign up for an Adobe ID.
The Identity Provider must be TLS 1.2 compliant.
The portion of an email address after the @ symbol. To use a domain with Enterprise or Federated ID, you must first validate your ownership of that domain.
For example, if an organization owns multiple domains (geometrixx.com, support.geometrixx.com, contact.geometrixx.com) but their employees are authenticated against geometrixx.com. In this case, the organization will use the geometrixx.com domain to set up their identity on the Admin Console.
- Works with IdP directory managers and DNS managers to set up identity in the Admin Console. This document is targeted at System admins who will have access to the Admin Console. The persona is expected to work with the other personas who (usually) will not have access to the Admin Console.
User identities are verified against an authentication source. To use Enterprise ID or Federated ID, set up your own authentication source by adding a domain. For example, if your email address is email@example.com, example.com is your domain. Adding a domain permits the creation of Enterprise IDs or Federated IDs with email addresses on the domain. A domain can be used either with Enterprise IDs or Federated IDs, but not both. You can however add multiple domains.
An organization must validate their control over a domain. An organization can also add multiple domains. However, a domain can be added only once. Known public and generic domains, such as gmail.com or yahoo.com cannot be added at all.
To know more about the Identity types, see Manage identity types.
To use Enterprise IDs or Federated IDs, start by creating a directory to which you can link one or more domains.
Choose Enterprise ID and click Create Directory, or choose Federated ID and click Next and move to step 5.
If you have chosen to create an Enterprise ID directory, you are done. Go ahead and set up your domains in the Admin Console.
(Federated ID only) Choose your IdP from the provided options, then:
- To configure an identity provider (IdP) using SAML, click Next for Other SAML Providers.
- Click Next for Microsoft Azure and follow the steps under Create a directory section in Set up Azure AD Connector.
- Click Next for Google and follow the steps under Create a directory section in Set up Google federation.
The rest of the steps in this procedure are required only if you choose Other SAML Providers.
In the Add SAML profile screen, create your SAML profile.
Some Identity Providers (IdP) accept a metadata file that you can upload. While others may require the ACS URL and the Entity ID. Depending on your IdP, choose one of the following options. For example:
- For Azure: Upload the metadata file.
- For Google: Copy the ACS URL and Entity ID and use these in the Google IdP software.
- For SalesForce: Download the metadata file, extract the certificate information from the file and use that certificate information in SalesForce IdP software.
Click Download Adobe Metadata file.
The metadata file is downloaded to your local disk. Use this file to configure your SAML integration with the Identity Provider.
Copy the ACS URL and the Entity ID.
If you have a CA-signed certificate, in the Admin Console, navigate to Support > Support Summary and create a support case.
Your directory is created.
If you have chosen to create a directory using the Other SAML Providers option, this directory uses SHA-2 authentication. However, previously created directories used SHA-1 authentication.
You can now go ahead and set up your domains in the Admin Console.
Your end users are authenticated against domains that you need to set up in the Admin Console.
To set up domains:
- Add domains to the Admin Console
- Prepare to validate domain ownership by adding a special DNS record
- Validate the domains
The domains that you add to the Admin Console do not need to be registered with the same IdP. However, when you link these domains to a directory, you need to link domains from different IdPs to different directories.
You cannot add a domain to the Admin Console if it has already been added to another organization's Admin Console. You can, however, request access to that domain.
An organization must demonstrate their ownership of a domain. An organization can add as many domains to the Admin Console as required.
The Admin Console allows one organization to use a single DNS token to demonstrate ownership of all its domains. Also, the Admin Console does not require DNS validation for subdomains. This means that when you use the DNS token and demonstrate ownership of a domain, all subdomains of that domain are validated instantly as they are added to the Admin Console.
Add information to your DNS servers to complete this step. Let your DNS manager know in advance so that this step can be completed in a timely manner.
Adobe periodically checks the DNS records for your domain. And, if they are correct, the domain is validated automatically. If you want to validate the domain immediately, you can sign into the Admin Console and validate it manually. See Domain validation.
The Admin Console attempts to validate domains you have added several times a day, so you need not take any action to validate a domain once the DNS records are properly configured.
If you need to validate your domain immediately, you can do this on the Admin Console. To manually validate your domains:
You can now link the validated domains to the required directories in the Admin Console.
The ownership of a domain can only be claimed by a single organization. So consider the following scenario:
A company, Geometrixx, has multiple departments, each of which has their own unique Admin Console. Also, each department wants to use Federated user IDs, all using the geometrixx.com domain. In this case, the system administrator for each of these departments would want to claim this domain for authentication. The Admin Console prevents a domain from being added to more than one different organization's Admin Console. However, once added by a single department, other departments can request access to the directory to which that domain is linked on behalf of their organization's Admin Console.
Directory trusting allows a directory owner to trust other system admins (trustees). After this, trustee organizations in the Admin Console can add users to any domain within the trusted directory.
To summarize. If you plan to use Enterprise or Federated ID on your Admin Console, you must add the domain associated with your organization. If this domain was previously added by another organization, you have to request access to the directory containing that domain as a trustee.
To request access to a directory, see the steps in the Add domains procedure in Set up domains above.
As an owner of a directory, if you approve an access request for that directory, the trustee organization will have access to all domains linked to that directory, as well as any domains linked to that directory in the future. So planning the domain-to-directory linking is essential as you set up the identity system in your organization.
If you add existing domains to the Admin Console, you are prompted with the following message:
If you request access to this domain, your name, email, and organization name is shared with the request to the system administrators of the owning organization.
The type of directory (Enterprise or Federated) depends on how it was set up by the owning organization. This means that you must use whichever directory type was chosen by the owning organization.
Since the domain has already been set up by the owner (see Demonstrate ownership of the domains in the Set up domains for details), as the trustee, you do not need to take any additional action. When the access request is accepted by the owner, your organization will have access to the directory and all it's domains, as configured by the owning organization.
If your request access to the directory is accepted by the owning organization, you receive an email notification. Your trust request disappears and instead the trusted directory and it's domains appear with the status Active (trusted) in your Directories and Domains listings.
As the trustee organization, if you no longer have a need to access the trusted directory, you may withdraw your trustee status at any time.
If you withdraw your access to a trusted directory, any Enterprise ID or Federated ID users that belong to domains in that directory (meaning that they log in using the domain credentials) are removed from your organization. Also, these users lose access to any software granted to them by your organization.
As a system administrator of an owning organization, you can choose to accept or reject the requests for access to the directories that you own.
When you get an email request for access to a directory you own, you can either choose to accept or reject the request from within the email itself. You can also go to the Access Requests tab to manage the claim requests.
While all data on Creative Cloud and Document Cloud is encrypted, you can choose to have Adobe generate dedicated encryption keys for accounts in a directory that you create.
Organizations can structure directories by moving domains from source directories to target directories within the Admin Console. You can reorganize domain-to-directory linking based on your organization’s needs without end users losing access to their products, services, or stored assets. Consolidating domains configured for the same identity provider into a single directory streamlines management for your IT teams.
- Do not move domains from SHA-1 to SHA-2 directories using the procedure described below as this is not currently supported. For this migration, contact Adobe Enterprise support by opening a support case from the Admin Console.
- Users are logged out of their accounts and cannot log into a new session during domain transfer. It's recommended to edit directories in off-peak hours to minimize end user disruption.
You can benefit from this feature in the following scenarios:
- You have directories in a trust relationship or want to share directories for trusting, without allowing access to all domains within the trusted directory.
- You have to group directories based on organization teams and departments.
- You have a number of directories that are linked to single domains and wish to consolidate.
- You accidentally linked a domain to an incorrect directory.
- You want to self-serve move a domain from Enterprise ID to Federated ID or Federated ID to Enterprise ID.
To move domains to or from an encrypted directory
To move a domain from one Admin Console org to another
To move domains between directories that are in a trust relationship with each other
To move domains between directories that are in trust relationships but not with each other
You are sent to the Domains section under Settings > Identity. All the domains with their status are listed.
Once the domains have been transferred successfully, the system admins receive an email about the domain transfer. Next, you can edit directory names and delete empty directories as required.
You cannot delete a directory that has:
- Active users
- Linked domains
You cannot remove a domain if there are users with that domain in the Admin Console or if the domain is linked to one or more directories.