The Experience Analytics CX Report Server Configuration tool contains several methods for authenticating user access.
To access the configuration methods:
- Log in to the Portal as an administrator.
- In the Portal menu, navigate to TMS.
- Click the Experience Analytics node.
- Click Shared configuration information.
- In the Config Actions, click View/Edit.
- Click the Portal tab.
Portal (Database) authentication
By default, the Portal is configured to use Portal authentication, which leverages the Portal user management capabilities to control access. The Portal uses its own authentication mechanism, which is useful for organizations preferring to separate Experience Analytics from their corporate authentication systems.
- MD5 - This method only exists to support early customers configuring via the MD5 mechanism.
Note: New Experience Analytics systems should not deploy this authentication mechanism.
- RC2 - Passwords are encrypted using RC2.
- 3DES - Passwords are encrypted using 3DES (Default)
- NT - N/A
NT (AD - Active Directory) authentication
Under NT authentication mode, only valid NT accounts are permitted to log in to the Portal. Users submitting credentials that cannot be validated against the NT domain are not granted access.
- In Mixed Mode, NT users and accounts created through the Portal can access the Portal.
- When a user performs a search, the Portal application passes the user's NT credentials to the Search Server, which validates those credentials against the NT domain. If those credentials are not valid, no data is returned from Search Server.
Organizations that wish to integrate Portal logins with their existing AD groups may do so:
- MD5/RC2/3DES - When Allow Mixed Mode Logon is enabled, these three methods are available. Although the system is in NT mode, Mixed Mode allows a Portal authentication account to successfully login to the Portal.
Note: With the exception of the designated user group type administrators (admin, revealadmin and viewadmin), Portal authentication accounts do not have access to event or session information, which are controlled by the search server under NT authentication. Mixed Mode allows an administrator to login and do account management regardless of the state of the NT authentication configuration.
- NT - This option should be used when NT/AD authentication is desired.
- Active Directory user login names should not included any accented characters.
- If you are using an NT account to access the SQL Server database, you must use an NT domain account with appropriate privileges. Additional factors should be considered.
When NT authentication is enabled, you can configure the Portal to auto-create new Experience Analytics user accounts when authenticated NT users first contact the Portal.
Note: If you use NT Authentication and you need to delete one of your users, remove them from Experience Analytics first and then from the Windows Active Directory. Otherwise, you'll see an error.
Support for Sub-Domains
NT authentication supports the following formats of NT domain user names:
- The full domain:
- The subdomain only:
- The domain only:
Configuring Active Directory
To enable NT authentication use by Experience Analytics, some additional configuration within Active Directory may be required.
After you have enabled NT authentication, you may need to configure additional permissions for your user account or accounts.
When NT authentication is in use, the Portal can be configured to allow authorized users in the domain to automatically login when they visit the Portal login page.
- In the CX Settings, the
Automatic NT User Loginsetting must be set to
NT users who have logged in may log out:
- when no action is taken for the period of time, the user is automatically logged out.
- manually by clicking the Logout button.
When NT users automatically log out, they can login manually back into the Portal by visiting the Portal login page. This manual login enables NT users to optionally use a non-NT (Database) account to log into the Portal assuming mixed-mode authentication has been enabled.
- Subsequent logins after a successful login revert to the auto-login method for the user.
Mixed mode authentication
When NT authentication is enabled, you can optionally enable Mixed Mode authentication, which is useful for performing initial administrative tasks.
In addition to authenticating the standard NT credentials, Mixed Mode supports authentication using the Portal user credentials.
Note: Mixed Mode is intended for user management in an NT environment if an NT account with sufficient permissions is not available. It should not be used for other Portal features or general Portal use after accounts have been created or otherwise managed.
Note: Experience Analytics Mixed Mode authentication is not related to the mixed mode authentication method available in SQL Server.
Under NT Authentication, users authenticating with Portal credentials have some restrictions; they cannot retrieve events, cannot search, and other restrictions. In Mixed Mode, these same restrictions still apply, yet Portal users with the correct administration permissions can manage Portal users and their permissions. By using Mixed Mode, Experience Analytics administrators can grant to NT users the appropriate permissions to use and manage the Portal.
For example, suppose the Experience Analytics administrator left the company and his NT account is disabled. You can use Mixed Mode authentication to login using the default administrator account (
ADMIN) and re-assign menu and group permissions to a new administrator.
Note: Mixed Mode authentication is not intended as an additional mechanism for end users to use. It serves an administrative function for managing the initial NT accounts that are later assigned the necessary administrative permissions to manage users.
Web services authentication
Like the Portal application, the Portal Web Service (PortalAPI) supports all three methods of authentication: Portal (accounts defined in the Portal), NT (NT/Active Directory accounts) and Single Sign On. Since the Portal and Portal Web Service are both ASP.NET applications, authentication methods for both can be set in similar ways.
However, the Portal Web Service does not have a user interface to enter user credentials, so one of three methods must be used to enable Portal authentication for the Portal Web Service:
- Modify the
AnonAccessPortalAccountvalue in the
Web.Configfile to take the Portal account username. This setting enables Anonymous mode for the Portal Web Service, which allows execution of all requests as the specified user.
Note: This field takes the internal Portal account username, not the User ID.
- Clear the
AnonAccessPortalAcountvalue in the
Web.Configfile. If NT/SSO credentials cannot be established and
AnonAccessPortalAccountis not set, initial connections to the Web Service will be unauthenticated and will not be allowed to go through. At this point, the user must authenticate via the /Authenticate method which accepts a Portal username and password.
Note: This mode works if the Portal Web Service is being called programmatically but is an inconvenience if using the Portal Web Service to provide a replay URL to end users.
true. When an authenticated request is made, a username/password dialog is displayed in the browser, where the authenticating user can enter his or her Portal credentials.
Note: The configuration mode for the Portal Web Service should be set depending on the use case.
Single Sign On (SSO) authentication
The Portal supports authentication integration with most third-party providers via HTTP request headers.
When the SSO mechanism supplies an authenticated username, the Portal performs the login and allows access to the Portal. The Portal relies on the SSO authentication method to ensure the Portal is protected from unauthenticated users and that the SSO headers are valid and unaltered.
- To the Portal, an SSO login is the same as a Portal authentication login.
- SSO users can manually logout and then login again using different credentials.
The flag to enable SSO support and the header configuration is in the following file
<configuration> ... <appSettings> ... <add key="ENABLE_SITEMINDER_SSO" value="false"/> <add key="SITEMINDER_USERNAME_HEADER" value="SM_USER"/> <add key="SITEMINDER_SESSIONID_HEADER" value="SM_SERVERSESSIONID"/> <add key="SITEMINDER_LOGOUT_URL" value=""/> ... </appSettings> ...</configuration>
Note: The configuration options below can be used to provide the required configuration values for other SSO providers.
||The flag to enable (true) or disable (false) SSO/SiteMinder integration.|
||The HTTP request header that specifies the account/user name. The default Experience Analytics value is also the SiteMinder default:
||The HTTP request header that specifies the SiteMinder session ID. The default Experience Analytics value is also the SiteMinder default:
||The HTTP request header that specifies the SSO logout URL. If supplied, the Portal logout button redirects the user to the specified URL to end the current SSO session. If the value is left blank (default), the logout button is hidden, as the Portal cannot end an SSO connection. For the Portal to successfully read the user's NT/AD credentials, IIS must have anonymous access disabled and integrated windows authentication enabled. From the Windows™ Start menu, these settings can be configured in the Control panel: Administrative Tools > Internet Information Services (IIS) Manager > HOSTNAME (local computer) > Web Sites > Default Web Site > Portal > Properties > Directory Security > Edit (Authentication and access control).|