This topic describes the database permissions on provisioned Db2 virtual instances
Authentication is the process of validating a supplied user ID and password using a security mechanism. User and group authentication is managed in a facility external to Db2 LUW, such as the operating system, a domain controller, or a Kerberos security system. This is different from other database management systems (DBMSs), such as Oracle and SQL Server, where user accounts may be defined and authenticated in the database itself, as well as in an external facility such as the operating system.
Any time a user ID and password is explicitly provided to Db2 LUW as part of an instance attachment or database connection request, Db2 attempts to authenticate that user ID and password using this external security facility. If no user ID or password is provided with the request, Db2 implicitly uses the user ID and password that were used to login to the workstation where the request originated. More information on Db2 authentication and authorization is available via IBM documentation
Delphix Db2 Authentication Delphix for Db2 requires that the staging and target hosts must already have the necessary users and authentication systems created/installed on them. Delphix will neither create users nor change database passwords as part of the provisioning process.
While the terminology used within the Delphix Management application refers to a VDB, the ingestion, snapshot and provisioning process for Db2 on Delphix always occurs on the Database level. Thus when a virtual Db2 database is provisioned by Delphix, it contains the Db2 database that were in the source instance with the identical user permissions as they had on the source. This means that if the target instance name is different from the source instance name then that instance owner will NOT have DBADM or SECADM permissions unless they were specifically granted to that instance owner on the source instance. The instance owner will however always have SYSADM permissions on all databases in the instance.
If your Db2 instances and applications use LDAP authentication then they will work seamlessly as long as LDAP had been configured on the VDB Target Instance.
If your DB2 instances and applications are using OS authentication then it is important to ensure that the relevant OS accounts exist on the target machine.
If the Db2 applications are using generic (non-instance owner) accounts, they will then be able to continue using them as long as those OS accounts exist on the host machine. It is important to note that the passwords for the same account may be different on different hosts, or if they use different LDAP servers (i.e. prod vs dev LDAP servers).
Instance owner usage
If the Db2 applications typically use the instance owner accounts to access data then it is important to note that if the new instance name is different from the source instance name then that instance owner will NOT have DBADM or SECADM permissions in the VDB instance and may not be able to read and write data. In such a case there are three possible workarounds:
Connect to the databases as the source instance owner. This requires that the target host has a UNIX account with the same name as the source instance.
Grant the necessary permissions to the VDB instance owner on the source instance before taking the snapshot that is to be provisioned.
Grant the permissions to a known "delphix" user on the source instance and then use that account to grant the permissions to the target VDB instance after provisioning.