Oracle Advanced Networking Option Administrator's Guide
Release 8.0.3

A54084_01

Library

Product

Contents

Index

Prev Next

11

Configuring Oracle for Oracle DCE Integration

This chapter discusses how to configure Oracle and Net8 to use Oracle DCE Integration after it has been successfully installed. The following sections describe the parameters you need to configure for servers and clients.

11.1 DCE Address Parameters

DCE addresses in the LISTENER.ORA and TNSNAMES.ORA configuration files are defined by DCE parameters. These parameters consist of both mandatory and optional fields, which are described below:

ADDRESS=(PROTOCOL=DCE)
(SERVER_PRINCIPAL=server_name)
(CELL_NAME=cell_name)
(SERVICE=dce_service_name))

where:

PROTOCOL is a mandatory field that identifies the DCE RPC protocol.

SERVER_PRINCIPAL is a mandatory field for the server and an optional field for the client. The server authenticates itself to DCE as this principal. This field is mandatory in LISTENER.ORA and specifies the principal the server will start under. This field is optional in TNSNAMES.ORA and specifies the principal of the server the client must connect to. If not specified, then one-way authentication is used. In this case, the client does not care what principal the server is running under.

CELL_NAME is an optional parameter. If present, it specifies the DCE cell name of the database. If this parameter is not set, the cell name defaults to the local cell (useful for single-cell environments). Optionally, the SERVICE parameter (described below) may specify the complete path (including the cell name) to the service, making this parameter unnecessary.

SERVICE is a mandatory field for both server and client. For the server, this is the service registered with CDS. For the client, this is the service name used when querying CDS for the location of the Oracle DCE servers. The default directory for storing service names in CDS is /.../cell_name/subsys/oracle/service_registry. This service name can fully specify the path in CDS.

You can specify a service as:

SERVICE=/.../cell_name/subsys/oracle/service_registry/dce_service_name

or it can be specified as

SERVICE=dce_service_name

provided that CELL_NAME=cell_name is also specified.

A third option is to specify SERVICE=dce_service_name, in which case the cell name defaults to the local cell. However, this third way of specifying service names only works well if you are working within a single cell.

Note:

The dce_service_name in the service field may or may not be the same as the service name used by Net8. The service name used by Net8 is mapped to the connect descriptor in TNSNAMES.ORA. The dce_service_name is part of the address within the connect descriptor.  

Note:

In this DCE Integration release, the configuration files LISTENER.ORA, SQLNET.ORA, TNSNAMES.ORA, and PROTOCOL.ORA are located in the $ORACLE_HOME/network/admin directory. The INIT<SID>.ORA file is located in the $ORACLE_HOME/dbs directory.  

11.2 Configuring the Server

To configure a server for DCE Integration, you need to configure the following Net8 files with DCE address and parameter information as described in Section 11.1, "DCE Address Parameters" and in the following sections.

Note:

Use the Oracle Net8 Assistant to create the necessary configuration files. For explanations of the configuration files, see Net8 Administrator's Guide.  

Note the following prerequisites:

11.2.1 LISTENER.ORA Parameters

For a database server to receive connections from Net8 clients in a DCE environment, there must be a Net8 listener active on the server platform. A listener listens for connections on a network address that is defined in the LISTENER.ORA file.

The SERVER_PRINCIPAL parameter designates what DCE principal the listener should be running under. In the sample below, the listener is running under principal "oracle".

11.2.2 Sample DCE Address in LISTENER.ORA

Below is a sample DCE address as it would appear in the LISTENER.ORA file.

LSNR_DCE=
(ADDRESS=
(PROTOCOL=DCE) (SERVER_PRINCIPAL=oracle) (CELL_NAME=cell1) (SERVICE=dce_svc))
SID_LIST_LSNR_DCE=
(SID_DESC=
(SID_NAME=ORASID)
(ORACLE_HOME=/private/oracle7))

11.3 Creating and Naming Externally-Authenticated Accounts

To use DCE authentication for logging onto the Oracle database, you need to create database accounts that are "authenticated externally".

Refer to Oracle8 Server Distributed Databases for more information on external authentication.

To enable secure external authentication, do the following:

  1. Verify that these lines are in the INIT<SID>.ORA file:
    	REMOTE_OS_AUTHENT=FALSE 
    OS_AUTHENT_PREFIX=""
  2. Verify that the INIT<SID>.ORA file does not have a multi-threaded server (MTS) entry for DCE. For example, an entry such as the following is not allowed:
    	mts_dispatchers="dce, 3"  
    
    
  3. Make sure that you are logged in as a member of the DBA group. Restart the database instance for the changes to take effect.
  4. At the server manager prompt, define users. Before doing so, decide whether you are, or ever will be, operating in a multi-cell DCE environment in which you will allow Oracle access across cell boundaries. The way you define users depends on whether they will be connecting within a single cell, or across cell boundaries.
    Note:

    The privileges shown in the remainder of this section are the minimum privileges necessary. The actual set of privileges needed depends on the instance and/or application.  

    If users will be connecting within a local cell, use the following format.

    svrmgr1> create user SERVER_PRINCIPAL identified externally;
    	svrmgr1> grant create session to SERVER_PRINCIPAL;
    
    

    For example:

    	svrmgr1> create user oracle identified externally;
    	svrmgr1> grant create session to oracle;
    
    
    Note:

    The entire CELL_NAME/SERVER_PRINCIPAL string must be 15 characters or less.

    For example:

    		svrmgr1> create user "CELL1/ORACLE" identified 
    externally;
    

    svrmgr1> grant create session to "CELL1/ORACLE";  

    If connecting to the database across multiple cells, specify both the CELL_NAME and the SERVER_PRINCIPAL.

    		svrmgr1> create user "CELL_NAME/SERVER_PRINCIPAL" identified 
    externally;
    		svrmgr1> grant create session to "CELL_NAME/SERVER_PRINCIPAL";
    
    
    Attention:

    You must enclose the externally-identified account name in double quotes, because the slash is a reserved character. Also, if the account (user) name is double-quoted, it must be capitalized.  

    For example:

    		svrmgr1> create user "CELL1/ORACLE" identified externally;
    		svrmgr1> grant create session to "CELL1/ORACLE";
    
    
    Note:

    When using the above format, set the following parameter in PROTOCOL.ORA to FALSE:

    			dce.local_cell_usernames=false 
    
     
    Note:

    References to an Oracle account created in this manner must include the schema/account in the correct format. For example, consider requests for access to tables from another account. When a user references the tables in another account created within a local cell, the command might be:

    			SQL> select * from oracle.emp
    

    If a user wants to access tables in an another account created for connections across cells, the command might be:

    SQL> select * from "CELL1/ORACLE".emp  

11.4 Setting up DCE Integration External Roles

To set up external roles for DCE Integration, do the following:

  1. Set the following parameter in the INIT<SID>.ORA file.
    		OS_ROLES=TRUE
    
    

    Then restart the database.

  2. Make sure that the DCE groups that map to Oracle roles adhere to the following syntax:
    	ORA_<SID>_<ROLE>[_[A][D]]
    
    

    where:

    ORA Designates that this group is used for Oracle purposes

    <SID> Is the Oracle System Identifier

    <ROLE> Is the name of the role, as defined in the data dictionary

    A Optional character indicating that the user has admin
    privileges for this role.

    D Optional character indicating the role is to be enabled
    by default at connect time.

    Note:

    For more details on external roles see the Oracle8 Server Administrator's Guide.  

  3. DCE authenticate to a user who is a member of a DCE group by performing a dce_login and a klist command. (Below is some sample output from the dce_login and klist commands.)
    Note:

    The DCE group must adhere to the syntax described in step 2.

    % dce_login oracle
    Enter Password:
    % klist
    DCE Identity Information:
    Warning: Identity information is not certified
    Global Principal: /.../ilab1/oracle
    Cell: 001c3f90-01f5-1f72-ba65-02608c2c84f3 /.../ilab1
    Principal: 00000068-0568-2f72-bd00-02608c2c84f3 oracle
    Group: 0000000c-01f5-2f72-ba01-02608c2c84f3 none
    Local Groups:
    0000000c-01f5-2f72-ba01-02608c2c84f3 none
    0000006a-0204-2f72-b901-02608c2c84f3 subsys/dce/cds-server
    00000078-daf4-2fe1-a201-02608c2c84f3 ora_dce222_dba
    00000084-89c8-2fe8-a201-02608c2c84f3 ora_dce222_connect_d
    00000087-8a13-2fe8-a201-02608c2c84f3 ora_dce222_resource_d
    00000080-f681-2fe1-a201-02608c2c84f3 ora_dce222_role1_ad .
    . .
     
  4. Connect to the database as usual.

    Following is some sample output showing a connection to a database and a listing of external roles (DBA, CONNECT, RESOURCE, and ROLE1) that have been mapped to DCE groups.

    % sqlplus /@test_222

    SQL*Plus: Release 3.2.2.0.0 - Production on Thu Aug 31 11:24:12 1995

    Copyright (c) Oracle Corporation 1979, 1994. All rights reserved.

    Connected to:
    Oracle7 Server Release 7.2.2.3.0 - Production Release
    PL/SQL Release 2.2.2.3.0 - Production

    SQL> select * from session_roles;

    ROLE
    ------------------------------
    CONNECT
    RESOURCE
    ROLE1

    SQL> set role all;

    Role set.

    SQL> select * from session_roles;

    ROLE
    ------------------------------
    DBA
    EXP_FULL_DATABASE
    IMP_FULL_DATABASE
    CONNECT
    RESOURCE
    ROLE1

    6 rows selected.

    SQL> exit
    Disconnected from Oracle7 Server Release 7.2.2.3.0 - Production Release
    PL/SQL Release 2.2.2.3.0 - Production
    % logout

11.5 Configuring the Client

To configure a client for DCE Integration, you need to configure the following Net8 files with DCE address and parameter information, as described in "Description of the DCE Address Parameters" and below:

Typically, CDS is used for name resolution. Thus, TNSNAMES.ORA is not used, except when loading names and addresses into CDS. See Section 11.6, "Configuring Clients to Use the DCE CDS Naming Adapter".

11.5.1 Description of Parameters in PROTOCOL.ORA

In this release of DCE Integration, there are four DCE parameters located in PROTOCOL.ORA. Each parameter begins with the prefix "DCE." to distinguish it from parameters relevant to other protocols. If default values are used for these four parameters, DCE Integration does not require a PROTOCOL.ORA file. The parameters and their current defaults are as follows:

DCE.AUTHENTICATION=dce_secret
DCE.PROTECTION=pkt_integ
DCE.TNS_ADDRESS_OID=1.3.22.1.5.1
DCE.LOCAL_CELL_USERNAMES=TRUE
Note:

The default for DCE.LOCAL_CELL_USERNAMES is now TRUE. (It was set to FALSE in the DCE Integration 2.1.6 release.)  

Configuration parameters are not case-sensitive: you can enter them in either upper-case or lower-case.

Note:

If the DCE.AUTHENTICATION entry is not specified, cell-wide default authentication is used.

If the DCE.PROTECTION entry is not specified, cell-wide default protection is used.  

DCE.AUTHENTICATION. This parameter is optional. It indicates the authentication value to be used for each DCE RPC. The client's DCE_AUTHENTICATION value must be the same as the server's DEC_AUTHENTICATION value. The choices are:

NONE: No authentication.

DCE_SECRET: DCE shared-secret key authentication (Kerberos).

DCE_SECRET: is the default authentication level.

DEFAULT: The cell default.

Note:

It is recommended that DCE_SECRET be used for this parameter.  

DCE.PROTECTION. This is an optional field. It specifies the data integrity protection levels for data transmission. The client's DCE_PROTECTION level must be equal to or greater than the server's DCE_PROTECTION level. The choices are:

NONE: Perform no protection for the current connection.

DEFAULT: Use the default cell-wide protection level.

CONNECT: Perform protection only when the client establishes a relationship with the server.

CALL: Perform protection only at the beginning of each remote procedure call when the server receives the request.

PKT: Ensure that all data received is from the expected client.

PKT_INTEG: Ensure and verify that none of the data transferred between the client and server has been modified.

PRIVACY: Perform protection as specified by all of the previous levels and also encrypt each RPC argument value and all user data in each call.

DCE.TNS_ADDRESS_OID. This optional parameter enables you to specify an alternative to the default DCE.TNS_ADDRESS_OID (shown below):

					DCE.TNS_ADDRESS_OID=1.3.22.1.x.x

For information on how to determine if you need to include this parameter, and how to specify it, see Section 11.6.2, "Modify the CDS Attributes File and Restart the CDS".

DCE.LOCAL_CELL_USERNAMES. This optional parameter defines the format used to specify the principal name (username) either with or without the cell name.

Note:

The choice you make for this parameter should be determined by whether users will be making connections across cells, and if so, whether you have naming conventions that assure that users in different cells do not have duplicate names.  

The choices are:

TRUE: This is the default. Choose TRUE when using just the SERVER_PRINCIPAL format, without the CELL_NAME. An example of a user specified in this format would be:

oracle

This choice would be appropriate if users are making connections within a single cell, or if naming conventions in your network assure that users in different cells do not have duplicate names.

FALSE: Choose FALSE when using the CELLNAME/SERVER_PRINCIPAL format. An example of a user specified in this format would be:

					CELL1/ORACLE

This choice would be appropriate if users are making connections across cells and there may be users in different cells with identical names.

11.6 Configuring Clients to Use the DCE CDS Naming Adapter

Clients will typically use CDS to resolve Oracle service names to addresses. Follow the instructions below to configure CDS.

11.6.1 Enable CDS for use in Performing Name Lookup

To use CDS for name resolution, the DCE Integration CDS Naming Adapter must be installed on all clients and servers that will use CDS. Also, the CDS namespace must have been configured for use by DCE Integration. (Refer to the DCE Integration installation instructions and to Section 10.4, "Configuring DCE CDS for Use by Oracle DCE Integration" for instructions on how to install and configure the CDS Naming Adapter.) For example, a service name such as "ORADCE" and its network address can be stored in DCE's CDS.

Typically, users can connect to Oracle services using the familiar Oracle service name (if there are no domains or the database is in the user's default domain): For example:

	sqlplus /@ORADCE

This example assumes that DCE externally-authenticated accounts are in use.

As an alternative name resolution service, you can use TNSNAMES.ORA files when CDS is inaccessible. To do this, you must locate names and addresses of all Oracle servers in the TNSNAMES.ORA file.

11.6.2 Modify the CDS Attributes File and Restart the CDS

On all DCE machines where the CDS naming adapter will be used, add the object ID for the CDS attribute TNS_Address to the CDS attributes file. (The object ID must be the same across all machines.)

  1. Add a line with the following format to the /opt/dcelocal/etc/cds_attributes file.
    	1.3.22.1.5.1    TNS_Address    char
    
    
    

    If the default TNS_Address OID (Object Identifier) value (1.3.22.1.5.1) already exists in the cds_attributes file, then you need to specify a value for the OID that is not already in use.

    Note:

    The first four digits of the TNS_Address attribute value (1.3.22.1.x.y) are fixed under DCE-naming conventions.  

  2. If you are unable to use the default value for the OID, you will need to specify the OID in the PROTOCOL.ORA file on the client.

    If you had to specify a value other than the default (1.3.22.1.5.1), then you need to add the following parameter to the PROTOCOL.ORA file:

    	DCE.TNS_ADDRESS_OID=1.3.22.1.x.y
    
    
    Note:

    Make sure that the OID value in the cds_attributes file matches the value specified in the DCE.TNS_ADDRESS_OID parameter in the PROTOCOL.ORA file.  

  3. Restart the CDS on the machine. (The command to restart CDS may vary from platform to platform. For example, on IBM AIX, you may use smit to restart the CDS.) The steps on IBM AIX are as follows:
    1. Type: smit DCE
    2. Choose Restart DCE/CDS Daemons
    3. Select List
    4. Select all CDS daemons available

    11.6.3 Create a TNSNAMES.ORA For Loading Oracle Connect Descriptors into CDS

    To load the Oracle service names and addresses into CDS, create or modify a TNSNAMES.ORA file containing service names (or aliases) and addresses. A sample TNSNAMES.ORA file is shown below. TNSNAMES.ORA is used to map service names to addresses for use by Net8.

    This section describes the parameters that the administrator needs to include in the TNSNAMES.ORA file. TNSNAMES.ORA contains a list of Oracle service names mapped to connect descriptors of destinations or endpoints in the network. The sample DCE address below shows a network address for an Oracle server with the Oracle service name "ORADCE". It is used to connect to the service registered as "DCE_SVC" in the CDS directory /.../<cell_name>/subsys/oracle/names.

    ORADCE=(DESCRIPTION=
    (ADDRESS=
    (PROTOCOL=DCE)
    (SERVER_PRINCIPAL=oracle)
    (CELL_NAME=cell1)
    (SERVICE=DCE_SVC))
    (CONNECT_DATA=
    (SID=ORASID)))
    Note:

    In this example, the Oracle service name and the DCE service name are different. However, they are often the same.  

    The keyword value pair PROTOCOL=DCE is mandatory. It appears in the address section of LISTENER.ORA and in the address section of TNSNAMES.ORA. It must be the same in both places.

    The DCE parameter SERVER_PRINCIPAL is optional in TNSNAMES.ORA.

    The DCE parameter SERVICE is mandatory. The value given for the DCE parameter (SERVICE= dce_service_name) must be the same in the LISTENER.ORA and TNSNAMES.ORA files.

    The Oracle parameter SID is mandatory. It identifies the Oracle system ID; each SID value must be unique on a node. This parameter is strictly local and is not used in DCE CDS. For further information on TNSNAMES.ORA, refer to Net8 Administrator's Guide.

    11.6.4 Load Oracle Connect Descriptors into CDS

    A separate utility called "tnnfg" is provided with Oracle DCE Integration to load connect descriptors into CDS.

    To load the Oracle service names or aliases into CDS, perform the following steps:

    	% dce_login cell_admin
    	% tnnfg dceload full_pathname_to_TNSNAMES.ORA
    % Enter Password:  (password will not display)
    
    
    Note:

    You must enter the full pathname for the TNSNAMES.ORA file in the previous command.

    Also make sure that the SQLNET.ORA file exists in the same directory as the TNSNAMES.ORA file.  

    This procedure loads the service names in TNSNAMES.ORA into DCE's CDS.

    Note:

    If you configure a new service name and address in TNSNAMES.ORA, tnnfg will add the new service name and address to CDS.

    If you change the address for a particular service name, tnnfg will update the address for a particular service name.  

    11.6.5 Delete or Rename TNSNAMES.ORA File

    If you are using SQL*Net 2.2 or earlier, after having loaded the TNSNAMES.ORA file into DCE's CDS, it is recommended that you rename it to another name-TNSNAMES.BAK, for example. or delete it. Otherwise, TNSNAMES.ORA may be searched instead of CDS to resolve the service name to an address.

    If you are using SQL*Net 2.3 or Net8, you can keep TNSNAMES.ORA available as a backup in case CDS becomes unavailable. To assure that CDS will routinely be searched instead of TNSNAMES.ORA, configure the NAMES.DIRECTORY_PATH parameter in the SQLNET.ORA file, as described in Section 11.6.6, "Modify SQLNET.ORA Parameter File to Have Names Resolved in CDS".

    11.6.6 Modify SQLNET.ORA Parameter File to Have Names Resolved in CDS

    The parameters required in SQLNET.ORA depend upon the version of SQL*Net or Net8 you are using.

    11.6.6.1 SQL*Net Release 2.2 or Earlier

    For a client or server to use the DCE CDS Naming Adapter, the administrator needs to do the following:

    • make sure that the CDS Naming Adapter has been installed on that node
    • add the following two parameters and values to SQLNET.ORA:
      		native_names.use_native=true
      native_names.directory_path=(dce)

    After these parameters are added to the SQLNET.ORA file, the client's or server's name requests will be resolved in CDS instead of by a local TNSNAMES.ORA file.

    Note:

    A client or server can use CDS to reach services on a network even if some of those services are not also using CDS.  

    11.6.6.2 SQL*Net Release 2.3 and Later

    For a client or server to use the DCE CDS Naming Adapter, the administrator needs to do the following:

    • make sure that the CDS Naming Adapter has been installed on that node
    • add the following parameter to the SQLNET.ORA file:
      		NAMES.DIRECTORY_PATH=(dce, tnsnames, onames)
      
      

    The first name resolution service listed as a value for this parameter is used. If it is unavailable for some reason, the next name resolution service is used, and so forth.

    11.6.7 Connect to Oracle Servers in DCE

    For information on how to connect to Oracle databases in a DCE environment, see Chapter 12, "Connecting to an Oracle Database in DCE".




Prev

Next
Oracle
Copyright © 1997 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index