Minimum Permissions for Scan Accounts
Forcepoint DSPM / Structured Data now supports scanning Teradata as a data source for cataloging and classification.
| 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=ANSIandCHARSET=UTF8are always set by the connector. -
SSLMODE=REQUIREandSSLPROTOCOL=TLSv1.2are applied automatically on the FIPS image. On the non-FIPS (standard) image the driver's defaults are used; customers can override via the connector'soptionsfield 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
- Connection test and database metadata
Operation Catalog views read Minimum grant Test connection - LOGONon connecting hostDatabase (schema) enumeration DBC.DatabasesVSELECT ON DBCTable/view listing DBC.TablesV,SELECT ON DBCColumn / PK / FK metadata (bulk prefetch) DBC.ColumnsV,DBC.IndicesV,DBC.All_RI_ChildrenVSELECT ON DBCApproximate row count DBC.StatsVSELECT ON DBCApproximate table & index size DBC.TableSizeVSELECT ON DBCNote:DBC.StatsVonly has a row when statistics have been collected on the table. The connector tolerates missing rows and reportsnullrather than failing the scan. - Data sampling
Operation Tables read Minimum grant SAMPLE nrow sample for classificationTarget user table/view SELECTon 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.
- Trustee (users + roles) extraction
Operation Catalog views read Minimum grant List Teradata users DBC.UsersVSELECT ON DBCList Teradata roles DBC.RoleInfoVSELECT ON DBCRecursive role-membership graph DBC.RoleMembersVSELECT ON DBCUsers come from
DBC.UsersV; roles come fromDBC.RoleInfoV. Both feeds are merged into the trustee list and exposed to the platform asuserandgrouprespectively. - Permissions extraction
Operation Catalog views read Minimum grant Database-level grants (per user) DBC.AllRightsV (TableName='All')SELECT ON DBCDatabase-level grants (per role) DBC.AllRoleRightsV (TableName='All')SELECT ON DBCSchema-level grants DBC.AllRightsV, DBC.AllRoleRightsVSELECT ON DBCTable-level grants DBC.AllRightsV, DBC.AllRoleRightsVSELECT ON DBCColumn-level grants DBC.AllRightsV,DBC.AllRoleRightsVSELECT ON DBCSuper-admin holders ( DBC,SYSDBA, anyone with administrative rights onDBC)DBC.UsersV,DBC.AllRightsVSELECT 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
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.
-- 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 scopeNetwork: the Teradata listener port (default 1025) must be reachable from the connector host.
Verification
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
-
DBCuser /SYSDBAuser credentials. -
Administrative rights on the
DBCdatabase (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,CREATEon any user database. -
Workload-management / Viewpoint /
TDWM/TDQCMaccess.
-
Non-FIPS (standard) deployment: TLS is not forced by default — the Teradata driver's
SSLMODEdefaults toALLOW, which permits unencrypted sessions. Customers who require encryption should setSSLMODE=REQUIRE(and optionallySSLPROTOCOL=TLSv1.2) in the connector'soptionsfield. -
FIPS deployment: TLS is forced (
SSLMODE=REQUIRE) and the protocol floor is pinned toTLSv1.2automatically by the connector — no customer action required. The host JDK additionally routes TLS through the FIPS-validated NSS module.