We are currently using Db2, SLES11, RACF/LDAP (zOS). Application users (personalized users, not system users) connecting to Db2 are defined in RACF/LDAP.
Db2 user authentication and authorization is using Transparent LDAP, accessing RACF/LDAP. The usernames in RACF/LDAP are defined using uppercase letters, e.g. S123456 (zOS). DB2 privileges like "connect, select, update ..." are granted to LDAP groups, but not the primary group of a user. (System users like Db2 instance users and administration users (performing loads into DB2) are managed locally on Liunux by /etc/passwd.)
This architecture worked well using SLES11, after Linux migration to SLES12 it did not work anymore. The reason is on the one hand SLES12 is not case insensitive regarding usernames anymore, SLES11 was case insensitive (the changed behavior is treated as a correction by SuSE). On the other hand it was found out Db2 is converting usernames always to lowercase, e.g. Db2 converts username [S123456] to [s123456] for groupset enumeration.
Thus, if Db2 establishes a connection using conversion "lower(username)" the secondary groups of username are not returned by LDAP, leading to missing permissions. User/password authenticatoin is working this way, but not evaluating the secondary groups. If Db2 would provide a way (e.g. Db2 registry variable) to switch off the conversion of the username, RACF/LDAP would return the complete user group-list. See Db2 case TS002722481 (and Linux case TS002758643, TS002764890).
|Who would benefit from this IDEA?||First the customer would benefit from it and furthermore every customer who requires the possibility to use LDAP usernames containing uppercase letters.|
How should it work?
1) Do you have proposed solution for this problem?
2) What would the measurable benefits of the solution be?
A measurable benefit would be on the one hand the possibility for Db2 to work with not-only lowercase LDAP usernames. Furthermore it would increase Db2s security since incorrect usernames (regarding upper-/lowercase) will no longer be authenticated.
3) What are you doing today to work around the problem? (or what else did you try?) ]
At the moment there is no working solution. Customers migration to SLES12 is on-hold. Alternatives on SLES12 and RACF/LDAP (zOS) level are evaluated.
|Client Name||Finanz Informatik GmbH & Co KG|
|IBM's success depends on gathering feedback from customers like yourself. Aha Ideas Portal is the third party tool through which IBM Offering Managers gather feedback from customers such as yourself.|
|IBM is a global organization with business processes, management structures, technical systems and service provider networks that cross borders. As such, the information collected through Aha Ideas Portal (Customer Name, Customer Email Address) will be stored by them in the United States, and handled only as per IBM's instructions and policies. Your data (Name and Email Address) will NOT be shared with other IBM customers.|
|In order to safeguard your information in Aha, do not leave your workstation unattended while using this application, log off after using it, and print only if necessary. If you need to make a hardcopy, remember to pick up the print-out immediately, keep it under lock, and destroy it immediately when no longer needed.|
|NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "email@example.com" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions|