To authorize user access to applications in Enterprise Application Access (EAA), you add directories and associate them with connectors. Then you add groups with permissions and specify user membership.

📘

Note:

You can also try out Connector Pools to add multiple connectors and associate them to directories. For more information, see our Beta feature, Connector Pools, Application Access Groups (AAG).

For new accounts, Enterprise Application Access creates a default Cloud Directory that you can use to add users and groups. You should also assign directories to identity providers (IdPs), to provide identity as a service.

Directory services supported by Enterprise Application Access:

• EAA Cloud Directory. Every tenant is provisioned with an EAA Cloud Directory to provide quick access to applications without Active Directory (AD) integration or to extend third party or contractor access to applications without VPN. By default all users are part of the main Users group. Enterprise Application Access doesn't store or cache passwords for users.

• AD. Active Directory is a directory service that automates domain network management. In order to integrate an AD to Enterprise Application Access (EAA), the AD must be able to communicate with connectors and associate with an identity provider (IdP). The connector must be ready and reachable, and in the same private network as your AD. You also need to have a functional Active Directory setup with admin privileges. In AD integration, the connector works as an LDAP client and synchronizes the user database and other attributes, such as group, in the EAA management edge for authentication. The AD authenticates with the connector through host information such as an IP address or URL for the directory, and the internal port number. Enterprise Application Access supports multi-Active Directory or multi-AD configuration to authenticate users against multiple, on-premise AD forests to provide access to enterprise applications.

• LDAP. Lightweight Directory Access Protocol is a platform-independent software protocol that enables location of organizations, individuals, and other resources such as files and devices in a network, on the public Internet or internal intranet. Select this directory type if you are using an LDAP or OpenLDAP directory.

📘

Prerequisite

The LDAP directory must have ldap class posixGroup.

• AD LDS. Active Directory Lightweight Directory Access Protocol is a directory service designed for use with directory-enabled applications. It operates independently of the AD and AD domains or forests, yet provides dedicated directory services for applications.
  To use AD LDS with Enterprise Application Access configure an application partition in the AD LDS to hold application data such as users and groups.

• SCIM. The System for Cross-domain Identity Management (SCIM) specification is an open API designed to make managing user identities in cloud-based applications and services easier and faster. Enterprise Application Access (EAA) supports SCIM provisioning with Azure Active Directory and with Okta. It allows to obtain users' and groups' information quickly, sync between identity stores in near real-time and apply enforcement policies. EAA also allows user and group membership SCIM provisioning from OneLogin to EAA using generic SCIM.

You can grant a user a directory administrator role to configure directories or a custom administrator role to manage the administration tasks for multiple resources with role-based access control in ​Akamai Control Center​.

👍

If you have more than 20 directories configured, only the first 20 directories are listed, when you want to assign a directory to the identity provider.

Directory server certificate validation rules and use cases

Use Host and Host Aliases for Directory origin server certificate validation.

EAA connector performs a directory (either AD, LDAP, AD LDS) origin server validation using the CA certificate that you upload into ​Akamai​ Enterprise Center. EAA connector does a hostname validation against the directory server to confirm its identity.

EAA connector uses the Host and Host Aliases fields in the directory configuration to validate the LDAPS origin server identity.

For this, the EAA connector does a match of server identity presented in the server certificate's DNS name in the Subject Alternative Name (SAN) or the Common Name (CN) in the Subject against Host in directory configuration in Enterprise Application Access, with SAN having the highest priority. If the server certificate includes a SAN of type DNS name, only that is considered for doing the host match, otherwise the server certificate's CN (the subject field) is considered. If you have multiple domain controllers or you entered an IP address for the Host, you can use the Host Aliases field to match the LDAPS server's identity.

Use cases:

• Use Case 1. A single domain is represented by two domain controllers (DC1 and DC2). Host matches SAN (DNS name). CN is ignored. Host-aliases is not needed.

In Enterprise Application Access to configure the directory, provide the domain name for the Host:

Both domain controllers have the domain name mydirectory.mycompany.com in the SAN.

Domain Controller1's server certificate has these values for CN and SAN:

Domain Controller2's server certificate has these values for CN and SAN:

Since the Host matches SAN, CN is ignored. Host Aliases is not needed in the configuration. Since there is a server match, the origin server is validated.

• Use Case 2. A single domain is represented by one domain controller (DC1). Host has an IP address. Server certificate for DC1 only has a CN that represents the FQDN of DC1. So use Host-Aliases with the CN value.

In Enterprise Application Access to configure the directory, provide an IP address for the Host:

Domain Controller1's server certificate has a CN and does not have a SAN:

You provide the CN value in Host-Aliases field:

Since there is no SAN, CN value provided in the host-aliases is considered a host match and origin server is validated.

• Use Case 3. A single domain is represented by two domain controllers (DC1 and DC2). Host has a different domain name that does not match the CN in both server certificates. SAN is absent in both server certificates. Use Host-Aliases with CN values of both certificates.

In Enterprise Application Access to configure the directory, provide the domain name for the Host:

Let's assume each domain controller has it's own domain controller certificate. This domain name is not there in any of the domain controller certificates.

Domain Controller1's server certificate has a CN and does not have a SAN:

Domain Controller2's server certificate has a CN and does not have a SAN:

You can use Host Aliases to configure the host names that match the server identity. Since, SAN is absent, you can provide the CN values of the two domain controllers:

CN values of the certificates of both the domain controllers (DC1 and DC2) are provided in the host-aliases as comma-separated values. Since there is no SAN, if Enterprise Application Access reaches any of the domain controllers, it is considered a host match and origin server is validated.

Alternatively, if you don't configure Host Aliases, the EAA connector does a DNS lookup on the Host value for resolving the DNS and if it returns a single or multiple CNAMEs, the EAA connector use them for host match.
EAA connector supports also a wildcard match for the hostname validation.