Please Note:

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.

Note

Although the default mapping can be used for both encryption and decryption operations, Thales strongly recommends that it has no key or group permissions. The point of creating a default mapping is to gracefully handle requests for encrypted data from database users who are not authorized to view that data. If the default mapping has key or group permissions, you are potentially allowing unauthorized database users to view sensitive data.

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.

Note

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, then the individual user mapping takes precedence.
If a database user belongs to multiple database roles, which are mapped to NAE users, then the user inherits the access privileges of the NAE user mapped to the role that appears first when sorted alphabetically.
The mapping priority takes precedence in the following order: individual > database role > Default Mapping.

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

Log on to the CipherTrust Manager GUI.
Click Database Protection to open the application. The Databases screen displays the list of existing database connections, if any.
Open the connection for which you want to view the user mapping.
Click the User Mapping link.
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.
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

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.
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 &lt;parameter-name&gt;
```
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;
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;
```
Restart the database. Execute the following statements:
```
Shutdown
Startup
```
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.