5
Configuring CyberSafe Authentication

This chapter contains information on how to configure Oracle for use with CyberSafe, as well as a brief overview of the steps to configure CyberSafe to authenticate Oracle users.

This chapter covers the following topics:

• Enabling CyberSafe Authentication

• Troubleshooting the Configuration of the CyberSafe Authentication Adapter

Enabling CyberSafe Authentication

Enable CyberSafe authentication by performing the following tasks.

Note: Perform the tasks in the order listed.

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 Server

Task 5: Extract the Service Table from CyberSafe

Task 6: Install an Oracle Server

Task 7: Install Oracle Advanced Security With CyberSafe

Task 8: Configure Net8 and Oracle on the Server and Client

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 Server

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

Task 13: Connect to an Oracle Server Authenticated by CyberSafe

Task 1: Install the CyberSafe Server

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

More Information: See the CyberSafe documentation listed in the "Related Publications" in the Preface.

Task 2: Install the CyberSafe TrustBroker Client

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

More Information: See the CyberSafe documentation listed in "Related Publications"in the Preface.

Task 3: Install the CyberSafe Application Security Toolkit

Perform this task on the client and on the server.

More Information: See the CyberSafe documentation listed in "Related Publications"in the Preface.

Task 4: Configure a Service Principal for an Oracle Server

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

The name of the principal should have 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 the fully-qualified name of the machine on which Oracle is running
REALM	the domain 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 actual programs that are run. 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 machine on which Oracle is running is dbserver.someco.com, and the realm is SOMECO.COM, the principal name is as follows:

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 server and CyberSafe TrustBroker client machines.

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
   
   
   

   Note: 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 above.

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 the additional entries.

3. Move the CyberSafe service table to the CyberSafe TrustBroker client machine. If the service table is on the same machine 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 machine 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 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, since this can allow a security breach.

Task 6: Install an Oracle Server

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

More Information: See the Oracle8i 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 Oracle8i. The Oracle Universal Installer guides you through the entire installation process.

More Information: See the Oracle installation documentation for your platform.

Task 8: Configure Net8 and Oracle on the Server and Client

More Information: See the platform-specific documentation.

Task 9: Configure CyberSafe Authentication

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

• Configure CyberSafe on the Client and on the Server

• Set REMOTE_OS_AUTHENT in the Initialization Parameter File

Configure CyberSafe on the Client and on the Server

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

1. Start Net8 Assistant:
   • On UNIX, run netasst from $ORACLE_HOME/bin.

   • On Windows NT, choose Start > Programs > Oracle - HOME_NAME > Network Administration > Net8 Assistant.

2. In the navigator's pane, expand Local > Profile.

3. From the list in the right pane, select Oracle Advanced Security.

   The Oracle Advanced Security tabbed pages appear.

4. Click the Authentication tab.

   
   

5. In the Available Methods list, select CYBERSAFE.

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

7. Arrange the selected methods in order of desired use. To do this, select a method in the Selected Methods list, then click 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. Click the Other Params tab.

   
   

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
    

    Note: You must insert the principal name, using the format described in Task 4: Configure a Service Principal for an Oracle Server.

11. Choose File > Save Network Configuration.

    The sqlnet.ora file updates 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:

REMOTE_OS_AUTHENT=FALSE

Note: Setting REMOTE_OS_AUTHENT to TRUE can allow a security breach because it allows someone using a non-secure protocol, such as TCP, to perform an operating system-authorized login (formerly referred to as 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 server after modifying the configuration files to enable the changes.

More Information: For information on how to restart the Oracle server, see the operating system-specific documentation and Oracle8i Administrator's Guide.

Task 10: Create a CyberSafe User on the Authentication Server

In order 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 actual programs that are run. 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.

The command prompts and responses that you enter are as follows:

# 
kdb5_edit
kdb5_edit:
ank cyberuser
Enter password: 
password
Re-enter password for verification:
password
kdb5_edit:
quit

More Information: For information on creating the realm, see "Related Publications" in the Preface.

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

Run SQL*Plus to create the Oracle user and enter the following commands on the Oracle server machine:

SQL> CONNECT INTERNAL; 
SQL> CREATE USER "USNERNAME" IDENTIFIED EXTERNALLY; 
SQL> GRANT CREATE SESSION TO "USERNAME";

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

Note: When you create the Oracle user, the name must be in uppercase and double-quoted.

In the following example, OS_AUTHENT_PREFIX is set to ("").

SQL> CREATE USER "JDOE" IDENTIFIED EXTERNALLY
SQL> GRANT CREATE SESSION TO "JDOE"

More Information: See Oracle8i Administrator's Guide.

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

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

1. Enter the following

   % kinit user_name
   
   

2. Enter the password for [e-mail]. The password is not echoed to the screen.

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:

   Creation Date         Expiration Date       Service
   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    [e-mail]
   

Task 13: Connect to an Oracle Server Authenticated by CyberSafe

After running kinit to get an initial ticket, users can connect to an Oracle 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 Net8 service name.

For example:

% sqlplus /@npddoc_db

More Information: See Chapter 1, "Introduction to Oracle Advanced Security" and Oracle8i Distributed Database Systems.

Troubleshooting the Configuration of the CyberSafe Authentication Adapter

This section lists 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 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 machines 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 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 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.