User Security Requirements

The security requirements for TA vary according to the task the user account needs to accomplish. The user account that installs TA components requires different security rights than an account that runs TA as a service. The user account that will operate TA has its own security needs. These points and the table below illustrate security rights differences between the various TA components.

TA Component	Installation Rights	Service Rights	User Rights
Windows Master	Local Administrator Able to access COM objects	Local Administrator or Local System Logon as a service Able to access COM objects	Local Administrator or Local System
Unix Master	Must be installed under a user created by root Access rights to JVM	Access rights to JVM	User account must be created by root Access rights to JVM
Windows Agent	Local Administrator Able to access COM objects	Local System or if running under Domain\User must have local administrator rights including: Logon as a batch job Logon as a service Act as part of the operating system Replace a process level token Able to access COM objects. On machines running Windows 2003, you also need these privileges: Bypass traverse checking Adjust memory quotas for the process User must be root or created by root Access rights to JVM	Local System or if running under Domain\User must have local administrator rights including: Logon as a batch job Logon as a service Act as part of the operating system Replace a process level token User must be root or created by root Access rights to JVM Ability to change to the runtime user
Unix Agent	Logon as root	N/A	N/A
Client Manager	Local Administrator Able to access COM objects	N/A	General user rights

Note: For the Windows Operating System, users must have administrator privileges instead of administrator group privileges.

Permissions after Installation

When installing TA, you should set the 'tidal' account to sysadmin for database creation. For normal operation, the product selects, updates, inserts, and deletes statements on the user tables in the TA data schema. During product upgrades, TA needs DBO privileges to perform the structural changes to the TA schema.

The product has been tested and verified with the 'tidal' user having DBO privileges, as testing and regression testing involves upgrading from prior product versions as part of Tidal’s verification process.

Note: If you choose to run with altered privileges that Tidal has not tested, you must revert to the tested/supported configuration in order to receive Tidal support when a support ticket is created.

Database Access

When installing a TA Master that uses an Oracle, Microsoft SQL, or PostgreSQL database, you will need the passwords for the database and database connections during installation. Agent and Master installations also require a Windows administrator to provide passwords during installation.

Installation

The Client Manager and agent should be installed under the same user name with equivalent capabilities.

Unix-specific Considerations

When installing TA Agent for Unix, you must be able to log in as root.

The TA Agent for Unix provides another layer of security by having its single Java process run as the agent owner with the same security rights as its owner. By default, access is disabled for all dependent files, scripts and environment variables for an agent. A Unix job cannot complete successfully unless you ensure that the agent has the proper access rights to all of the files required during the processing of a job.

Only the owner has read/write permissions for the logs directory and read/write/execute permissions for the tesm, fm, cm, tmkdea, and tesmcmd scripts for TA components installed on Linux/Unix.

Windows-specific Considerations

The Windows components require access to COM objects. To prevent an access violation error when an installation is attempted, verify that the user performing the installation can access COM objects. If necessary, the procedure to verify and provide access to COM objects is explained in Java Path Mismatch in the Troubleshooting chapter.

LDAP Considerations

LDAP users can be imported into TA to improve user audit trails. These imported users inherit security from multiple LDAP groups. Imported LDAP user information is stored in a user definition that includes email, telephone, and so on. Imported LDAP users are allowed to be owners of scheduling constructs such as jobs if their security permits it. User definitions must be migrated to LDAP groups.
The Administration group has three distinct entries for adding users, “Interactive Users”, “Runtime Users” and “LDAP Groups”. TA 6.x allows for a user setup that authenticates against Active Directory/LDAP. TA also supports AD/LDAP only users.
An AD/LDAP user is authenticated to TA provided the user’s AD/LDAP group and its hierarchy (nested groups) are registered with TA. For more information about creating nested LDAP groups through SAML with on-premises ADFS Services, see Creating Claim Rules.

Note: Nested LDAP groups are not supported for SAML with Azure ADFS.
When logging in, user credentials are validated against Active Directory/LDAP. Once authenticated, TA obtains the user’s AD/LDAP groups and other information such as phone number and email.
Once login has been completed, a record is established in TA to represent the Active Directory/LDAP only user if not already present and only if the user belongs to an Active Directory/LDAP group defined in. All user activity logging is then done against this new user record, allowing for correct auditing and reporting.
Active Directory/LDAP users can only create and own jobs and other objects if their security permissions permit.
TA LDAP groups are supported when the LDAP groups are created in the TA application.

Security Policies

Security policies can be defined and specialized by application administrators.
One security policy can be assigned to each group within TA.

Note: A user's security capabilities are based on the cumulative summation of security policies defined for each group in which the user is a member and any security policy directly assigned to the users specified in the TA system.

Workgroups and Security Policies

Workgroups are also available within the TA application. These workgroups can be used to own related objects. Users and groups can be made members of one or more workgroups. Workgroup security allows for additional security policies to be applied to scheduling constructs (jobs, view, alerts, etc.) owned by the workgroup for a particular user associated with the workgroup.

When a user or a group is made a workgroup member, then additional security policies can be applied to this relationship. The users’ total security capabilities will then be a summation of their user applied security policy, the security policy associated with each of the groups they are a member of, and the security policies contained in the relationship between the user or group and the workgroups they are a member of (in the context of objects contained in that workgroup).