Enable desktop SSO authentication

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 desktop logon. Then the user accesses the application.

When you use IWA for your IdP, and you set application-facing authentication mechanism as Kerberos for your EAA applications, you need to configure Kerberos constrained delegation.

When you use IWA for your IdP, and 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 derived from FQDN. If using a custom domain, it is derived from 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.

  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 on a subnet 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)

Description of use IWA parameter used in Integrated Windows Authentication (IWA) settings

Description of use IWA parameter used in Integrated Windows Authentication (IWA) settings shown in the below table helps to interpret the meaning of the use IWA parameter in IWA settings. For users to experience desktop SSO with their windows applications, you should configure the use IWA parameter as described in the below table.

Use IWA valueInterpretation
Never (default)Desktop SSO is never used on this IdP. IWA is disabled.
AlwaysIWA is enabled. Desktop SSO is always used with this IdP, irrespective of whether the user is on or off the premise, device characteristics like browser or operating system type. If user is off the network, they are not be able to authenticate with the IdP. If they are off-net or device that has not joined the windows domain, they get troubleshooting issues in IWA.
When-applicableIWA is enabled. Desktop SSO is only used when ALL of these configured conditions are satisfied: (1) The device is on-net (either when the user is on VPN or on a subnet that matches the value in on premise subnet and user on premise checked on the domain joined computer. See Add public IP gateways to an IdP to add on premise subnet. (2) User's browser matches the regular expression configured. (3) User's operating system matches the regular expression configured. If any of these conditions are not met, user is presented with login form for entering username and password.

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. For more information see Add a directory to an identity provider, and Add users and invite them to the cloud directory.

  2. Configure a new IdP log into the EAA Management Portal.

    a. In the EAA Management Portal 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. Select 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:

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.

  1. Upload the keytab file for IWA in EAA Management Portal.

a. In the EAA Management Portal 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 example ADDomain.com.
  • For Keytab Type select Integrated windows authentication.
  • Upload your keytab file, select Choose File. Select the keytab file, for 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.

  1. 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 provider. Move to step 6.
    e. To use IWA sometimes under certain conditions, like certain Operating Systems, Browsers, the user is on-premise in certain subnets, for Use IWA, select When Applicable. See Description of use IWA parameter used in Integrated Windows Authentication settings.
    f. In the Settings tab, scroll down to the Advanced section. In On premise subnets enter a list of all the outbound Internet gateways.
    g. Go back to the Integrated Windows Authentication (IWA) Settings section, and select User on premise.
    h. 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 regular expression `^((?!Firefox).)*$`.
    

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

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

- For Windows 8, use 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**.

j. Click Save.
k. Deploy the IdP.

  1. 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.

  1. 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.

Did this page help you?