Minimum Permissions for Scan Accounts

Forcepoint DSPM / Structured Data now supports scanning Teradata as a data source for cataloging and classification.

Connection Prerequisites
Requirement Reason
Network reachability to the Teradata server host:port (default 1025) Establish TCP connection
A Teradata user with LOGON rights from the connector host Establish JDBC session
Scan user owns or has access to a database to use as a default DATABASE= qualifier The JDBC driver requires a database context. In Teradata every user owns a database of the same name, so the user's own database is a safe default.

The connector uses the official Teradata JDBC driver (com.teradata.jdbc.TeraDriver). No DBC superuser membership is required.

JDBC URL emitted by the connector

The connector assembles the URL automatically — customers do not need to construct it manually. Documented here for reference / troubleshooting:

jdbc:teradata://<host>/DATABASE=<database>,DBS_PORT=<port>,TMODE=ANSI,CHARSET=UTF8,SSLMODE=REQUIRE,SSLPROTOCOL=TLSv1.2
  • TMODE=ANSI and CHARSET=UTF8 are always set by the connector.

  • SSLMODE=REQUIRE and SSLPROTOCOL=TLSv1.2 are applied automatically on the FIPS image. On the non-FIPS (standard) image the driver's defaults are used; customers can override via the connector's options field if they need to force TLS.

Supported Teradata versions

Teradata 17.20 and later (Vantage). The connector relies on DBC.ColumnsV, DBC.IndicesV, DBC.All_RI_ChildrenV, DBC.StatsV, DBC.RoleMembersV, DBC.AllRightsV, DBC.AllRoleRightsV, DBC.RoleInfoV, DBC.UsersV, DBC.DatabasesV, DBC.TablesV, DBC.TableSizeV — all available in 17.20+.

How Teradata handles DBC.* access

Teradata's data-dictionary views live in the built-in DBC database. By default, ordinary users can read rows about themselves from these views but not rows about other users / databases. To enumerate schemas, tables, columns, trustees and permissions across the customer's data, the scan account must be granted SELECT on the DBC database (which transitively grants read on every DBC.* view the connector uses).

Operations and Required Permissions

  1. Connection test and database metadata
    Operation Catalog views read Minimum grant
    Test connection - LOGON on connecting host
    Database (schema) enumeration DBC.DatabasesV SELECT ON DBC
    Table/view listing DBC.TablesV, SELECT ON DBC
    Column / PK / FK metadata (bulk prefetch) DBC.ColumnsV, DBC.IndicesV, DBC.All_RI_ChildrenV SELECT ON DBC
    Approximate row count DBC.StatsV SELECT ON DBC
    Approximate table & index size DBC.TableSizeV SELECT ON DBC
    Note: DBC.StatsV only has a row when statistics have been collected on the table. The connector tolerates missing rows and reports null rather than failing the scan.
  2. Data sampling
    Operation Tables read Minimum grant
    SAMPLE n row sample for classification Target user table/view SELECT on the table / view (or on its containing database)
    Column payload sampling Target user table/view Same as above

    The connector uses Teradata's native SAMPLE n clause (not TABLESAMPLE) and adds an ORDER BY 1 so the sampled rows are returned in stable order across AMPs.

  3. Trustee (users + roles) extraction
    Operation Catalog views read Minimum grant
    List Teradata users DBC.UsersV SELECT ON DBC
    List Teradata roles DBC.RoleInfoV SELECT ON DBC
    Recursive role-membership graph DBC.RoleMembersV SELECT ON DBC

    Users come from DBC.UsersV; roles come from DBC.RoleInfoV. Both feeds are merged into the trustee list and exposed to the platform as user and group respectively.

  4. Permissions extraction
    Operation Catalog views read Minimum grant
    Database-level grants (per user) DBC.AllRightsV (TableName='All') SELECT ON DBC
    Database-level grants (per role) DBC.AllRoleRightsV (TableName='All') SELECT ON DBC
    Schema-level grants DBC.AllRightsV, DBC.AllRoleRightsV SELECT ON DBC
    Table-level grants DBC.AllRightsV, DBC.AllRoleRightsV SELECT ON DBC
    Column-level grants DBC.AllRightsV, DBC.AllRoleRightsV SELECT ON DBC
    Super-admin holders (DBC, SYSDBA, anyone with administrative rights on DBC) DBC.UsersV, DBC.AllRightsV SELECT ON DBC

System schemas excluded by the connector

The connector automatically excludes Teradata system databases / users from scan scope, so customers do not need to grant the scan account access to any of them. These include (non-exhaustive): DBC, SYSADMIN, SYSTEMFE, SYSLIB, SYSUDTLIB, SYSSPATIAL, SYSUIF, SYSJDBC, SYS_CALENDAR, SYSBAR, SQLJ, SAS_SYSFNLIB, TDPUSER, TDSTATS, TDMAPS, TDWM, TDQCD, TDQCM, TDMETA, TDBCMGMT, TDAAS_*, TD_SERVER_DB, TD_ANALYTICS_DB, TD_METRIC_SVC, TD_MLDB, TD_MODELOPS, TD_SYSAI, TD_VAL, EXTERNAL_AP, EXTUSER, SYSDBA, DBCMNGR, DBCMANAGER, PDCRINFO, PDCRDATA, PDCRSTG, SYS_TIME_ZONE, LOCKLOGSHREDDER, CONSOLE, VIEWPOINT, TD_SYSFNLIB, TD_SYSGPL, TD_SYSXML, CRASHDUMPS.

Granting data access

For a full-tenant scan, grant SELECT on every user database the customer wants in scope. The cleanest pattern is to grant on each user database individually.
GRANT SELECT ON <user_database> TO fp_user;

Repeat for each database to be scanned. New databases created later require a follow-up grant; Teradata does not have a "default privileges" equivalent to PostgreSQL's ALTER DEFAULT PRIVILEGES.

Consolidated grant script
-- 1) Create the scan user. Teradata creates a database of the same name automatically.
CREATE USER fp_user FROM <parent_database> AS
    PERM = 10000000,
    SPOOL = 50000000,
    PASSWORD = '<STRONG_PASSWORD>';

-- 2) Allow login from any host (or restrict via LOGON RULES if required).
GRANT LOGON ON ALL TO fp_user;

-- 3) Metadata access — read on the data dictionary
GRANT SELECT ON DBC TO fp_user;

-- 4) Data + permissions extraction — read on each user database to be scanned
GRANT SELECT ON <user_database_1> TO fp_user;
GRANT SELECT ON <user_database_2> TO fp_user;
-- ...repeat for every user database in scan scope

Network: the Teradata listener port (default 1025) must be reachable from the connector host.

Verification

Connect as fp_user and run:
-- Connection + role memberships
SELECT USER, DATABASE;
SELECT RoleName FROM DBC.RoleMembersV WHERE Grantee = USER;

-- Metadata access
SELECT DatabaseName FROM DBC.DatabasesV SAMPLE 5;
SELECT TableName FROM DBC.TablesV WHERE DatabaseName = '<user_database_1>' SAMPLE 5;
SELECT ColumnName FROM DBC.ColumnsV WHERE DatabaseName = '<user_database_1>' SAMPLE 5;

-- Data sampling
SELECT * FROM <user_database_1>.<table> SAMPLE 5;

-- Trustee scan
SELECT UserName FROM DBC.UsersV SAMPLE 5;
SELECT RoleName FROM DBC.RoleInfoV SAMPLE 5;

-- Permissions extraction
SELECT * FROM DBC.AllRightsV SAMPLE 5;
SELECT * FROM DBC.AllRoleRightsV SAMPLE 5;

All queries should return without an authorization error. Empty result sets are acceptable.

What is not required

The scan account does not need any of the following:
  • DBC user / SYSDBA user credentials.

  • Administrative rights on the DBC database (AE, AF, AP, DP, DA) — the connector reports holders of these as super-admins, but the scan account itself does not need them.

  • INSERT, UPDATE, DELETE, DROP, CREATE on any user database.

  • Workload-management / Viewpoint / TDWM / TDQCM access.

TLS / encryption
  • Non-FIPS (standard) deployment: TLS is not forced by default — the Teradata driver's SSLMODE defaults to ALLOW, which permits unencrypted sessions. Customers who require encryption should set SSLMODE=REQUIRE (and optionally SSLPROTOCOL=TLSv1.2) in the connector's options field.

  • FIPS deployment: TLS is forced (SSLMODE=REQUIRE) and the protocol floor is pinned to TLSv1.2 automatically by the connector — no customer action required. The host JDK additionally routes TLS through the FIPS-validated NSS module.