User Mapping

A user mapping is an association between a database user or a database role and a local user on the CipherTrust Manager. CDP uses this user mapping to authenticate with the CipherTrust Manager before submitting cryptographic requests.

When a database user sends a request to the CipherTrust Manager, CDP searches its list of user mappings (contained in the ING_AUTHORIZED_USER table in the metadata database). If the database user appears on the list, is a member of a mapped group, or has a mapped server role, CDP includes the associated CipherTrust Manager user and password in the request. If those credentials are valid and the CipherTrust Manager user has access to the required key, then the CipherTrust Manager performs the operation. If the credentials are not valid or the CipherTrust Manager user does not have access to the key, the operation fails.

If a database user, who is a member of a database role mapped to an NAE user, is also mapped individually to an NAE user, the individual user mapping takes precedence.

If a database user belongs to multiple database roles, which are mapped to NAE users, the user inherits the access privileges of the NAE user mapped to the role that appears first when sorted alphabetically. Some features may need to be enabled for all database users and database roles not otherwise listed on the User Mappings section. To do this, the Default Mapping value should be associated with a specific CipherTrust Manager user. For example, a CipherTrust Manager user with access to global keys can be created, or a CipherTrust Manager user with access to no specific permissions can be created to enable the replacement value feature.

You can create and manage user mapping using any of these options:

• CipherTrust Manager UI. Refer to Managing User Mappings for details.

• pdbctl utility. Refer to the pdbctl utility documentation for details.

Default Mapping

The default mapping is a catch-all CipherTrust Manager user used to connect to the CipherTrust Manager when no user mapping exists for a database user. When there is no default mapping and an unmapped database user attempts to access sensitive data, CDP returns an error message and does not send the request to the CipherTrust Manager. It may be useful to create a default mapping to prevent CDP from automatically returning this error.

When this feature is enabled, instead of returning an error message, CDP connects to the CipherTrust Manager as the default CipherTrust Manager user. How the CipherTrust Manager then responds to requests depends on your CipherTrust Manager configuration. The CipherTrust Manager might return an “insufficient permissions” error, it might return NULL, or it might return a pre–configured replacement value.

When the default mapping is assigned, the system creates an entry in the ING_AUTHORIZED_USER table with the user name, ING_DEFAULT_USER. For this reason, you should avoid using ING_DEFAULT_USER to represent a specific database user.

Group or Role Mapping

CDP enables an authorized database user’s access to encryption keys. A database user or a database role can be directly mapped to a CipherTrust Manager user. An AD user can also be mapped to a CipherTrust Manager user.

The next two topics describe steps to map a database role and an AD user to an NAE user. To understand the instructions given below, following are required:

• An encrypted table TestTable.

• Two database users (User01 and User02) having privileges on TestTable.

• Two Windows AD users (sfnt\ADUser01 and sfnt\ADUser02) having access permissions on TestTable. For information on adding Windows users to Oracle database, see

A database role, DBRole (consisting of User01, User02, and sfnt\ADUser01), having privileges on TestTable.

Map a Database Role to an NAE User

1. Log on to the CipherTrust Manager GUI.

2. Click Database Protection to open the application. The Databases screen displays the list of existing database connections, if any.

3. Open the connection for which you want to view the user mapping.

4. Click the User Mapping link.

5. Click + Add User.

   After the database role is mapped, the database users, User01 and User02, and the AD user, sfnt\ADUser01 (mapped to the role), can execute the select queries on the CipherTrust Manager.

6. Verify the settings.

   a. Log on to Oracle as User01, User02, or sfnt\ADUser01.

   b. Execute a select query.

Add Windows AD Users to Oracle

1. Make sure that the SQLNET.AUTHENTICATION_SERVICES parameter in the sqlnet.ora file contains nts. The sqlnet.ora file is stored at ORACLE_HOME\network\admin.

2. Make sure that the following SQL parameters are set as follows:

   • os_authent_prefix = "OPS$" or ""

   • remote_os_authent = FALSE

   • remote_login_passwordfile = NONE

   To check the above parameters, execute the following query as sysdba:

       Show parameters <parameter-name>
   

   To change the value of these parameters, execute the following queries as sysdba:

   • alter system set OS_AUTHENT_PREFIX = 'OPS$' SCOPE=SPFILE;

   • alter system set remote_login_passwordfile=NONE scope=spfile;

   • alter system remote_os_authent=FALSE scope=spfile;

3. Add the Windows AD user to Oracle users. This can be done by using the Oracle Administration Assistant utility for Windows or manually.

   a. Connect to the database as the SYSTEM Database Administrator (DBA). Execute the following query:

   sqlplus sys as sysdba
   

   b. Create an external user. Execute the following query:

   CREATE USER "XYZHELIUM\USER1" IDENTIFIED EXTERNALLY
   

   Here, XYZ represents the name specified in the initialization parameter, OS_AUTHENT_PREFIX; HELIUM represents the domain name; and USER1 represents the domain user. For example, if the domain is helium.in and the user is user1, then the user created will be HELIUM\USER1. If the prefix is OPS$, then the created user will be OPS$HELIUM\USER1. If no value is provided, then the default prefix is OPS$.

   Double-quotes (" ") are required here, and the entire syntax must be in UPPERCASE.

   c. Grant database roles to the external user. Execute the following statements

   GRANT RESOURCE TO XYZHELIUM\USER1; GRANT CONNECT TO XYZHELIUM\USER1;
   

4. Restart the database. Execute the following statements:

   Shutdown
   Startup
   

5. Log on to Oracle as a domain user. Execute the following query:

   Connect/
   

   This query is used to log on to Oracle as a domain user without supplying password. To verify, execute the following query:

   Select * from USER_USERS;
   

   This query displays all current domain users.