Search Server authentication lets you define a list of users that have administrative or general user privileges to perform operations such as searching and retrieving session data, editing events, or modifying system settings.
When authentication is configured for Search Server, visitor requests automatically present the Windows™ domain and username of the currently logged-in account. The login information is checked to determine the following:
- Whether the user exists on the domain specified
- Whether the user actually belongs to the group specified and has restricted access based on the group. This group defines the types of tasks the user can perform in the client. For example, a user who is a member of the user's group may be able to search and not to configure events.
If the user belongs to none of the groups, access is completely denied.
Authentication Slaves
Authentication Master setting on each authentication slave server.Debugging Search server authentication
For authorization, the Search Server uses the same user ID that issued the Event Maintenance command to read and update the slave Search Servers. If a slave Search Server rejects those commands, then it can be inferred that slave servers are running with a different authorization configuration.
Examining the Search Server logs generally identifies the problem. When Search Server restarts with authorization enabled, the list of defined users accessible to it are inserted into the log.
- Search Server is typically restarted at 1AM. At restart time, the Search Server log also lists OperatingParams, which indicate the authorization mode and other operating parameters.
- If you know the time that saving events failed, you can examine the slave server log at that time for the /NTYP command from Search Server to identify the user name it's using and then compare that ID to the user list from the last restart.
Portal authentication
The Search Server can be configured to authenticate user access through the Portal authentication mechanisms. Configuring portal authentication is similar to how you can configure NT authentication for Search Server .
By default, Search Server assumes that the following Portal user groups have administration privileges:
admin groupevent admin
To view the members of a user or admin group, select the group and click List Group.
Like NT authentication, Portal authentication supports the use of privacy keys and data segmentation.
NT authentication
Tealeaf CX is capable of using NT domain information to authenticate users and restrict access to specific functionality based on user identity. The two components of Tealeaf CX that can be configured to use NT authentication are the Portal and the Search Server service.
NT authentication relies on querying a Windows NT™ domain controller to determine existence of users and their NT user group memberships.
Search Server NT authentication
Search Server authentication lets you define a list of users who have general or administrative privileges to perform operations such as searching for and retrieving session data, editing events, or modifying shared CX RealiTea Viewer settings profiles.
When configured, clients of Search Server authenticate the currently logged in user before allowing access to Search Server's functions. The login information is checked to determine if the user belongs to the NT group specified and to restrict access based on the applicable group. For example, a user who is a member of the Search Server Users group only can search but cannot configure events.
If the user belongs to none of the groups defined in the Search Server authentication settings, access is denied to that user.
- In the case of the CX RealiTea Viewer, a denied user cannot search for sessions or edit events.
- In the case of the Portal, a denied user cannot perform searches.