System Administration Certification exam 919 for Informix 11.70 prep, Part 8: Security

Understanding connection security

Database connection security protects a database server from unauthorized access by using authentication and authorization processes. As a database administrator (DBA), you can configure the Informix server authentication mechanisms to meet varying needs, such as different security methods required for local and remote connections, database access by users without operating system accounts on the server's host computer, and non-root installation. You can also authorize authenticated users to perform certain database actions or access certain database objects based on their needs. When configuring Informix authentication, a DBA should consider how user names and passwords are validated:

• Should the user authenticate on the server machine?
• Do any non-OS users need to connect to Informix databases?
• What are the current security policies enforced on the system?
• What are the authentication methods available?

In Informix 11.70, you can configure authentication in different ways:

• Using OS for verification that the user is legitimate. This mechanism requires that a user has a valid OS user account on the Informix host computer and is granted connection privileges by the database system administrator (DBSA).
• Using a self-defined authentication mechanism supported by Informix server, including pluggable authentication modules (PAM) on UNIX or Linux and lightweight directory access protocol (LDAP) authentication on Windows.
• Using mapped users. This mechanism is new in Informix 11.70 to maintain security while reducing the dependency on system administrator and root-level privileges.
• Using single sign-on (SSO) to bypass the requirement to provide user name and password after a user logs in to the client computer's operating system with Kerberos.

You can establish trusted connections through trusted-context database objects to increase system performance and security within a three-tier application model. The concept of a trusted connection through a trusted-context object is different than trusted systems by configuring hosts.equiv or .rhosts file on UNIX or Linux.

Understanding the pluggable authentication module

Pluggable authentication module (PAM) enables system administrators to implement different authentication mechanisms for different applications based on their business needs. Make sure the operating system of the Informix server supports PAM.

The PAM module determines whether a user can authenticate by providing a password, responding correctly to a challenge, or a combination of both. The modes supported by Informix 11.70 are password mode and challenge-response mode. In password mode, the user password is sufficient to satisfy the authentication. In the challenge-response mode, a server raises a challenge, and the client sends a response. A client gets access to the database only if the response is as expected. When the Informix server is configured to use PAM module for authentication, the default authentication will be ignored.

To configure an Informix server to use PAM, the system administrator must know:

• The name of the PAM module that is typically located under the /usr/lib/security directory and its parameters are listed in /etc/pam.conf. In Linux, the /etc/pam.conf file can be replaced with a directory called /etc/pam.d, where there is a file for each PAM service. If /etc/pam.d exists, Linux will ignore /etc/pam.conf.
• Whether the PAM module will raise a challenge in addition to accepting a simple username and password combination.

You must modify the server entry in the sqlhosts file on the database server to enable PAM authentication. If the application and server are on separate computers or in separate locations on a single machine, the sqlhosts file will need to be modified for both the client and server.

Table 1 lists the settings for PAM services in sqlhosts.

You need to set the s option to 4 for enabling PAM services.

Listing 1 shows an sqlhosts entry that enables PAM authentication with challenge.

#Authentication mode: challenge 
ifxserver2 oltlitcp servermc portnum2 s=4, pam_serv=(pam_pass), pamauth=(challenge) 

Listing 2 shows another sqlhosts entry that enables PAM authentication that needs only a password.

#Authentication mode: password
ifxserver2 oltlitcp servermc portnum2 s=4, pam_serv=(pam_pass), pamauth=(password)

When the operating system or third-party PAM modules (shared libraries) are loaded into the informix user thread, the stack size required for the PAM modules is unpredictable. You can customize the stack size for PAM modules by setting the onconfig parameter PAM_STACKSIZE to a larger value, as shown in Listing 3.

PAM_STACKSIZE 64 # Stack size needed for the PAM modules (kilobytes) 

On UNIX, the default value of PAM_STACKSIZE is 32 KB. On Linux, the default value is 128 KB plus the value of the STACKSIZE configuration parameter.

Not all IBM Informix products and tools support PAM. You can find more information about compatibility issues with authentication modules in the Informix Information Center (see Resources).

Back to top

Understanding LDAP authentication on Windows

Similar to PAM used on UNIX and Linux, LDAP can be set up and configured on Windows for different authentication mechanisms. You need to create your own LDAP authentication module for your specific LDAP authentication.

The authentication module is a DLL that usually is located in the %INFORMIXDIR%\dbssodir\lib\security directory. The parameters of the module are listed in the %INFORMIXDIR%\dbssodir\pam.conf file. The source code for a fully functional LDAP authentication module and samples of the required configuration files are included in the %INFORMIXDIR%\demo\authentication directory.

Not all IBM Informix products and tools support PAM. You can find more information about compatibility issues with authentication modules in the Informix Information Center (see Resources).

To make an LDAP authentication module work with Informix server, you should make sure you have an LDAP server and an LDAP client-side system available. You can use IBM Directory Server or openLDAP as the LDAP client-side system.

You can use the template of the PAM configuration file to configure your LDAP module by copying the template file pam.conf_tmpl to %INFORMIXDIR%\dbssodir\etc, renaming it to pam.conf, and customizing it.

To configure a server to use an LDAP authentication support module, you must edit the sqlhosts file with the name of the LDAP module and the authentication mode. Listing 4 shows an Informix server configured to use PAM challenge authentication.

ifxserver1 onsoctcp servermc portnum1 s=4,pam_serv=(pam_chal),pamauth=(challenge)

Listing 5 shows an Informix server configured to use PAM password authentication.

ifxserver2 onsoctcp servermc portnum2 s=4,pam_serv=(pam_pass),pamauth=(password)

You can find more information about how to install and customize the LDAP authentication module in the Informix Information Center.

Back to top

Mapping users (UNIX or Linux)

Beginning in Informix version 11.70, Informix can allow externally authenticated users to access a database server by mapping them to the appropriate user and group privileges, regardless of whether these users have local operating system accounts on the IBM Informix host computer. This feature is only available for UNIX or Linux systems. External users that are authenticated with SSO or PAM can be mapped to either of the following:

• A UID and GID pair defined in the database server but not established as an OS account on the server host computer
• An existing OS user account on the database server host computer

Users who obtain database access using user mapping are referred to as mapped users. Only a DBSA can create a mapped user.

When the DBSA grants database server access to externally authenticated users, the permissions that are mapped to these users are referred to as surrogate user properties. Surrogate user properties include one or more of the following:

• User ID
• Group ID
• OS user name
• Group name
• Home directory

This mapped user functionality can help DBSAs and system administrators who do not know in advance all legitimate users who will need access to the database server.

The DBSA maps a user to surrogate user properties by running the GRANT ACCESS TO command in SQL.

Allowing connections to the database server without corresponding OS user accounts changes the default Informix configuration. The USERMAPPING configuration parameter must be set for mapped users to access the database successfully. Access is set to OFF when you create a new Informix instance or when you complete an upgrade.

Removing the dependency on a local host OS account for database server access reduces administrative work. With mapped users, the DBSA is not required to coordinate with the OS administrator to ensure that every user who should have Informix access also has an OS account. However, in many environments other considerations might warrant that Informix access still requires the presence of a user identity on the OS level of the host computer.

Before you start to create a mapped user, you must verify the following:

• You have DBSA privileges to complete this task.
• The users that you want to map to surrogate user properties for Informix access can externally authenticate with single sign-on (SSO) or a pluggable authentication module (PAM).
• Informix server instance is configured to accept authentication through PAM or SSO.

Complete the following steps to create a mapped user.

1. Set the USERMAPPING parameter of the onconfig file to one of two values:
   • BASIC: no Informix administrative privileges, regardless of which UID or GID the user is mapped to.
   • ADMIN: possible to have Informix administrative privileges. No administrative privileges are given to any users until you run the AUTHORIZATION clause of the GRANT ACCESS TO statement. Typically, if you set this parameter to ADMIN, there are only a few individual mapped users to whom you plan to grant administrative privileges.
2. Specify surrogate user properties with the GRANT ACCESS TO statement. The statement maps externally authenticated users to the properties that enable Informix access. If you want to grant administrative privileges to a mapped user, you must include the AUTHORIZATION keyword with the value that designates the role that you want to grant the user. After you run the GRANT ACCESS TO statement, new rows are added to the user mapping tables in the SYSUSER database.

Note: Mapped users can access Informix with the surrogate user properties only if they authenticate with SSO or PAM.

Back to top

Using single sign-on authentication

Single sign-on (SSO) is an authentication mechanism that bypasses the requirement to provide user name and password after a user logs in to the client computer's operating system. With SSO, authentication for the DBMS and other SSO-enabled services happens when a user first logs into the client computer (or domain, in the case of Windows). The Kerberos implementation validates the user credentials. Kerberos authentication generates a system of secret keys that store login credentials. When a user action tries to access an Informix database, an exchange of ticket-granting tickets (TKTs) allows database access without a login prompt.

SSO authentication uses both of the following open computing standards:

Generic Security Services Application Programming Interface (GSSAPI)

An API defined by Internet Engineering Task Force (IETF) standard RFC 2743 for client-server authentication

Kerberos security protocol

RFC 1510 that defines a typical key exchange mechanism. Applications can use the Kerberos service to authenticate their users and exchange cryptographic keys containing credentials.

Generic Security Services communications support module (GSSCSM) does not function with the simple password and encryption modules (SPWDCSM and ENCCSM). SSO implemented with GSSCSM supports PAM and LDAP, but it does not support mutual authentication.

For single sign-on, the user login process and authentication must employ a Kerberos 5 network infrastructure, including a dedicated Key Distribution Center computer.

Following is the high-level procedure for deploying Kerberos SSO for Informix:

1. Configure the computers on the network to function with the Kerberos 5 authentication protocol. This involves setup of a secured computer to host the Key Distribution Center (KDC). It is possible that your network has already been set up with a Kerberos mechanism.
2. Create client user principals and the Informix service principal in the KDC (see Resources).
3. Configure the sqlhosts information and GSSCSM on the computer hosting the database server.
4. Configure the Informix service principal key and ensure it is on the computer hosting the database server.
5. Configure a database client program that functions with GSSCSM (see Resources).

To configure an Informix instance for SSO, you need to complete the following tasks in the Informix Information Center:

1. Set SQLHOSTS information for SSO
2. Set up the concsm.cfg file for SSO
3. Ensure keytab file has the required key (UNIX and Linux)
4. Verify Informix uses Kerberos authentication for SSO

Back to top

Understanding trusted context

In a three-tier application model, all database users must log in to the middle tier with their user IDs and passwords. The middle tier will then connect to the database server with a different user ID and password. Using a trusted-context database object, you can establish trusted connections from your application to your database to achieve the following:

• Increase system security
• Increase overall system performance
• Reduce maintenance overhead
• Control user privileges
• Preserve auditing capability of user access

A trusted connection through a trusted context object also allows an application developer to maintain his or her user ID to access a database or share a single database connection with other users.

Only a user ID that has been granted the DBSECADM role can create, alter, rename, and drop trusted context objects.

When creating a trusted context object, consider the following:

• Which role and privileges should be assigned for users of a trusted-context object
• Which client locations are trustable
• Which use is required to authenticate

A context object can obtain any of the following:

• Attributes or locations for defining a trusted connection
• Authentication requirements for trusted-connection users
• Roles for defining the access privileges of trusted-connection users

If a trusted-connection request matches all of a trusted-context object's attributes, the system grants a trusted connection. If a connection request contains an attribute that doesn't match the trusted-context object, the system rejects the request.

Two steps are required to establish a trusted connection through a trusted-context database object:

1. Create a trusted context database object with the CREATE TRUSTED CONTEXT statement. You must have the database security administrator (DBSECADM) role to run this statement. Make sure that the following are true:
   • Each ATTRIBUTES, DEFAULT ROLE, ENABLE, and WITH USE clause is specified no more than once.
   • Each attribute name and corresponding value is unique.

   The example in Listing 6 creates a trusted-context object called appserver such that the current user john on a trusted connection based on appserver can be switched to two different users: joe and bob. When the current user john is switched to user joe, no authentication is required, but authentication is required when switched to user bob.

   
   
   Listing 6. Establishing a trusted connection through a trusted context database object
   

   CREATE TRUSTED CONTEXT appserver USER john DEFAULT ROLE MANAGER ENABLE ATTRIBUTES (ADDRESS '9.26.113.204') WITH USE FOR joe WITHOUT AUTHENTICATION, bob WITH AUTHENTICATION;

   
   
2. Create a trusted connection in your database application. To create trusted connections, you must use an application that connects to the Informix server using TCP/IP. Local communication protocols are not supported. Make sure that the following are true:
   • The trusted-context object is enabled.
   • Your user ID has CONNECT privileges to the database.
   • Your user ID matches the primary user ID in the trusted-context object.
   • Your connection request is coming from a trusted location that is defined in the trusted-context object.

   The following APIs can be used to request trusted connections:

   • IBM Informix ESQL/C
   • IBM Informix JDBC Driver
   • IBM Informix ODBC Driver
   • IBM Data Server Driver for JDBC and SQLJ
   • IBM Data Server Provider for .NET

   The example in Listing 7 creates a trusted connection in ESQL/C by adding the TRUSTED keyword within the existing CONNECT statement.

   
   
   Listing 7. Adding the TRUSTED keyword
   

   EXEC SQL CONNECT TO 'database_name' TRUSTED;

   
   

Specific rules apply to switching users on a trusted connection.

2 of 8 | Previous | Next

Comments

Back to top

Table of contents

• Before you start
• Understanding connection security
• Using network encryption
• Using auditing
• Using discretionary access control
• Conclusion
• Resources
• About the authors

---

2 of 8 | Previous | Next

Next steps from IBM

• Try: Informix Ultimate Edition
• Buy: Informix Ultimate Edition

Dig deeper into Information Management on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers