DB2_sys-auth installation guide
- Installation example
- Upgrade example
- Compiling from source
- Known issues
- To Do
- Contacting us
This document describes how to install the DB2 system authentication module for PAM/LAM database authentication.
This DB2 authentication module requires UDB version 8.2 or later, or UDB version 9.1 or later.
In this example, DB2 has been installed on AIX 5.1 and the instance owner name is db2inst1. The DB2_sys-auth package has been downloaded into /tmp, and you want to install it so it authenticates using AIX's LAM (not PAM).
# cd /tmp # gzip -d < DB2_AIX_51-52.tar.gz | tar fxv - # cd DB2_sys-auth # ./install.sh db2inst1 LAM
The install script copies the files,
and sets the setuid bit on the lamAuth64
helper application so that local user authentication may work.
LAM argument should be omitted for PAM installations.
LAM is only available on the AIX platform.
Once installed, the next step is to configure the database instance to use the plugin:
# su - db2inst1 $ db2stop $ db2 update dbm cfg using SRVCON_PW_PLUGIN sys-auth $ db2 update dbm cfg using GROUP_PLUGIN sys-auth $ db2 update dbm cfg using CLNT_PW_PLUGIN sys-auth $ db2start
If you are on AIX, and configuring for PAM, be aware that AIX 5.1 and 5.2 do not come with /etc/pam.conf by default. You can install the sample aix.pam.conf is in this package.
If you are running a 64-bit DB2 instance, you cannot use PAM authentication because AIX's pam_aix module is 32-bit only.
When upgrading, unpack the distribution and run the upgrade script.
# cd /tmp # gzip -d < DB2_AIX_51-52.tar.gz | tar fxv - # cd DB2_sys-auth # ./upgrade.sh db2inst1 LAM
LAM argument is optional and should match what was
specified during installation.
Before uninstalling, you may need to run
Compiling from source
If the provided binary packages are not suitable for your platform, you can compile the authentication plugin directly.
- The gcc compiler
- The 'make' program
- The Quest Authentication Services SDK (vasdev) package
- pam_aix (only if wanting to use PAM authentication AIX 5.1)
(Previously, the DB2 application development client package was required, but this is no longer necessary.)
Download and unpack the source package. Change into the unpacked directory, and build with these commands:
$ ./configure $ make
Read the file named TESTING to ensure the module is working.
Finally, run the install.sh script as described previously.
- Though the dbm cfg was changed from sys-auth32 to sys-auth to reflect the name change, and the instance was restarted, one system failed to authenticate users saying it could not find sys-auth32. This was a partitioned instance, and might have been a lack of replication between the instances. The issue was resolved by changing the dbm cfg entries to another name, and then back to sys-auth.
- The plugin doesn't resolve gid, due to security reasons. Most default installs will not make for example db2inst1 a member of db2grp1, instead setting the users gid to the group. You will need to make the user a member of the group explicitly. This is not an issue on AIX as the getgrset command returns the pgid, and it is processed. Due to the layer of authenticaiton used by the program, if the user isn't allowed access because of group membership, then LAM/PAM will deny the attempt.
- If the authentication program (pamAuth32, pamAuth64, lamAuth32 or lamAuth64) is not made setuid root, then some authentication mechanisms will be unavailable because they expect to run privileged. For example, Quest Authentication Services' PAM module does not required privileged operation, but authentication of local accounts using shadow password files does.
- AIX 5.2's PAM module is 32-bit. If your instance is 64-bit, you
will need to either use LAM, or add this line to /etc/pam.conf:
sys-auth64 auth sufficient /opt/vas/lib/security/pam_vas64.so get_tgt create_homedir
- The HP and linux packages only have 32-bit libraries.
- Does not use a GSSAPI interface; DB2 assumes authentication is always by username-password pair.
- Does not handle required password changes or expired password. Either everything must be fine with the username/password, or authentication fails.
- AIX 5.1/5.2 PAM modules are 32-bit only; LAM needs to be used for 64-bit instances.
- Since DB2 converts the username to uppercase before calling the plugin's DoesAuthIDExist interface, and most unix users are all lowercase, this plugin re-converts the name to all lowercase before testing for existence. This might cause problems on case-sensitive systems, e.g. HP-UX running in trusted mode. With Active Directory, Quest Authentication Services can usually validate an Active Directory username regardless of case. For local account usernames with uppercase letters, authentication will fail.
- There is no host-based access control. Access control is only by group memberships, and whether a username/password combination is valid. If the AD user is unix-disabled (i.e is given an invalid shell, but the account still has unix attributes) or is listed in users.deny, they will still be able to access DB2. Disabling the AD user explicitly in Active Directory, or implicitly from failed password attempts, logon hours, and the like will stop the user from accessing DB2. Anything that would make Windows complain 'revoked client credentials' will also deny the user (e.g. locked account, bad passwords), but settings that affect shell (users.deny, unix-disabled) will not be enforced.
- The libraries must be copied to each instance directory. Due to how DB2 loads the shared libraries, symlinks to a common library file are apparently not sufficient.
These will be done as time allows. If needed for customers, much sooner.
- Re-write the install instructions and readme for clarity.
- Remove ignoring PGID membership on non-AIX platforms.
- Provide an uninstall script/instructions.
Please use the web forums to ask questions about the authentication plugin, or contact Quest support for urgent issues.
— Seth Ellsworth