The Symbol matcher uses global variables to identify a match. A global variable has a name and a value. Global variables are case sensitive and have an assigned value for the database session. The database management system provides most of the values and there might be discrepancies between database versions of the same type.

For example, the Symbol matcher can identify a connection initiated by the database administration team. To identify team members that are not Dynamic Data Masking administrators and set a matching action that blocks access to the requested data, use the global variable AUTH_USERNAME. When the Rule Engine encounters the symbol, it blocks access to the data.

You can reference a global variable by placing the global variable in parentheses preceded with a backslash. For example, \(AUTH_USERNAME) is replaced with the database username.

The availability of a global variable is dependent on the database type. To identify global variable values, use the Client Info entry in the

rule.log

file.

You can use the following global variables:

AUTH_CURRENT_DATABASE

Defines the current database.

You can use AUTH_CURRENT_DATABASE on Sybase, IBM Db2, Informix (DRDA), Teradata, Data Vault, Microsoft SQL Server, and Hive. For Hive, AUTH_CURRENT_DATABASE contains a value only when you provide a database name in the connection URL and Hive protocol is binary.

AUTH_DATABASE_IP

The IP address of the database that the client is connected to.

You can use AUTH_DATABASE_IP on Oracle, Sybase, Microsoft SQL Server, IBM Db2, Informix, Teradata, Data Vault, and Hive databases.

AUTH_DATABASE_NAME

Defines the Dynamic Data Masking database name that you define in the Management Console.

You can use AUTH_DATABASE_NAME on Oracle, IBM Db2, Sybase, Informix, Data Vault, Teradata, Hive, and Microsoft SQL Server.

AUTH_DATABASE_PORT

The database port that the client is connected to.

You can use AUTH_DATABASE_PORT on Oracle, IBM Db2, Sybase, Informix, Microsoft SQL Server, Data Vault, Hive, and Teradata.

AUTH_DRIVER_CLASS

The driver class name that the Generic JDBC client instruments at runtime.

You can use AUTH_DRIVER_CLASS with the DDM for JDBC service.

AUTH_DRIVER_NAME

The JDBC driver name.

You can use AUTH_DRIVER_NAME with the DDM for JDBC service.

AUTH_EXTERNAL_AUTHENTICATION

Defines whether the user is connected to the database with a password. If the user is connected to the database with a password, the value is FALSE. If the user is connected to the database without a password, the value is TRUE.

You can use AUTH_EXTERNAL_AUTHENTICATION on Informix.

AUTH_ORIG_STATEMENT

The statement that is sent by the client. The symbol is updated each time the client sends a statement.

You can use AUTH_ORIG_STATEMENT on Oracle, IBM Db2, Sybase, Informix, Microsoft SQL Server, Data Vault, Hive, and Teradata.

AUTH_MACHINE

Defines the client host name and is not dependent on the client.

You can use AUTH_MACHINE on Oracle, Sybase, IBM Db2, Informix, Data Vault, and Microsoft SQL Server.

AUTH_PROGRAM_NM

Defines the program name.

You can use AUTH_PROGRAM_NM on Oracle, IBM Db2, Sybase, Microsoft SQL Server, and Teradata.

AUTH_SERIAL_NUM

Defines the session serial number.

You can use AUTH_SERIAL_NUM on Oracle.

AUTH_SESSION_ID

Defines the session ID configured for Dynamic Data Masking.

You can use AUTH_SESSION_ID on Oracle, Microsoft SQL Server, Hive, and Teradata.

AUTH_SID

Defines the client user name.

You can use AUTH_SID on Oracle, Teradata, Data Vault, and Microsoft SQL Server (when you log in using Windows authentication).

AUTH_STATEMENT_RECEIVED_TIME

Date and time Dynamic Data Masking received a statement. The date format is dd MMMM yyyy HH:mm:ss and is not customizable. AUTH_STATEMENT_RECEIVED_TIME is populated immediately after parsing of the protocol and before rule set processing.

You can use AUTH_STATEMENT_RECEIVED_TIME on Oracle, IBM Db2, Sybase, Informix, Microsoft SQL Server, Data Vault, Hive, and Teradata.

AUTH_TERMINAL

Defines the client host name and is dependent on the client. For example, if you use SQL Developer to connect to an Oracle database, AUTH_MACHINE contains the client host name, but AUTH_TERMINAL does not contain the client host name.

You can use AUTH_TERMINAL on Oracle.

AUTH_USERNAME

Defines the database user name.

You can use AUTH_USERNAME on Oracle, IBM Db2, Sybase, Informix, Microsoft SQL Server, Data Vault, Kerberos Hive, and Teradata.

CLIENT_IP

Defines the IP address of the client machine.

You can use CLIENT_IP on Oracle, Sybase, Microsoft SQL Server, IBM Db2, Informix, Teradata, Data Vault, and Hive databases.

CLIENT_PORT

Internal port of the client machine that connects to Dynamic Data Masking.

You can use CLIENT_PORT on Oracle, Sybase, Microsoft SQL Server, IBM Db2, Informix, Teradata, Data Vault, and Hive databases.

DDM_HOST

The host name of the machine where the Dynamic Data Masking Server runs.

You can use DDM_HOST on Oracle, Sybase, Microsoft SQL Server, IBM Db2, Informix, Teradata, Data Vault, and Hive databases.

DDM_IP

The IP address of the machine where the Dynamic Data Masking Server runs.

You can use DDM_IP on Oracle, Sybase, Microsoft SQL Server, IBM Db2, Informix, Teradata, Data Vault, and Hive databases.

DDM_PORT

The internal port of the Dynamic Data Masking machine that connects to the database.

You can use DDM_PORT on Oracle, Sybase, Microsoft SQL Server, IBM Db2, Informix, Teradata, Data Vault, and Hive databases.

DDM_VERSION

The version of the Dynamic Data Masking Server.

You can use DDM_VERSION on Oracle, IBM Db2, Sybase, Informix, Microsoft SQL Server, Data Vault, Hive, and Teradata.