The following are considerations for configuring MIT Kerberos:
Install and configure the MIT software on your system, see the release bulletin for the version supported. This software can be downloaded from the MIT Web site.
Set the desired security features using ct_con_props, or use the default credentials by not setting credential properties.
Configure the security section of the libtcl.cfg configuration file.
Verify that the application has a preexisting user credential to connect to the server. In other words, the user of the application must log in to the Kerberos environment using an authentication tool (such as kinit or the lease32 utility) before running the client application.
If a user name is supplied, it must match the user’s preexisting credential. If a user name is not supplied, Client-Library connects to the server using the user name associated with the user’s credential.
The environment variable KRB5CCNAME specifies the cache name. If the default cache is not used, then set KRB5CCNAME to a different cache name.
For more information, refer to your MIT Kerberos documentation.
The MIT GSS library, gssapi32.dll, must be specified in the libtcl.cfg file using the libgss keyword. Sybase recommends providing the full path to the Kerberos driver.
No extra flags are required when compiling your Client-Library applications to use Kerberos security services.
Once you have configured Open Client and Open Server and MIT Kerberos, use any of the following isql commands (without -U and -P arguments) to test your configuration:
If DSQUERY is set to the server name that you want to connect to:
isql -V
If DSQUERY is not set:
isql -V -S server_name
If server_name is different from the Sybase Kerberos server principal name:
isql -V -R kerberos_server_principal_name [-S server_name]
Use -S server_name
if
DSQUERY is not set to server_name.
See README.SEC in the %SYBASE%\%SYBASE_OCS%\sample\srvlib directory for an example of configuring and running the example program.
You can run a custom Open Server application with Kerberos security. In order for the server and its clients to communicate over the network, you must perform the normal configuration steps described in Chapter 3, “Basic Configuration for Open Server.” In order for the server and its clients to use Kerberos security services, you must perform these additional configuration steps:
Decide which Kerberos principal the server will run as.
You can create a new principal with the kadmin utility, using the add command. The principal must be allowed to act as a server.
If the server principal does not already have a key in a Kerberos server key table file, create one with the kadmin utility, using the ext command. Make sure that the operating system user who starts the server has read permission on the server key table file. In a production environment, he or she must control the access to the key table file. If a user can read this file, they can create a server that impersonates your server.
Make sure the Kerberos security driver is configured in the [SECURITY] section of libtcl.cfg. See “Editing libtcl.cfg” for details.
Set the KRB5_KTNAME environment variable to the name of the key table file that holds the key for the server principal (see step 2). The Kerberos runtime libraries require this environment variable to be set if the server key table file is in a location other than the system default.
Enter the location of gssapi32.dll file in the libtcl.cfg directory using the libgss keyword.
When you start the server, specify the principal name in addition to the network name if the principal name does not match the network name. You do not have to specify the network name if you set the DSLISTEN environment variable to the network name.
The Open Server network name is defined in the interfaces directory service.
A custom Open Server application specifies the principal name by setting the SRV_S_SEC_PRINCIPAL Server-Library property.
Kerberos does not allow the key table file to be specified programatically; you must use the KRB5_KTNAME environment variable (see item 4).
See “Client-Library and security services” for an overview of how client applications use security services. These considerations apply to client applications that use Kerberos security services:
The application must use a preexisting user credential to connect to the server. In other words, the user of the application must log in to Kerberos before running the client application. Use the Kerberos kinit utility to log in to Kerberos.
If a user name is supplied, it must match the user’s preexisting credential. If a user name is not supplied, Client-Library connects to the server using the user name associated with the user’s Kerberos credential.
For suggestions on configuring the Kerberos environment and mixed Kerberos environments, refer to the technical document called “General Kerberos Configuration Tasks”.