You can now move domains across directories without removing users from the domain or losing access to users' assets.
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 firstname.lastname@example.org, 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 setting up a directory to which you can link one or more domains.
To set up a directory:
- Create a directory in the Admin Console.
- (Federated ID only, except Microsoft Azure or Google as IdP) Adobe will provision the directory. This usually takes up to 48 hours.
- If you set up your organization for Enterprise ID identity, you can start linking your email domains to the directory.
- (Federated ID only) After Adobe has provisioned your directory, configure the SAML settings for the directory.
(Federated ID only) Choose your IdP from the provided options, then:
Your directory is created.
If you have chosen to create an Enterprise ID identity type directory, you are done. Go ahead and set up your domains in the Admin Console.
If you have chosen to create a Federated ID identity type directory with an identity provider other than Microsoft Azure or Google, Adobe will need to provision this directory before you can proceed with any more operations on it. However, you don't need to wait around while Adobe provisions the directory. You can go ahead and set up your domains in the Admin Console.
Provisioning Federated ID type directories using the custom SAML-based method typically takes up to 48 hours. You are notified by email when it is done.
After you receive the email from Adobe confirming that your directory is provisioned, configure the SAML settings for the directory.
When organizations configure and enable Single Sign-On (SSO), users in that organization are able to use their corporate credentials to access Adobe software. This enables users to use a single credential to access Adobe desktop apps, services, and mobile apps.
The Adobe Admin Console offers a method for enterprise users to authenticate using their existing corporate identity. Adobe Federated IDs enable integration with a Single Sign-On (SSO) identity management system. Single Sign-On is enabled using SAML, an industry-standard protocol that connects enterprise identity management systems to cloud service providers like Adobe.
SSO can securely exchange authentication information between two parties: the service provider (Adobe) and your Identity Provider (IdP). The service provider sends a request to your IdP, which attempts to authenticate the user. If authentication is successful, the IdP sends a response message to sign in the user.
To successfully set up SSO for Adobe software, IT Admins need the following:
- An understanding of SAML 2.0
- An Identity Provider (IdP) that supports SAML 2.0, and at a minimum must have:
- IDP Certificate
- IDP Login URL
- IDP Binding: HTTP-POST or HTTP-Redirect
- Assertion consumer service URL
- TLS 1.2 enabled
- Access to your DNS configuration for the domain claim process
The login URL of the IdP does not need to be externally accessible for users to be able to access it for logging in. However, if it is only reachable within the organization's internal network, users can only log in to Adobe products when they are connected to the organization's internal network either directly, via wifi or via VPN. It is not necessary for the login page to be accessible only via HTTPS, but it is recommended for security reasons.
Currently, Adobe does not support IdP-initiated SSO.
Adobe’s cloud services offer SSO using a SaaS SAML 2.0 connector provided by Okta. The connector is used to communicate with your identity provider to provide authentication services. You are not required to use Okta as your identity provider service since Okta connects to many SAML 2.0 identity service providers. For more information, see SSO / Common questions.
If your organization wants to test SSO integration, it is recommended that you claim a test domain that you own, as long as your organization has an Identity Provider with identities set up in that test domain. This allows you to test the integration before you claim the main domains, until you feel comfortable with the domain claim and configuration process.
If you already have an Identity Provider (IdP), you can easily set up your SSO configuration using the SaaS SAML 2.0 connector provided by Okta.
Okta is one of the many vendors you can choose to use as an Identity Provider.
IDP Certificate: To upload the certificate (.cer) that your IdP uses to sign the SAML response or assertion, click Upload.
If you don't have the certificate, contact your Identity Provider for instructions to download the certificate file.
- PEM (base-64 encoded X.509) format
- Named with a .cer filename extension (not .pem or .cert)
- Multi-line format (single line fails)
- Must last a minimum of three years (it saves the maintenance over that lifespan, and does not compromise security)
The Okta certificates used at Adobe's side of the Federated ID handshake are 20-year certificates. This is so that you can do certificate rotation on a schedule of your own choice, rather than being forced to do it by Adobe/Okta.
IDP Binding: Choose the method to transmit SAML protocol messages.
- Use HTTP-Post to transmit the authorization request via the browser using an XHTML form. The IdP also responds with a document containing an XHTML form.
- Use HTTP-Redirect to transmit the authorization request via the SAMLRequest string parameter in the URL query string of an HTTP GET request. The IdP responds with a SAMLResponse string parameter in the URL.
User Login Setting: Choose Email Address or Username to specify how users of this domain will identify themselves.
IDP Issuer: Enter the entity ID of the identity provider that issues the SAML request.
Your SAML assertion must reference this string exactly. Any difference in spelling, characters, or formatting results in an error.
Click Download Metadata.
The metadata file is downloaded to your local disk. Use this file to configure your SAML integration with the Identity Provider.
Your Identity Provider requires this file to enable Single Sign-On.
For generic SAML identity providers such as OpenAthens or Shibboleth, send the username (usually email address) as the NameID in format 'unspecified'. Also, send the following attributes (case-sensitive): FirstName, LastName, Email.
These attributes must match the entries set up via the Admin Console. If these attributes are not configured in the IDP to be sent over as part of the SAML 2.0 Connector configuration, the authentication will not work.
Work with your Identity Provider (IdP) directory manager to complete the SSO configuration with your Identity Provider.
If Federated ID is active, any changes to the configuration may cause the SSO logins to fail for end users. A changed configuration generates a new metadata file that needs to be reconfigured in the IdP.
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 now 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.
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.