Security plug-in support for two-part user IDs
The Db2® database manager on Windows supports the use of two-part user IDs, and the mapping of two-part user IDs to two-part authorization IDs.
For example, consider a Windows operating system
two-part user ID composed of a domain and user ID such as: MEDWAY\pieter
. In this
example, MEDWAY
is a domain and pieter
is the user name. In
Db2 database
systems, you can specify whether this two-part user ID should be mapped to either a one-part
authorization ID or a two-part authorization ID.
The mapping of a two-part user ID to a two-part authorization ID is supported, but is not the default behavior. By default, both one-part user IDs and two-part user IDs map to one-part authorization IDs. The mapping of a two-part user ID to a two-part authorization ID is supported, but is not the default behavior.
db2 connect to db user MEDWAY\pieter using pw
In
this situation, if the default behavior is used, the user ID MEDWAY\pieter
is
resolved to the authorization ID PIETER
. If the support
for mapping a two-part user ID to a two-part authorization ID is enabled,
the authorization ID would be MEDWAY\PIETER
.- One set exclusively maps a one-part user ID to a one-part authorization ID and maps a two-part user-ID to a one-part authorization ID.
- Another set maps both one-part user ID or two-part user ID to a two-part authorization ID.
If a user name in your work environment can be mapped to multiple accounts defined in different locations (such as local account, domain account, and trusted domain accounts), you can specify the plug-ins that enable two-part authorization ID mapping.
It is important to note that a one-part authorization ID, such
as, PIETER
and a two-part authorization ID that
combines a domain and a user ID like MEDWAY\pieter
are
functionally distinct authorization IDs. The set of privileges associated
with one of these authorization IDs can be completely distinct from
the set of privileges associated with the other authorization ID.
Care should be taken when working with one-part and two-part authorization
IDs.
Authentication type | Name of one-part user ID plug-in | Name of two-part user ID plug-in |
---|---|---|
User ID/password (client) | IBMOSauthclient | IBMOSauthclientTwoPart |
User ID/password (server) | IBMOSauthserver | IBMOSauthserverTwoPart |
Kerberos | IBMkrb5 | IBMkrb5TwoPart |
When you specify an authentication type that requires a user ID/password or Kerberos plug-in, the plug-ins that are listed in the "Name of one-part user ID plug-in" column in the previous table are used by default.
To map a two-part user ID to a two-part authorization ID, you must specify that the two-part plug-in, which is not the default plug-in, be used. Security plug-ins are specified at the instance level by setting the security related database manager configuration parameters as follows:
srvcon_pw_plugin
toIBMOSauthserverTwoPart
clnt_pw_plugin
toIBMOSauthclientTwoPart
srvcon_pw_plugin
toIBMOSauthserverTwoPart
clnt_pw_plugin
toIBMOSauthclientTwoPart
srvcon_gssplugin_list
toIBMOSkrb5TwoPart
clnt_krb_plugin
toIBMkrb5TwoPart
The security plug-in libraries accept two-part user IDs specified in a Microsoft Windows Security Account Manager compatible format. For example, in the format: domain\user ID. Both the domain and user ID information will be used by the Db2 authentication and authorization processes at connection time.
You should consider implementing the two-part plug-ins when creating new databases to avoid conflicts with one-part authorization IDs in existing databases. New databases that use two-part authorization IDs must be created in a separate instance from databases that use single-part authorization IDs.