Enterprise Application Access (EAA) identity service supports Kerberos-based Integrated Windows Authentication (IWA) to provide a seamless desktop single sign-on (SSO) experience for on-net users to ​Akamai​ identity provider (IdP) to access applications. When users log in to their domain-joined computer with their network credentials, they can automatically authenticate to the ​Akamai​ IdP and access applications through the Enterprise Application Access Cloud service without entering their username and password again.

To support desktop SSO, the IdP endpoint responds to authentication requests with Kerberos authentication challenges. The browser on the user's desktop is configured to trust the IdP service for desktop SSO and respond to the Kerberos challenges using the user credentials cached during a desktop logon. Then the user accesses the application.

When you use IWA for your IdP, and if you set application-facing authentication mechanism as Kerberos for your EAA applications, you need to configure [Kerberos constrained delegation] (doc:kerberos-constrained-delegation).

When you use IWA for your IdP, and if you set application-facing authentication mechanism as NTLM for your EAA applications or auto-login for RDP applications, the user is prompted for password once for each user login session.

IWA workflow overview

To add desktop SSO or integrated windows authentication (IWA) capability to your ​Akamai​ identity provider (IdP) involves these high-level steps. The configuration details are described in Configure desktop SSO for an Akamai IdP

1. Derive the service principal name (SPN) for the ​Akamai​ IdP. If you use ​Akamai​ domain, it is the FQDN. If using a custom domain, it is the CNAME.

2. The SPN should be registered to a unique service account in Active Directory (AD) controller. It should be in the domains of the users who log in through the ​Akamai​ IdP portal.

3. A keytab file should be generated for the service account created in your AD domains. If you have multiple domains or forests with different trusted relationships, you should create separate keytab files for each of them.

4. Upload the keytab file or files for all of the above domains into EAA admin portal.

5. Enable the IWA in ​Akamai​ IdP with always or when-applicable options. See description of IWA parameter settings.

6. Select the keytab file or files for the ​Akamai​ IdP.

7. Integrated windows authentication (IWA) can be conditionally applied to computers capable of responding to Kerberos challenge. The devices should have all of the capabilities:

   • On-net (have a VPN connection or a network zone specified in the IWA settings)
   • Able to reach Active Directories
   • Support Kerberos SSO
   • Regular expressions may also be configured for device operating systems, device browsers to match User agent strings when Use IWA is configured as when-applicable.

User agent strings

When any user sends a request to access a web application, the web browser sends a HTTP header called the user agent. The user agent string contains information about the user's web browser name, operating system, device type, and other information.

The common format for a user agent string is:

User-Agent: <product> / <product-version> <comment>

This varies among different browsers. Here are some examples of user agent strings:

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101Firefox/47.0

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)

Interpretation of Use IWA arguments used in Integrated Windows Authentication Settings

The meaning of the different arguments like Never, Always, and When-applicable for Use IWA is described in the table below.

Configure desktop SSO for an Akamai IdP

Configure Enterprise Application Access (EAA) and Active Directory (AD) controller to support desktop SSO for an identity provider (IdP).

1. Create a directory (AD or LDAP) and sync the user for the domain.

2. Configure a new IdP log into the Enterprise Center.

   a. In the Enterprise Center navigation menu, select Application Access > Identity & Users > Identity providers.

   b. Select Add Identity provider (+).

   c. Enter a name, description, and select the provider type as ​Akamai​.

   d. Click Continue.

   e. From Settings > General, note down the Identity server hostname. If you use ​Akamai​ domain as the identity server, note down the FQDN. Your FQDN will be of the form https://YOUR-IDP-NAME.login.go.akamai-access.com. If you use your own domain, note down the CNAME.

   f. Click Save.

   g. In Directories select Associate.

   h. Select the directory and click Associate.
   The cloud directory appears under the Directories.

   i. Leave all the other tabs as default.

   j. Click Save.

3. Create a keytab file in Microsoft Active Directory controller:

   a. Create a service account in Active Directory for EAA login.

   b. Generate a keytab file for the IWA. Use Microsoft ktpass utility. For more information see Microsoft ktpass usage.

The format for the running ktpass command and generating the keytab is shown in the example below:

ktpass /out ActiveDirectorydomain.keytab /princ HTTP/yourloginportalurl@ADDomain.com /mapuser serviceaccount@ADdomain.com /pass +rndPass /crypto All /ptype KRB5_NT_PRINCIPAL

For yourloginportalurl use the following:

• if you use your own domain, use the CNAME noted in 2.e step.

• If you use ​Akamai​ domain, use the FQDN noted in 2.e step. For this example, https://YOUR-IDP-NAME.login.go.akamai-access.com

The value for /princ argument is the Service Principal Name (SPN) and in this example ADDomain is the realm.

You should have a keytab file called ActiveDirectorydomain.keytab that's created on your computer.

4. Upload the keytab file for IWA in Enterprise Center.

a. In the Enterprise Center navigation menu, select Application Access > Identity & Users > Keytabs.

b. Click Add New Keytab (+).

c. Provide the keytab information:

• Name. A unique identifier for the keytab.
• Realm. Provide the service domain that you want ​Akamai​ IdP to do desktop SSO, for this example ADDomain.com.
• For Keytab Type select Integrated windows authentication.
• Upload your keytab file, select Choose File. Select the keytab file, for this example ActiveDirectorydomain.keytab from previous steps. Click Save. The keytab appears as a card on the Keytabs page.

You should upload one keytab file for each forest or domain. It should have the correct SPN derived from the hostname/FQDN of the IdP when you use ​Akamai​ Domain, or CNAME of the IdP when you use your own domain in the keytab file you generated. If you have multiple domains with one-way or two-way trusted relationships, upload all the keytab files.

5. Configure all of the integrated windows authentication settings for the identity provider.

a. Open the IdP you created in step 2.

b. In the Settings tab, scroll down to the Integrated Windows Authentication (IWA) Settings section. You can select either always or when applicable for using IWA.

c. To always use IWA, for Use IWA select Always. See Description of use IWA parameter used in Integrated Windows Authentication settings.

d. In Keytabs select the name of the keytab file for this IdP. For example, ActiveDirectorydomain.keytab. You can select multiple keytabs. Click Associate. Click Save and deploy the identity provide. Move to step 6.

e. To use IWA sometimes under certain conditions, like certains Operating Systems, Browsers, user is on premise within certain network zones, for Use IWA, select When Applicable. See Description of use IWA parameter used in Integrated Windows Authentication settings.

f. In Keytabs select the name of the keytab file for this IdP. For example, ActiveDirectorydomain.keytab. You can select multiple keytabs.

g. Select User on premise

h. In the On Network Zones provide the network zones where IWA is applied when the user is in this zone. If the user is outside this network zone, IWA is not applied.

• To configure a new network zone, select Add New Network Zone, provide a network zone name, add an IP/CIDR or a comma-separated list of IPs/CIDRs, select Add new Network Zone to the list upon created, and Save. Your newly configured network zone should be selected for IWA.
  

• To use an existing network zone, select Manage Network Zones, select the network zone from the list, and click Save. Your existing network zone should be selected for IWA.

• If you have the IPs/CIDRs as a .csv file on your machine, you can upload it using the import icon.

i. In Browsers add a regular expression for multiple browsers. For example:

• For IE browser, use regular expression ([MS]?IE) (\d+)\.(\d+).

• To exclude Firefox browser and include all other browsers, use the regular expression ^((?!Firefox).)*$.

j. In Operating Systems add a regular expression for multiple operating systems. For example:

• For Windows 10, use the regular expression (Windows NT 6\.4)|(Windows NT 10\.0).

• For Windows 8, use the regular expression (Windows NT 6\.2)|(Windows NT 6\.3).

  📘

  User on premise, Browsers and Operating Systems can be configured only if Use IWA is set to when-applicable.

k. Click Save.

l. Deploy the identity provider.

6. You or the end-user have to add the ​Akamai​ IdP hostname as local intranet zone.

To ensure identity provider (IdP) URL is added to trusted site to do automatic logon with kerberos for IWA for all users in the organization you should make the following updates on the users computers:

• Update the security settings in local intranet zones to allow automatic logons.

• Add ​Akamai​ IdP URL to the intranet zone.

You can use group policies to push these changes on user's computer.

Alternatively, if users want to perform the above tasks they can do from their computer from Internet Explorer > Internet options.

7. Verify the EAA IdP setup and access to application.

a. Log in to a domain joined computer with your network credentials.

b. Ensure IdP URL is added to trusted site to do automatic logon with Kerberos.

c. Access the Identity Portal URL.

d. User automatically signs into the IdP. The end-user can access the applications on the IdP portal.