Setting up and Using the Security Logon Function - Teradata Director Program

Teradata® Director Program Reference - 17.20

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Teradata Director Program
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2023-11-17
dita:mapPath
cki1641301536147.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
frc1470439950465
Product Category
Teradata Tools and Utilities
Use the following procedure as a guideline for setting up and using the security logon function:
  1. Submit the following Teradata SQL statement to the database to grant logon access with a null password:

    GRANT LOGON ON ALL AS DEFAULT

    WITH NULL PASSWORD;

    This command must be submitted either by the database system administrator, or by another user with EXECUTE access to DBC.LogonRule.

    Note also that:
    • The null password privilege only applies to logon requests originating on mainframe client systems. Requests from network-connected workstation always require a password.
    • Any attempt to log on to the database with user name DBC always requires a password. TDP does not use the validated logon feature for user name DBC.
    • The AS DEFAULT provision can be overridden by more restrictive GRANT clauses for individual users.
  2. If the User Logon Exit interface (TDPLGUX) has been customized, review the interaction guidelines in Using Security Logon With TDPLGUX to determine whether additional changes are required.

    If TDPLGUX has not been customized, its enabled/disabled status has no effect on security logon operations.

  3. Set up your external security manager to work with the TDP security logon function.

    For RACF:

    1. Create user profiles in the FACILITY class with a universal access code of NONE to regulate logons.
      Note, in the following example, that the first qualifier of the resource name specifies the TDPid, and the second qualifier specifies the DBC user logon name:
      RDEFINE FACILITY TDP9.TEST01 UACC(NONE)
      RDEFINE FACILITY TDP0.BIG_DBC_USER_NAME    - UACC(NONE)
      RDEFINE FACILITY TDPX.PAYROLL977263 -   UACC(NONE)
    2. Give each user the appropriate status authority to the FACILITY profile. READ is sufficient, as in the following examples:
      PERMIT UACC(READ) USER(TSO0997) -   PROFILE(TDP9.TEST01) CLASS(FACILITY)
      PERMIT UACC(READ) USER(TSO0998) -   
         PROFILE(TDP0.DBC_BIG_USER_NAME) -
         CLASS(FACILITY)
      PERMIT UACC(READ) USER(TSO0999) -   PROFILE(TDPX.PAYROLL977263) 
      -    CLASS(FACILITY)
    3. If not already activated, activate the FACILITY class:
      SETROPTS CLASSACT(FACILITY)

    For ACF2:

    Set up resource rules of TYPE(FAC) to regulate logon requests and grant access to each user. Note, in the following example, that the key represents the TDPid and the extension represents the DBC user logon name:

    SET RESOURCE(FAC)
    COMPILE *
     $KEY(TDP9) TYPE(FAC)
    TEST01 UID(TS0997) ALLOW
    STORE
    COMPILE *
     $KEY(TDPX) TYPE(FAC)
    STPRE
    COMPILE *
     $KEY(TDPX) TYPE(FAC)
       PAYROLL977263 UID(TSO999) ALLOW
    STORE

    For all other external security managers, refer to the appropriate vendor documentation.

  4. Always test new resource profiles or access rules before placing them in a production environment.

    Since the FACILITY class is limited to 39 bytes, it will not suffice if RDBMS user names exceed 30 bytes. This will be the case only if character sets are being used that support more than one byte per character. If this is the case, it is necessary to create an entirely new class with a maximum length of 92 bytes (the maximum number of bytes for an RDBMS user id in any currently supported character set).

    This is a complicated process - especially under RACF, where an IPL is required -and should be performed only by an experienced systems programmer.

    Refer to the appropriate vendor documentation for details, and when the security logon function is enabled, specify the name of your new alternate class as follows:

    ENABLE SECLOGON MSGS CLASS DBCLOGON

    This forces TDP to use a class name of DBCLOGON instead of FACILITY for RACROUTE authorization calls.

    Under RACF, class names can be between 4 and 8 characters in length. Under ACF2, class names are called resource names and are generally 3 characters in length. (ACF2 internally translates FACILITY to FAC, and vice versa.)
  5. Enable the security logon function with the desired messages option:

    ENABLE SECLOGON MSGS

    or:

    ENABLE SECLOGON NOMSGS

See Customer Exits and Database Userid Authentication for more information about the TDP commands that pertain to the security logon function:
  • ENABLE SECLOGON
  • DISABLE SECLOGON
  • MODIFY SECLOGON