Enterprise Application Access (EAA) new software release.

EAA Client versions

EAA Client for Windows/macOS: version 2.1.2 (build number is 20110505)
EAA Client mobile app for iOS: version 1.0
EAA Client mobile app for Android: version 1.0

Akamai EAA new features

User diagnostics and troubleshooting. User diagnostics workflow can be used by administrators to quickly diagnose and find the root-cause for commonly faced issues during application access. Designed as a workflow, customers provide the username, identity provider (IdP URL) accessed, a time window, and devices used. The retrieved data includes the top applications accessed by the user, ACL and authorization policies violated by the user and network performance as viewed from within the EAA service.
Connector health monitoring. The connector health monitoring widget has been significantly upgraded in this release. The load indicator on the connector card provides a simple stop-light view on its health. The performance tab provides rich information like state of system resources, nature of EAA dial-outs, as well as number of active connections per connector are now available for each connector that is active.
Application configuration versioning. Starting with this release, the EAA service supports application configuration versioning. Administrators can automatically roll back to a previous version where possible, and easily compare different configuration versions and identify changes.
Bypass of multi-factor authentication. Administrators can enable bypass MFA criteria like a managed device check or a corporate network IP check, to determine if MFA is prompted for users during the sign-in process. Corporate gateway subnet verification is used to determine if a request from the corporate network. Client certificate (User Store) validation is used to determine if a device is managed.
EAA APIs. The Open API documentation provides better API segmentation, clearer documentation for the user, group, application, IdP, directory, and includes Device Posture API.
Support for customer configurable ciphers. Allows the administrator to select a default or custom cipher suite to be used for TLS client-server handshake before starting a TLS secure communication. It can be configured in the advanced settings within an application’s configuration.
Crowdstrike Integration for Device Posture. Customers using Crowdstrike Falcon Error Detection and Response (EDR) can enable EAA to check the Crowdstrike cloud to validate the health and validity of the Falcon sensor on the device. This can be used as a device posture signal which can be used for application access control rules (ACL).
Device Posture checks device certificate validity. Administrators can enable a new device posture signal to confirm the presence of a valid device certificate on the device. A valid certificate helps EAA distinguish an organization’s owned and managed device from others, and can also be used as a signal for an ACL for applications.
VMware Carbon Black for Device Posture. An updated API from VMware has been integrated with Device posture to provide an additional layer of security and protection between Akamai EAA Cloud and VMware Carbon Black cloud communication.
Identity provider username in Device Posture reports. Device Posture reports show the identity provider (IdP) username that is present in authentication login sessions, correlating device posture signal to the user.

Akamai EAA Client end of support

With this release, Akamai is announcing the end of support for all EAA 1.x.x Clients. Customers using 1.x.x Clients are requested to migrate to 2.1.0 or later versions of EAA.

Upgrade of EAA Client 2.1.0 or later release:

The recommended upgrade procedure for the 2.1.0 or later releases is to directly upgrade over the existing 2.0.x installations. If the user is running a 1.x.x version of the EAA Client they must uninstall it before installing version 2.1.0 or later release.

If the user has an active EAA session at the time of upgrade, they are automatically logged out. After the user logs in again and resumes application access, the device ID is updated and usage may continue as normal.

EAA Client 2.1.0 installation and `akamai-device-id` changes:

When you install EAA Client, a unique identifier called the akamai-device-id is associated with the EAA Client. With EAA Client 2.1.0 release, a new algorithm is used to generate the device ID for each device. Due to this change, after you install new EAA Client, each device automatically gets a new device ID. This change is to address an issue with EAA Client used on computers created using a Microsoft Windows image. A problem may occur that results in the EAA Client reporting duplicate device IDs. When creating the source image for use on multiple computers, certain operating system identifiers used by the EAA Client may be duplicated if not properly prepared. This issue is addressed with EAA Client 2.1.0.

EAA activity reports, Clients overview dashboard, Device Posture dashboard may include old akamai-device-id, resulting in inaccurate statistics until the old akamai-device-id is purged after 90 days.

EAA and EAA Client limitations

User diagnostics do not show Device Posture ACL policy violations for access-applications (clientless apps).
User diagnostics do not show browser-based SSH, bookmark, or SaaS applications.
User diagnostics is not supported on Internet Explorer version 11 due to unsupported fonts.
Connector health monitoring is not supported on Internet Explorer version 11 due to unsupported fonts.
Integrated Windows Authentication (IWA) fails intermittently while accessing from a new browser session and the identity provider (IdP) will prompt for form-based authentication. Authentication will succeed if we refresh the browser session or open the IdP URL in a new tab.
If you access an application that has bypass MFA criteria set to certification validation check enabled and appropriate settings are done, you are redirected to the identity provider login portal after authentication. The user should then access the application from the login portal.
Bypass MFA feature is not supported when the Certificate Identity is Username field is unchecked in the General settings of the identity provider and Device is Managed is used as a Bypass MFA criteria. Users will be prompted for MFA.

Device Posture limitations

When you use the EAA Client mobile app on Android devices when logging into an IdP from either a Chrome browser or via the QR code, if the user switches apps before the configuration is complete, it may cause the EAA Client to crash.
When you use the EAA Client mobile app on mobile devices to log into an MFA enabled Akamai IdP, you may need to enter the MFA code twice, once while logging into the mobile browser, and second when redirected to the EAA Client mobile app login screen.
When you install the EAA Client on Windows and open EAA Client, navigate to Device Posture > Signals, the username is the admin’s name and not the current user name. The workaround is to quit and restart the EAA Client.
When you use the EAA Client mobile app on mobile devices to log into an Akamai IdP with a QR code, you may have problems opening the app and may see a loading screen with a spinner. Close the application and re-open or, login to the IdP with a mobile browser. Another workaround is to do a second scan of the same QR code, after reopening the app when the first scan fails. Third-party IdPs are not affected.
EAA Client mobile app on an Android device works only if Chromium-based Browser (Chrome, Samsung browser, Microsoft Edge) is set as the default browser. On other browsers, users will see a remediation message, Ensure EAA Client is installed or configured correctly.
When you use the EAA Client app on iOS 14, iPadOS 14 devices and Safari is not the default browser, users will see a remediation message, Ensure EAA Client is installed or configured correctly when accessing a web app from the browser.
When you use the EAA Client app on iOS devices for authorization to a third-party IdP with or without MFA, the user is stuck in the authorization loop process (user accesses third-party IdP URL on iOS browser, OS opens EAA Client app, the user completes authorization and MFA, the user is redirected back to the browser again, OS opens EAA Client app again, loop repeats).
When you use the EAA Client mobile app on iOS devices to log into an Akamai IdP, you may be directed to the EAA Client and are prompted to log in again using the in-app browser window. After you enter login credentials, the app may hang with a loading screen and a spinner. To recover, you must close and reopen the EAA Client application. Then, you must log out of the IdP using the browser and log in again to the IdP via the mobile browser a second time. Third-party IdPs are not affected and can be used with QR code or the Safari browser.

Fixed customer bugs

Tunnel-type client-access application sessions are terminated within 5 minutes for a user, who is blocked by block user functionality.
Tunnel-type client-access applications can be saved when login credentials are used with Firefox Lockwise.
Tunnel-type client-access applications have a case-sensitivity check for application hostnames.
User and groups sync improvements for better integration between Okta IdP and Active Directory.
Client Details reports have been increased up to 10 000 records.
Use sticky cookies for connectors for tunnel-type client-access applications with TCP optimization enabled is supported.
False EAA Client upgrade notifications have been resolved.
Added pagination support for the Groups page under Active Directory.
Any custom application inside the RDP application window is not maximized any more.
SSH Audit report download support is extended from three months to one year.