Moving from maximal LDAP and privileges to a minimal LDAP and a maximal use of roles - Eddy Coppens

When using LDAP in DB2 to check who had access to a database and which items are available to a user works fine even though when looking to db2diag.log you should wonder. The number of messages passing by in that file makes you aware how many checks are done while going thru the data in your database.

Editing the DB2 configuration file you can set backup LDAP servers should your primary become unavailable. The thought behind that is good but the implementation could be better! The moment when the first LDAP server has timed out and DB2 goes searching for the next in line you will experience a delay in getting a security go / no-go ... which is still fine should DB2 remember that the first LDAP server is not available anymore. For the next security check DB2 starts again interrogating the first server to find that is still not available, time out and switch to the next LDAP server. This behaviour is just not acceptable in any environment surely when performing maintenance on the LDAP server.

This behaviour made us look to another manner of implementing security within the database. It should be done in a way that the security model becomes easier to maintain - this time done at a maximum by the database administrators instead of going thru the SLA period of the system engineers - and less dependent on the LDAP.

We want users still to be created by the system engineers but want to remove the maintenance of the LDAP groups as we cannot assign a group to each type of database object, e.g. a group cannot be checked when using a view, a trigger ... and privileges should be assigned at a per user base. The combination of granting privileges to groups and users is yet a second reason to move away of this kind of implementation.

Even though the migration project is not yet completely worked out we would like to follow the path of:

- analyze all existing LDAP groups used within the database and find the users for each of these groups and catalog the type of access the groups stand for

- create a limited number of roles representing the different types of groups

- assign the users to their respective role

- grant the roles to the database objects

- grant access to the database to the roles

- remove the privileges of the LDAP groups

By doing so, LDAP should be contacted only once while trying to gain access to the database - maybe with some timeouts should LDAP servers not answer within an appropiate time. Once granted access all security checks on the database objects is handled by roles. As a plus the database is ready for any kind of security implementation as there is RCAC (row and column access control).

Eddy Coppens - Infocura

Recent Stories
Db2 for z/OS locking basics

A Beginners Guide to Locks, Latches, Claims and Drains in DB2 for z/OS by Steve Thomas

Fun with Date Ranges