Troubleshooting the Configuration of the CyberSAFE Authentication Adapter
This chapter contains information on how to configure Oracle for use with CyberSAFE, as well as a brief overview of the steps you need to follow to configure CyberSAFE to authenticate Oracle users.
Steps to Perform to Enable CyberSAFE Authentication
This section contains information on the following tasks:
Note: You should perform these tasks in the order listed.
Install the CyberSAFE Server on the Machine that will Act as the Authentication Server
For information on how to install the CyberSAFE Challenger Master Server on your machine, refer to the CyberSAFE documentation listed in the Preface of this guide.
Install the CyberSAFE Challenger Client on the Same Machine that Runs the Oracle Server
For information on installing the CyberSAFE Challenger Client on clients refer to the CyberSAFE documentation listed in the Preface of this guide.
Install the CyberSAFE Application Security Toolkit
Install the CyberSAFE Application Security Toolkit on the Oracle client and Oracle server machines.
Configure a Service Principal for an Oracle Server
For the Oracle server to validate the identity of clients, you need to configure a service principal for an Oracle server on the machine running the CyberSAFE Challenger Master Server. Also configure a realm if necessary.
The name of the principal should have the following format:
"kservice/kinstance@REALM"
kservice is a string that represents the Oracle service. This may or may not be the same as the database service name.
kinstance is typically the fully-qualified name of the machine on which Oracle is running;
REALM is the domain of the server;
Note: kservice is case-sensitive, and REALM must always be capitalized.
Note: The utility names in this section are actual programs that you run. However, the CyberSAFE user name "cyberuser" and realm "SOMECO.COM" are examples only--the actual names may vary among systems.
For example, if kservice is "oracle", and the fully-qualified name of the machine on which Oracle is running is "dbserver.someco.com", and if the realm is "SOMECO.COM", the principal name would be:
oracle/dbserver.someco.com@SOMECO.COM
Note: It is a common convention to use the DNS domain name as the name of the realm.
To create the service principal, run kdb5_edit as root:
# cd /krb5/admin
# ./kdb5_edit
To add a principal called "oracle/dbserver.someco.com@SOMECO.COM" to the list of server principals known by CyberSAFE, from kdb5_edit enter the following:
kdb5_edit: ark oracle/dbserver.someco.com@SOMECO.COM
Extract the Service Table from CyberSAFE
You need to extract a service table from CyberSAFE and copy it to the Oracle server/CyberSAFE Challenger client machine.
For example, to extract a service table for dbserver.someco.com, from kdb5_edit enter the following:
kdb5_edit: xst dbserver.someco.com oracle
'oracle/dbserver.someco.com@SOMECO.COM'
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 (in the example, SOMECO.COM) when using xst, it uses the realm of the current host and displays it in the command output, as shown above.
Note: After the service table has been extracted, verify that the new entries are in the table in addition to the old ones. If they are not, or you need to add more, use kdb5_edit to append the additional entries.
Note: At this point, you need to move the CyberSAFE service table to the CyberSAFE Challenger client machine. If the service table is on the same machine as the CyberSAFE client, you can simply move it (using a command such as that shown below). If the service table is on a different machine from the CyberSAFE Challenger client, you must transfer the file with a program like ftp. For example, to move it, enter the following:
# mv dbserver.someco.com-new-srvtab /krb5/v5srvtab
Ensure that the Oracle Server Can Read the Service Table
Attention: Make sure 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.
Note: Do not make the file readable to all users. This will allow a security breach.
Install an Oracle Server
Install an Oracle server on the same machine that is running the CyberSAFE Challenger client. Refer to your operating system-specific documentation for information.
Install the Advanced Networking Option
Install the Advanced Networking Option on your Oracle client and Oracle server machines. Refer to your operating system-specific documentation.
Configure SQL*Net and Oracle7 on your Server and Client
For information on how to configure SQL*Net and Oracle7 on servers and clients, see your operating system-specific documentation.
Configure the CyberSAFE Authentication Adapter with Oracle Network Manager
This section describes how to configure the CyberSAFE authentication adapter from Network Manager. (If you do not have access to Oracle Network Manager, refer to "Configuration Parameters Required on the Oracle Server and Client" ![[*]](jump.gif)
for more information.)
Figure 4 - 1. Client Profile: General Page
Note: Network Manager creates a client profile for every community created (for example, TCP_world), and for every node that is a member of more than one community. If you create additional client profiles, Network Manager names them PRF2, PRF3, and so forth, but you should assign them more meaningful names.
Attention: You use the Client Profile to configure the Advanced Networking Option parameters for servers as well as clients.
Figure 4 - 2. Client Profile: Initial Authentication Page
Figure 4 - 3. Default Authentication Services Page
NO AUTHENTICATION is the default. Make this choice only if you want to disable authentication. For example, for users to be able to log into an Oracle database server using username/password, you must disable authentication by selecting this value. If you do, the following parameter will appear in the SQLNET.ORA file:
SQLNET.AUTHENTICATION_SERVICES = (NONE)
Note: If you open the Authentication Services page and decide you do not want to configure an authentication service, but do not want to disable authentication either, then press CANCEL.
If you want to specify one or more authentication services to be used in a specific order, select one of the authentication services from the drop down list at the top of the page. Choices are: Access Manager, CyberSAFE, Identix, Kerberos (V5), NO AUTHENTICATION, and SecurID.
Note: Access Manager is not currently supported.
Attention: Do not select an authentication service unless it is installed and linked into your SQL*Net network. If you do, it will cause connections to fail because they will try to use an authentication service that is not available.
Each authentication adapter you select has different parameters for which you may need to supply values. If a parameter is required, Network Manager will prompt you to enter it before leaving that page.
For further information on how to use Oracle Network Manager to configure authentication services, see the .
5. If you select CyberSAFE on the default Authentication page, the CyberSAFE page shown in Figure 4 - 4 displays.
Figure 4 - 4. CyberSAFE Authentication Page
GSSAPI Service
There is only one parameter for CyberSAFE, for which you must provide a value. An example of a possible entry is oracle/dbserver.someco.com@SOMECO.COM.
Note: You must provide a value for this parameter, or authentication will not function. If you do not enter a value for GSSAPI Service, you will be prompted to enter one when you try to generate configuration files.
Creating a CyberSAFE User on the Authentication Server
Perform the following steps to create Oracle users so they can be authenticated by the CyberSAFE adapter:
Note: Perform these steps on the authentication server (where the administration tools are installed).
It is assumed that the realm already exists. (Refer to the CyberSAFE documentation listed in the Preface if the realm needs to be created.)
Note: The utility names in this section are actual programs that you run. However, the CyberSAFE user name "cyberuser" and realm "SOMECO.COM" are examples only; these may vary among systems.
1. Run /krb5/admin/kdb5_edit as root to create the new CyberSAFE user, that is, "cyberuser".
# kdb5_edit
kdb5_edit: ank cyberuser
Enter password: <password not echoed to screen>
Re-enter password for verification: <password...>
kdb5_edit: quit
Create an Externally Authenticated Oracle User on the Oracle Server
Run Server Manager to create the Oracle user that corresponds to the CyberSAFE user. For example:
Note: You should perform the following commands on the Oracle server machine.
SVRMGR> connect internal;
SVRMGR> create user "CYBERUSER@SOMECO.COM"
identified externally;
SVRMGR> grant create session to
"CYBERUSER@SOMECO.COM";
Note: In this example, OS_AUTHENT_PREFIX is set to "".
Attention: When creating the Oracle user, the name must be in upper case and double-quoted; for example, "CYBERUSER@SOMECO.COM".
Use kinit on the Client to Get the Initial Ticket for the Kerberos/Oracle User
Before users can connect to the database, they need to run kinit on the clients for an initial ticket.
% kinit
Password for cyberuser@US.ORACLE.COM:
<password not echoed to screen>
Use klist on the Client to Display Credentials
Users should run klist on the clients to list the tickets currently owned.
% klist
Creation date Expiration date Service
11-Aug-95 16:29:51 12-Aug-95 00:29:21 krbtgt/SOMECO.COM@
SOMECO.COM
11-Aug-95 16:29:51 12-Aug-95 00:29:21
oracle/dbserver.someco.com
@SOMECO.COM
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 username or password. Enter a command like the following:
where service_name is a SQL*Net service name.
CyberSAFE Configuration Parameters Required on the Oracle Server and Client
This section describes the parameters that need to exist in configuration files on Oracle servers and clients to enable CyberSAFE to authenticate users.
Note: You should only manually configure files if you do not have access to Oracle Network Manager. Refer to "Configure the CyberSAFE Authentication Adapter with Oracle Network Manager" for information.
Oracle Client Configuration Parameters
Required SQLNET.ORA Parameters
Make sure the following line is present in the SQLNET.ORA file on the client:
SQLNET.AUTHENTICATION_SERVICES=(BEQ,CYBERSAFE)
Oracle Server Configuration Parameters
Required SQLNET.ORA Parameters
Make sure the following lines are present in the SQLNET.ORA file on the server.
sqlnet.authentication_services=(BEQ, CYBERSAFE)
sqlnet.authentication_gssapi_service=
oracle/dbserver.someco.com@SOMECO.COM
Note: You must insert the principal name, using the format described in "Creating the Oracle Principal" above.
Required INIT.ORA Parameters
It is strongly recommended that you add the following parameter to the INIT<SID>.ORA file used for the database instance:
REMOTE_OS_AUTHENT=FALSE
Note: <SID> is the database name.
Attention: Setting REMOTE_OS_AUTHENT to TRUE may create a security hole because it allows someone using a non-secure protocol (for example, 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, it is strongly recommended that the following null value be used for the value of OS_AUTHENT_PREFIX:
OS_AUTHENT_PREFIX=""
After modifying the configuration files, restart the Oracle server so the changes will take effect. (For information on how to restart the Oracle server refer to your operating system-specific documentation and to the Oracle7 Server Administrator's Guide.)
Troubleshooting the Configuration of the CyberSAFE Authentication Adapter
Here are some common configuration problems and tips to help resolve them:
If you cannot get your ticket-granting ticket using kinit:
- Make sure the default realm is correct by looking at krb.conf.
- Make sure the Challenger Master Server is running on the host specified for the realm.
- Make sure the Master Server has an entry for your user principal and the passwords match.
- Make sure 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 by the CyberSAFE Master Server.
- Check that the clocks on all machines involved 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 exists in the correct location and is readable by Oracle.
- Check that the v5srvtab has been generated for the service named in the SQLNET.ORA file 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. (The initial ticket must have been obtained by running kinit -f.)
- Check the expiration date on the credentials.
Attention: If your credentials have expired, you must close your connection and run kinit to get a new initial ticket.
