5
Configuring CyberSafe Authentication

This chapter describes how to configure Oracle Advanced Security for Oracle9i, or for the Oracle9i server, so that CyberSafe TrustBroker, a Kerberos-based authentication server, can be used to authenticate Oracle users. This chapter contains the following topics:

• Configuring CyberSafe Authentication

• Troubleshooting

Configuring CyberSafe Authentication

To configure CyberSafe authentication:

• Task 1: Install the CyberSafe Server

• Task 2: Install the CyberSafe TrustBroker Client

• Task 3: Install the CyberSafe Application Security Toolkit

• Task 4: Configure a Service Principal for an Oracle Database Server

• Task 5: Extract the Service Table from CyberSafe

• Task 6: Install an Oracle Database Server

• Task 7: Install Oracle Advanced Security With CyberSafe

• Task 8: Configure Oracle Net and Oracle9i

• Task 9: Configure CyberSafe Authentication

• Task 10: Create a CyberSafe User on the Authentication Server

• Task 11: Create an Externally Authenticated Oracle User on the Oracle Database Server

• Task 12: Get the Initial Ticket for the CyberSafe/Oracle User

• Task 13: Connect to an Oracle Database Server Authenticated by CyberSafe

Task 1: Install the CyberSafe Server

Perform this task on the system that functions as the authentication server.

See Also: CyberSafe documentation listed under Related Documentation

Task 2: Install the CyberSafe TrustBroker Client

Perform this task on the system that runs the Oracle database server and the client.

See Also: CyberSafe documentation listed under Related Documentation

Task 3: Install the CyberSafe Application Security Toolkit

Perform this task on both the client and server systems.

See Also: CyberSafe documentation listed under Related Documentation

Task 4: Configure a Service Principal for an Oracle Database Server

For the Oracle database server to validate the identity of clients, configure a service principal for an Oracle database server on the system running the CyberSafe TrustBroker Master Server. If required, also configure a realm.

The name of the principal has the following format:

kservice/kinstance@REALM


kservice	A case-sensitive string that represents the Oracle service. This might not be the same as the database service name
kinstance	Typically, this is the fully-qualified name of the system on which Oracle is running
REALM	The domain name of the server. REALM must always be uppercase, and is typically named the DNS domain name. If you do not enter a value for REALM when using xst, kdb5_edit uses the realm of the current host and displays it in the command output.

Note: The utility names in this section are executable programs. However, the CyberSafe user name CYBERUSER and the realm SOMECO.COM are examples only.

For example, if the Oracle service is oracle, the fully-qualified name of the system on which Oracle is running is dbserver.someco.com, and the realm is SOMECO.COM, the principal name is:

oracle/[e-mail]

Run kdb5_edit as root to create the service principal as follows:

# cd /krb5/admin

# ./kdb5_edit

To add a principal named oracle/[e-mail] to the list of server principals known by CyberSafe, enter the following in kdb5_edit:

kdb5_edit: ark oracle/[e-mail]

Task 5: Extract the Service Table from CyberSafe

Extract a service table from CyberSafe and copy it to both the Oracle database server and CyberSafe TrustBroker client systems.

For example, to extract a service table for dbserver.someco.com, perform the following steps.

1. Enter the following in kdb5_edit:

   kdb5_edit: xst dbserver.someco.com oracle 'oracle/[e-mail]' added to keytab 'WRFILE:dbserver.someco.com-new-srvtab'

   kdb5_edit: exit

   # /krb5/bin/klist -k -t dbserver.someco.com-new-srvtab


   If you do not enter a realm (SOMECO.COM in the example) when using xst, kdb5_edit uses the realm of the current host and displays it in the command output, as shown in the proceeding input example.

2. After the service table has been extracted, verify that the new entries are in the table, in addition to the old entries. If the new entries are not in the service table, or if you need to add additional new entries, use kdb5_edit to append them.

3. Move the CyberSafe service table to the CyberSafe TrustBroker client system. If the service table is on the same system as the CyberSafe client, move it as in the following example:

# mv dbserver.someco.com-new-srvtab /krb5/v5srvtab

If the service table is on a different system from the CyberSafe TrustBroker client, transfer the file with a program such as FTP. If using FTP, transfer the file in binary mode.

Ensure that the owner of the Oracle database server executable can read the service table (in the previous example, /krb5/v5srvtab). Set the file owner to the Oracle user, or make the file readable by the group to which Oracle belongs. Do not make the file readable to all users--this can enable a security breach.

Task 6: Install an Oracle Database Server

Install an Oracle database server on the same system that is running the CyberSafe TrustBroker client.

See Also: Oracle9i installation documentation for your platform

Task 7: Install Oracle Advanced Security With CyberSafe

Install CyberSafe, along with Oracle Advanced Security, during a custom installation of Oracle9i. The Oracle Universal Installer guides you through the entire installation process.

See Also: Oracle9i installation documentation for your platform

Task 8: Configure Oracle Net and Oracle9i

Configure Oracle Net and Oracle9i on both the server and client systems.

See Also: Oracle9i installation documentation for your platform

Task 9: Configure CyberSafe Authentication

Perform the following tasks to set parameters in the Oracle database server and client sqlnet.ora files to configure CyberSafe:

• Configure CyberSafe on both the Client and the Oracle Database Server

• Set REMOTE_OS_AUTHENT in the Initialization Parameter File (init.ora).

Configure CyberSafe on both the Client and the Oracle Database Server

To configure CyberSafe authentication service parameters on both the client and the database server:

1. Start Oracle Net Manager:
   • On UNIX, run netmgr from $ORACLE_HOME/bin.

   • On Windows NT, choose Start > Programs > Oracle - HOME_NAME > Network Administration > Oracle Net Manager.

2. In the Navigator window, expand Local > Profile.

3. From the list in the right pane, select Oracle Advanced Security; the Oracle Advanced Security Authentication window appears (Figure 5-1):

   Figure 5-1 Oracle Advanced Security Authentication Window (Cybersafe)

   
   
   Text description of the illustration cyb_auth.gif
4. Choose the Authentication tab.

5. In the Available Methods list, select CYBERSAFE.

6. Move CYBERSAFE to the Selected Methods list by choosing the right-arrow [>].

7. Arrange the selected methods in order of desired use. To do this, select a method from the Selected Methods list and choose Promote or Demote to position it in the list. For example, if you want CYBERSAFE to be the first service used, put it at the top of the list.

8. Choose the Other Params tab (Figure 5-2):

   Figure 5-2 Oracle Advanced Security Other Params Window (Cybersafe)

   
   
   Text description of the illustration cybersafe.gif
9. From the Authentication Service list, select CYBERSAFE.

10. Enter the name of the GSSAPI Service, as in the following example:

    oracle/dbserver.someco.com @SOMECO.COM

    Insert the principal name, using the format described in Task 4: Configure a Service Principal for an Oracle Database Server.

11. Choose File > Save Network Configuration.

    The sqlnet.ora file is updated with the following entries:

    SQLNET.AUTHENTICATION_SERVICES=(CYBERSAFE)
    SQLNET.AUTHENTICATION_GSSAPI_SERVICE=KSERVICE/KINSTANCE@REALM
    

Set REMOTE_OS_AUTHENT in the Initialization Parameter File

Add the following parameter to the Initialization Parameter File (init.ora):

REMOTE_OS_AUTHENT=FALSE

Note: Setting REMOTE_OS_AUTHENT to TRUE can enable a security breach because it lets someone using a non-secure protocol, such as TCP, perform an operating system-authorized login (formerly called an OPS$ login).

Because CyberSafe user names can be long, and Oracle user names are limited to 30 characters, Oracle Corporation recommends using null for the value of
OS_AUTHENT_PREFIX, as follows:

OS_AUTHENT_PREFIX=""

Restart the Oracle database server after modifying the configuration files to enable the changes.

See Also: Operating system specific documentation and Oracle9i Database Administrator's Guide for more information about how to restart the Oracle database server

Task 10: Create a CyberSafe User on the Authentication Server

For CyberSafe to authenticate Oracle users, you must create them on the CyberSafe authentication server where the administration tools are installed. The following steps assume that the realm already exists.

Note: The utility names in this section are executable programs. However, the CyberSafe user name CYBERUSER and realm SOMECO.COM are examples only.

Run /krb5/admin/kdb5_edit as root on the authentication server to create the new CyberSafe user, such as CYBERUSER.

Enter the following:

# kdb5_edit
kdb5_edit:
ank cyberuser
Enter password: 
<password> (password does not display)
Re-enter password for verification:
<password> (password does not display)
kdb5_edit: quit

See Also: Cybersafe documentation listed in Related Documentation for information about creating the realm

Task 11: Create an Externally Authenticated Oracle User on the Oracle Database Server

Run SQL*Plus to create the Oracle user, and enter the following commands on the Oracle database server (note that the Oracle user name must be uppercase and enclosed in double quotation marks):

In this example, OS_AUTHENT_PREFIX is set to null ("").

SQL> CONNECT / AS SYSDBA;
SQL> CREATE USER "[e-mail]" IDENTIFIED EXTERNALLY;
SQL> GRANT CREATE SESSION TO "[e-mail]";

See Also: Oracle9i Database Administrator's Guide

Task 12: Get the Initial Ticket for the CyberSafe/Oracle User

Before users can connect to the database, they must run kinit on the clients for an initial ticket:

1. Enter the following:

   % kinit cyberuser

2. Enter the password (password does not display).

3. To list currently owned tickets, run klist on the clients. Enter the following at the system command prompt:

   % klist

   The system displays the following information:

   11-Aug-99 16:29:51	12-Aug-99 00:29:21	krbtgt/[e-mail]
   11-Aug-99 16:29:51	12-Aug-99 00:29:21	oracle/[e-mail]

Task 13: Connect to an Oracle Database Server Authenticated by CyberSafe

After running kinit to get an initial ticket, users can connect to an Oracle database server without using a user name or password. Enter a command similar to the following:

% sqlplus /@net_service_name

where net_service_name is a Oracle Net service name.

For example:

% sqlplus /@npddoc_db

See Also: Chapter 1, Introduction to Oracle Advanced Security, and Oracle9i Heterogeneous Connectivity Administrator's Guide

Troubleshooting

This section describes some common configuration problems and explains how to resolve them:

If you cannot get your ticket-granting ticket using kinit:

• Ensure that the default realm is correct by looking at krb.conf.

• Ensure that the TrustBroker Master Server is running on the host specified for the realm.

• Ensure that the Master Server has an entry for the user principal and that the passwords match.

• Ensure that the krb.conf and krb.realms files are readable by Oracle.

If you have an initial ticket, but still cannot connect:

• After trying to connect, check for a service ticket.

• Check that the sqlnet.ora file on the database server side has a service name that corresponds to a service known to the CyberSafe Master Server.

• Check that the clocks on all the involved systems are within a few minutes of each other.

If you have a service ticket, and you still cannot connect:

• Check the clocks on the client and database server.

• Check that the v5srvtab file exists in the correct location and is readable by Oracle.

• Check that the v5srvtab file has been generated for the service named in the profile (sqlnet.ora) on the database server side.

If everything seems to work fine, but then you issue another query and it fails:

• Check that the initial ticket is forwardable. You must have obtained the initial ticket by running kinit -f.

• Check the expiration date on the credentials.

• If the credentials have expired, close the connection and run kinit to get a new initial ticket.