Use sp_maplogin to map users that are authenticated with LDAP or PAM to the local Adaptive Server login.
To map a user authenticated with Kerberos, use sybmapname instead
of sp_maplogin.
Only users with sso_role can create or modify login mappings using sp_maplogin.
Adaptive Server avoids conflicts between an authentication mechanism setting for a login and a mapping that uses the login. Potential mapping conflicts are detected by the stored procedure sp_maplogin or the commands alter login, or create login.
These controls do not allow maps:
From one Adaptive Server login name to another login name
From an external name that already exists as a local login
To a nonexistent login name
Additionally, when the authentication mechanism is specified with a mapping, the mechanism is checked with the authentication mechanism set in the target login.
If a target login’s authentication mechanism restricts the login to use a particular authentication mechanism, then the mechanism specified with the mapping must match either that specified for the login or match the “ANY” authentication mechanism.
When sp_maplogin detects that a conflict exists, sp_maplogin fails and reports an error that identifies the conflict.
Similarly, alter login and create login check for an existing mapping that may conflict with the authenticate with option for the user login. When alter login or create login detect a conflict, an error is reported to identify any conflicts with a login mapping.
Example 1 Maps an LDAP user to the Adaptive Server “sa” login. A company has adopted LDAP as their repository for all user accounts and has a security policy that requires LDAP authentication of all users including database administrators, “adminA” and “adminB,” who may manage hundreds of Adaptive Servers. Auditing is enabled, and login events are recorded in the audit trail.
To map these administrator accounts to “sa,” enter:
sp_maplogin LDAP, 'adminA', 'sa' go sp_maplogin LDAP, 'adminB', 'sa' go
Require all users to authenticate using LDAP authentication:
sp_configure 'enable ldap user auth', 2 go
When “adminA” authenticates during login to Adaptive Server, the distinguished name associated with “adminA” rather than only “sa” is recorded in the login audit event. This allows each individual performing an action to be identified in the audit trail.
Because the “adminA” and “adminB” password is set in the LDAP server, there is no need to maintain the “sa” password on all Adaptive Servers being managed.
This example also allows different external identities and passwords to be used for authentication, while their actions within Adaptive Server still require the special privileges associated with “sa” account.
Example 2 Uses both PAM and LDAP to map users to application logins. A company has adopted both PAM and LDAP authentication but for different purposes. The company security policy defines LDAP as the authentication mechanism for general user accounts, and PAM for special users, such as for a middle-tier application. A middle-tier application may establish a pool of connections to Adaptive Server to handle requests on behalf of users of the middle-tier application.
Configure Adaptive Server for both LDAP and PAM user authentication:
sp_configure 'enable ldap user auth', 2 go sp_configure 'enable pam user auth', 2 go
Establish an Adaptive Server login appX locally
with permissions that are appropriate for the middle-tier application:
create login appX with password myPassword go alter login appX authenticate with PAM go
Instead of hard-coding a simple password in “appX” and maintaining the password consistently in several different Adaptive Servers, develop a custom PAM module to authenticate the application in a centralized repository using additional facts to verify the middle-tier application.
Client application login “appY” requires LDAP authentication of the user with its LDAP identity and password. Use sp_maplogin to map all LDAP authenticated users to login “appY,”
create login appY with password myPassword go sp_maplogin LDAP, NULL, 'appY' go
Users of “appY” are authenticated with their company identity and password, then mapped to a local Adaptive Server login “appY” to execute database actions. Authentication has occurred with the identity of the LDAP user, which is recorded in the audit trail, and executes with permissions appropriate to the application login “appY.”
