Teradata Security: Users, Roles, Logon Controls and Vantage Hardening Steps

A Teradata Vantage system often holds an organisation's most complete copy of its business data, so who can log on, from where, with which privileges, and what gets logged decide how well that data is protected. This guide covers the customer side of Teradata security: user DBC and the administrative user hierarchy, the security administrator role, database users, roles and profiles, password and logon controls, directory and Kerberos authentication through Teradata Generic Security Services (TDGSS), encryption in transit, access logging and VantageCloud network settings. It is written for Teradata DBAs, security administrators and data platform owners. For controls common to every database engine, see the Database Security Guide.

This is an independent guide from NHI Mgmt Group, based on Teradata's public documentation as of November 2026. It is not sponsored or reviewed by Teradata. Product features change, so confirm settings against Teradata's current documentation.

Key takeaways

• Use DBC to build the hierarchy, then put it away. Teradata advises that administrative users perform most functions under their own names, not as DBC, and that the DBC password is limited to the most trusted staff. Never alter DBC's privileges.
• Create a security administrator. A SECADMIN style user owns users, roles, profiles, password defaults, logon rules and access logging, separate from day to day database administration.
• Grant through roles. Roles give consistent privileges and faster logon checks; Vantage allows a single level of role nesting, so keep the design flat.
• Control logons, not just passwords. Set DBC.SysSecDefaults password controls, use GRANT LOGON to decide which host IDs each user may log on from, and keep WITH NULL PASSWORD for externally authenticated communities only.
• Log access and protect the logs. Use BEGIN LOGGING rules for sensitive objects and privileged users, log use of the logging and logon rule macros themselves, and forward DBC.AccLogTbl entries to your SIEM before purging.

How identity and access work in Teradata

Vantage authenticates users through TDGSS, configured by the security administrator in the TDGSS configuration files, and authorises them through privileges granted directly or through roles. A logon can be checked by the database itself or by an external mechanism.

The mechanism security policy in TDGSS decides which mechanisms each client may use and in what order, so check it whenever you add or retire a mechanism. Directory-based authentication moves joiner, mover and leaver handling into the directory, which is usually the stronger choice for human users at scale; keep a small number of database-authenticated administrative users for recovery if the directory is unreachable. For directory protocol hardening, see the LDAP Security Deep Dive Guide.

Roles and profiles

• Roles: created with CREATE ROLE, granted privileges, then granted to users. Role privileges add to direct grants. A role can have many members and a user can hold several roles, but only one level of nesting is allowed: a role that has member roles cannot itself be a member of another role. Some privileges cannot be granted to a role and must go directly to a user; keep a list of these as they are exceptions to review.
• Directory roles: roles can be assigned to directory users, so a directory group change grants or removes database access without a DBA running GRANT.
• Profiles: created by the security administrator and assigned to users to set shared attributes, including password settings that differ from the system defaults, for groups such as service accounts or contractors.
• Session changes: a privilege granted to a role takes effect immediately for members who have that role active, which helps fast revocation during an incident.

Admin roles and privileged access

Vantage creates system-level users during setup. User DBC owns all users, databases and objects and by default holds all database privileges. Teradata's guidance is clear: never alter DBC's privileges, because installation, upgrade, maintenance and archive procedures depend on them; use DBC to create administrative users, transfer space to them and grant their privileges; and keep the DBC password to the most trusted staff.

The security administrator

Teradata's documentation creates SECADMIN with a temporary password that expires at first logon and grants it:

The documented responsibilities of the role include choosing the authentication strategy, maintaining TDGSS configuration, managing users, roles, profiles and security constraints, logon permissions and password controls, optional IP address access restrictions, and access logging. The power to purge audit entries sits with the same role that sets logging rules, so add a compensating control: after logging on as SECADMIN, create a BEGIN LOGGING rule that records use of the logon rule and access logging macros, as the documentation suggests, and ship the log off the system before any purge. See the Privileged Access Management Guide for vaulting and session recording around these accounts.

Password and logon controls

System-wide password controls live in DBC.SysSecDefaults and are changed with UPDATE, for example UPDATE DBC.SysSecDefaults SET PasswordMinChar = 8.

Use profiles where a group needs different values, for example long random passwords and no interactive use for application accounts. Where the site still holds passwords stored under older hashing, the documentation describes converting existing non-FIPS-compliant passwords; plan that conversion as part of hardening.

Logon rules

GRANT LOGON ON { host_id | ALL } { AS DEFAULT | TO | FROM user } [WITH NULL PASSWORD] decides which logon sources each user may use. The system console is host ID 0; other connections use 1 to 32,767. A host-specific default overrides one set with ALL. By default every logon requires a password; WITH NULL PASSWORD admits password-less logons from a client community and is meant for users authenticated externally through a TDP security exit. Use logon rules to keep administrative users off general-purpose connections, and pair them with the optional IP address access restrictions the security administrator can configure. DBC cannot be named in GRANT LOGON, so protect it through its password and monitoring.

Integrations, API tokens and service accounts

ETL tools, BI servers, schedulers and data science notebooks connect to Vantage with database users. Treat each as a non-human identity with an owner, a purpose and a rotation date. The Service Account Security Guide covers the lifecycle.

• One user per integration: a dedicated database user per application, holding a role with only the object privileges it needs, never a member of the DBADMIN hierarchy.
• Profiles for service users: assign a service profile with its own password settings, and use logon rules so the user can log on only from the application's host IDs.
• Middle-tier trusted users: where a BI or web tier connects as a trusted user and sets a proxy user per end user, configure access logging so the proxy identity is recorded, as Teradata's access monitoring process recommends.
• Directory users for people, not pipelines: human analysts should come from LDAP or Kerberos; pipeline users stay in the database with vaulted credentials. See the Secrets Management Guide.
• Logon string protection: Vantage encrypts the logon string (username and password) by default; enable message data encryption or TLS so query results are also protected in transit.

Encryption and network protection

VantageCloud network settings

In VantageCloud Lake, the organisation administrator sets each environment's connection type under Settings, Network: an Internet connection on port 1025 to the environment's Teradata public IP, or a private link (the documentation describes PrivateLink for AWS and Private Link for Azure setup pages). Teradata notes you can set up one or the other, not both at the same time. Prefer private link for production so database traffic stays on your cloud provider's network, and restrict any Internet connection to known egress ranges at your own firewall.

Logging and detection

Teradata's access monitoring process: set up the DBC.AccLogRule macro, define rules with BEGIN LOGGING, check DBC.AccLogRuleTbl after each statement to confirm the rule, add directory user logging and proxy user logging where relevant, review logs, then purge periodically. The rule syntax is BEGIN LOGGING ON [frequency] [operation] BY user ON object, where frequency is FIRST, LAST, FIRST AND LAST or EACH. Omitting BY applies the rule to all users, including users created later. Matching requests write entries to DBC.AccLogTbl.

• Privileged users: log EACH use by DBC, SECADMIN and DBADMIN-derived users.
• Sensitive objects: log access to tables and views holding personal or regulated data, including objects under row-level security.
• Security macros: log execution of the logon rule and access logging macros so rule changes are visible.
• Query behaviour: Database Query Logging (BEGIN, REPLACE and END QUERY LOGGING, with tables created in DBC) complements access logging for workload and investigation detail.
• Gateway: network encryption auditing in the gateway log shows unencrypted client sessions.

Detection patterns and SIEM guidance are in the Database Audit Log Detection Guide.

Metrics to track: DBC logons per month; number of users with privileges granted directly rather than through roles; percentage of service users with a profile and host-restricted logon rule; percentage of sensitive objects under access logging; share of client sessions encrypted; and age of the oldest service account password.

Hardening baseline

The sequence below is NHI Mgmt Group guidance, not a vendor requirement; adjust it to your environment.

1. Inventory. List administrative users, all database users with their owners, roles and memberships, profiles, logon rules, current SysSecDefaults values and existing access logging rules.
2. Restructure administration. Create named administrator users and roles under DBADMIN and SECADMIN, vault the DBC password and stop routine DBC use.
3. Turn on logging first. Add BEGIN LOGGING rules for privileged users, security macros and sensitive objects, confirm each in DBC.AccLogRuleTbl, and forward entries to the SIEM before tightening access, so you can see what breaks.
4. Set password and logon controls. Update DBC.SysSecDefaults, create profiles for service and human groups, and apply GRANT LOGON rules per host ID. Test on a non-production system and keep a record of previous values to roll back.
5. Move people to the directory. Configure LDAP or Kerberos through TDGSS with TLS on the directory bind, map groups to roles and pilot with one team before cutting over.
6. Encrypt in transit. Enable message encryption or TLS for clients, use network encryption auditing to find remaining plain sessions, and turn on backup encryption.
7. Close the network. Use private link for VantageCloud environments and firewall port 1025 to known sources elsewhere.
8. Maintain. Apply Teradata software updates promptly, review roles, profiles and logon rules quarterly, and purge access logs only after they are archived.

Framework mapping

Common misconfigurations

• Everyday work as DBC. It removes individual accountability. Build named administrators and log every DBC session.
• Security and audit purge in one unmonitored role. Log SECADMIN activity and archive DBC.AccLogTbl before any purge.
• Direct grants everywhere. Privileges granted user by user drift over time. Move them into roles and keep direct grants to the documented non-roleable exceptions.
• WITH NULL PASSWORD on a broad host range. Use it only for client communities that are authenticated externally, and review the rule list quarterly.
• Logging rules never verified. A mistyped BEGIN LOGGING rule logs nothing. Check DBC.AccLogRuleTbl after each change and test with a known access.
• Shared service users. One login for several pipelines blocks rotation and investigation. Give each integration its own user and profile.

Practitioner checklist

• Vault the DBC password, limit it to the most trusted staff and log every DBC logon.
• Create SECADMIN and DBADMIN hierarchies with named administrators working under their own users.
• Grant privileges through roles and record each non-roleable direct grant.
• Set DBC.SysSecDefaults password controls and load PasswordRestrictions with organisation words.
• Assign profiles to service users and restrict their logons by host ID with GRANT LOGON.
• Authenticate people through LDAP or Kerberos with TLS on the directory bind.
• Enable message encryption or TLS for clients and use network encryption auditing to find plain sessions.
• Use private link for VantageCloud production environments.
• Create BEGIN LOGGING rules for privileged users, security macros and sensitive objects, and forward logs to the SIEM.
• Apply Teradata updates promptly and review roles, profiles and logon rules every quarter.

Standards and references

• Teradata: Security Administration
• Teradata: User DBC
• Teradata: Creating the Security Administrator User
• Teradata: Password Control
• Teradata: GRANT LOGON syntax
• Teradata: Access Monitoring Implementation Process
• Teradata: Cipher Suites and Overriding the Configuration File
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Database Security Guide · Service Account Security Guide · Privileged Access Management Guide · Data Security Guide