Best practices for security in IBM Db2 Data Management Console

By Yuan Feng posted 26 days ago

  

The principle of security in IBM Db2 Data Management Console (DMC) is to integrate with the existing security architecture in the company.

 

First, let’s take a look at how to set up a repository connection using Kerberos Ticket-Granting Ticket to connect to the repository.

Step 1: Config Kerberos realm in the /etc/krb5.conf on the DMC installed server, user can just change the lines that need user input. Basically, the user needs to configure the default-realm, the realm mapping to which domains, and the realm point to which target Kerberos key distribution center server.

# To opt out of the system crypto-policies configuration of krb5, remove the

# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.

includedir /etc/krb5.conf.d/

 

[logging]

    default = FILE:/var/log/krb5libs.log

    kdc = FILE:/var/log/krb5kdc.log

    admin_server = FILE:/var/log/kadmind.log

 

[libdefaults]

    dns_lookup_realm = false

    ticket_lifetime = 24h

    renew_lifetime = 7d

    forwardable = true

    rdns = false

    pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt

    spake_preauth_groups = edwards25519

    #default_realm = <put your Kerberos realm>

    default_ccache_name = KEYRING:persistent:%{uid}

 

[realms]

 <your realm> = {

 #   kdc = <put your target kdc server>

 #   admin_server = kerberos.example.com

 }

 

[domain_realm]

 .<your domain suffix> = <your realm>

 <your domain> = <your realm>


Step2: Generate ticket and cache in DMC. Since DMC uses embedded IBM java, the user needs to go to the <DMC install folder>/java/jre/bin/ to generate the ticket.

./java com.ibm.security.krb5.internal.tools.Kinit -A -f -p <Kerberos user used to generate the ticket>
<password of Kerberos user>

When using the ticket-granting ticket, the password is just used once to encrypt the data, but it is not stored in the ticket file. And for any further authentication, the password is not used anymore. However, remember to renew the ticket before the ticket has expired. Users can reference the Kerberos server-side krb5.conf for the ticket_lifetime, default lifetime is 24h. If the monitor database and repository database all use the same Kerberos distribution center, the user can create a function id used both for repository database connection and the data collection credential for monitor databases. Then cache the ticket generated by the function id on the DMC server, with this approach user just need to maintain one ticket in the DMC server for all the databases.

Second, let’s deep dive into how to integrate DMC authentication and authorization with the user’s existing security architecture. After DMC 3.1.5, DMC supports three roles: “Database User”, “Database Administrator”, “Console Administrator”.  The user should also set up the relative mapping for authorization.

 

DMC supports three kinds of authentication mechanisms:
  1. Set up admin user during DMC install. This mechanism supports only one user. After another authentication mechanism is set up, the default set up admin user will be removed.

 2. LDAP authentication. DMC supports LDAPS, StartTLS, and Plain SSL methods.

User can store their certification file in a trust store, please reference this document for more details.
Here’s an example:

Then config your user DN and relative Group DN. DMC v3.1.5 supports three roles, each role can be configured to mapping to multiple LDAP groups' DN. Users can click the add button to add multiple LDAP groups. The “Member attributes type” is mapped to the attribute of the group which is used to store information of group members. The “User ID attribute type” is mapped to the attribute of user entries which value is stored in the group as group member information. If full DN values of user entries are stored in the group as group members, please set this value to be 'dn'.  Usually, this value is defined by the schema of the group member attribute.  

The setting can only be saved after the test is successful because once it is set up the default admin user will be removed.

 

 3. Repository authentication. If you trust the repository authentication, you can also delegate authentication to the repository. If your repository is using LDAP, it is also transparent to LDAP authenticate. DMC supports four ways to map the authorization.
  • Db2 Authorities. Users can have special Db2 built-in authorities, for example, map Console Admin to SYSADM or SYSCTRL. It supports multiple authorities for one role, just separate them with a vertical line. 
  • Db2 Groups. This relies on the db2 security configuration. If the repository DB group is delegated to LDAP groups, it can also be transparent to LDAP groups.
    It also supports multiple groups for one role, just separate them with a vertical line.
  • Db2 UDF. Users can map any UDF to different roles, but it just supports one UDF for each role, anyone who gives the relative execution privilege for this UDF will have the relative authorities in DMC.DMC will build in 3 UDF users can direct use:
    IBMCONSOLE.CANADMINISTER
    IBMCONSOLE.CANDBA
    IBMCONSOLE.CANVIEW
    
  • Db2 Roles. Users can define roles in repository DB and map those roles to DMC roles. Users can map multiple roles to one DMC role, again just need to separate them with a vertical line.

Once the user has set up the repository authorization mapping, the user has to test one user (suggest testing the user belonging to Console Administrator role), once the test is successful the setting can be saved and will take effect.




0 comments
495 views

Permalink