Tealeaf stores session data (the hits that make up a session) in data stores located on the Processing and Storage machines.? When configured to use NT Authentication users who are members of specific Security Groups within an Active Directory (AD) domain are able to access this data.? If the machines and the users are part of the same AD domain there is no issue with the access.

However in a situation where the Tealeaf machines are hosted by one organization and the users of the Tealeaf data are in a different organization issues of trust arise.

On the Processing and Storage machines is a Tealeaf service called the Search Server (SS). On a Storage machine it is called the Archive Server (AS) but the code base as far as authentication is concerned is identical.? It is the SS that responds to requests from users for session data validates the user that is authorized to receive the data and sends it.? SS ordinarily runs under the LocalSystem account on the Tealeaf machines.

There are two user tools that make requests to the SS. One is the RealiTea Viewer (RTV).? The other is the Tealeaf Web Portal (an Internet Information Services (IIS) Web application).? In both applications when a user requests a session for replay the application sends along with the request the domain and userid of the person making the request. This information is available to the RealiTea Viewer (RTV) and Portal applications based on the information supplied by the user when they log in to the Windows domain.

When the SS receives this request it compares the domain and userid to a cached list it keeps.? If the domain and userid is a member of any of the groups that were specified to the SS as authorized groups the requested session is returned to the requesting application.

The SS populates its cache of authorized user groups by periodically calling Windows API functions specifically NetGroupGetUsers and NetLocalGroupGetMembers.? The first one queries global groups in a domain for a list of users that belong to the named security group.? The second one queries domain local security groups in a domain for a list of users that belong to the named security group.

For users in a domain e.g. OURDOMAIN to access data in Tealeaf machines that do not belong to the domain OURDOMAIN the following steps need to occur:

1) The domain administrators in the OURDOMAIN domain create global security groups in AD called: Tealeaf_admins Tealeaf_CSR. Tealeaf_ACSR Tealeaf_Marketing etc.

2) The domain administrators place into these groups the OURDOMAIN userids of the authorized Tealeaf users for each role.? Each userid appear in one or more global security groups.? These represent the users of the Tealeaf data and the different roles each userid may perform.? Think of roles in this context as the ability to access different segments of the Tealeaf data.

3) The Tealeaf machines are placed in a local domain called the resources domain. Think of this as the resource data that users want to get.

4) Domain administrators in the resources domain create a one-way (non-transitive) trust relationship from the OURDOMAIN domain to the resources domain.? In effect this says the resources domain (in a limited way) trusts the OURDOMAIN domain.

5) In the resources domain the domain administrator creates one or more domain-local security groups: Tealeaf_admins Tealeaf_CSR Tealeaf_ACSR Tealeaf_Marketing etc.

6) A resources domain administrator using a specific named user account in the OURDOMAIN domain with appropriate privileges populates the domain local security groups with the members of the corresponding OURDOMAIN global security group.? Note that the domain-local group cannot contain the name of the OURDOMAIN global group.? Each user of the OURDOMAIN global groups is explicitly listed in the domain-local groups as (e.g) OURDOMAIN\msmith or OURDOMAIN\jjones (necessary because anonymous SAM enumeration is no longer allowed).

7) The resources domain administrator or a member of the resources domain with appropriate privileges to log into the Tealeaf machines runs the Tealeaf SearchConfig.exe program.? This program specifies to SS the names of the resource domain local groups to add to the list that is allowed to get Tealeaf session data.? This program contacts the resources domain's Domain Controller (DC) to enumerate the contents of the resources domain-local groups. SearchConfig.exe runs as the logged-in user.

8) Every five minutes (by default) SS contacts the domain controller (DC) in the resources domain enumerates the domain local groups that it has been configured to use for authentication and caches this information (the list of userids and their domain local security group names or roles).? SS generally is running as LocalSystem on the Tealeaf machines and LocalSystem (usually) has permission to contact a DC and enumerate the groups it finds there.

When a user in the OURDOMAIN domain uses RTV (or Web Portal) to issue a request for access to the Tealeaf data the OURDOMAIN domain userid comes along with the request (e.g. OURDOMAIN\msmith).? SS checks this against the cached list and since the domain-local groups were populated with the trusted global groups members (OURDOMAIN\msmith etc.) the passed credentials are found in the cached list and SS gives back the requested information.

Creating a small resources domain is not free of cost.? It requires Primary and Backup Domain Controller machines.? These are dedicated as none of the Tealeaf software can run on a Domain Controller (this is because the layout of the Windows Registry on a DC is different from the Registry layout of a normal server).? The resources domain is created the domain-local groups are created and initially populated and the maintenance of the membership in the domain-local groups requires some staff time.? In spite of these drawbacks it provides the mechanism to allow Tealeaf users in one corporate domain access to Tealeaf data stored in machines that are members of a different corporate domain.

Note: The above solution describes creating Tealeaf security groups in the OURDOMAIN domain.? Doing so is not strictly necessary.? It is sufficient to create the domain-local security groups in the resources domain and populate them with users from the OURDOMAIN domains.? There is one reason why global security groups in the OURDOMAIN are needed.? If any of the Tealeaf servers (especially the IIS Portal Web server) resides in the OURDOMAIN domain those servers need to query the Tealeaf group membership.? To perform the lookup in the OURDOMAIN domain the global groups in OURDOMAIN need to be created and populated.

Using domain-local security groups requires a sufficiently recent release of Storage Server and Archive Server.

00000217