Skip Headers

Oracle® Database Advanced Security Administrator's Guide
10g Release 1 (10.1)
Part Number B10772-01
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Feedback
Go to previous page
Previous		 Go to next page
Next
 View PDF

12
Enterprise User Security Configuration Tasks and Troubleshooting

This chapter describes the sequence of steps involved to configure Enterprise User Security from the initial database and directory preparation through connecting to the database as either a password-, Kerberos-, or SSL-authenticated enterprise user. In addition, a troubleshooting section is also included that will help you when testing your Enterprise User Security implementation.

This chapter contains the following topics:

Enterprise User Security Configuration Overview

Configuring Enterprise User Security essentially consists of creating shared schemas and global roles in databases that you want to be accessible to enterprise users. Then you configure the identity management realm in the directory to reflect those database roles and schemas, and, finally, associate directory users with them. Regardless of the authentication method you choose--password, SSL, or Kerberos--you must still create the global database objects and configure the identity management realm as described.

The primary difference between configuration for the various authentication types lies with network connection configuration. You must consider the following three connections:

Enterprise User Security supports many combinations of authentication types between databases, directories, and clients. The three most common implementations of Enterprise User Security, which will be described in this chapter, use the following authentication methods for client/database and database/directory connections:

Primarily, your network environment--whether all clients, databases, and directories reside within the same network behind a firewall, or are distributed across several networks and perhaps exposed to the Internet--determines what authentication type you choose for Enterprise User Security network connections. Security and integrity of enterprise data depend on secure network connections.

Secondarily, the configuration complexity, additional software, and ongoing maintenance required by more rigorous authentication types, such as SSL and Kerberos, should also be considered when choosing which "flavor" of Enterprise User Security to use.

Figure 12-1 shows the configuration process for Enterprise User Security. It is a step-by-step process with decision points based on your implementation and how your users are authenticated. Note that the steps which are represented with broken lines are optional steps in the configuration process.

Figure 12-1 Enterprise User Security Configuration Flow Chart

Text description of asoag034.gif follows

Text description of the illustration asoag034.gif

For brevity, some product names and features have been abbreviated in this flow chart. The following table lists the abbreviations used and their corresponding meaning:

Abbreviation Meaning

DBCA

Database Configuration Assistant

ESM

Enterprise Security Manager

IM Realm

Identity Management Realm

Netmgr

Oracle Net Manager

ODM

Oracle Directory Manager

OID

Oracle Internet Directory

OWM

Oracle Wallet Manager

SQL

SQL*Plus

See Also:

Chapter 11, "Getting Started with Enterprise User Security" for information about the realm Oracle Context, its administrative groups, and entries that pertain to Enterprise User Security.

Enterprise User Security Configuration Roadmap

The rest of this section provides detailed descriptions of these configuration steps, which should be performed in the following order:

  1. "Preparing the Directory for Enterprise User Security"
  2. "Configuring Enterprise User Security Objects in the Database and the Directory"
  3. Complete your Enterprise User Security configuration by performing the steps necessary for your authentication method:

Preparing the Directory for Enterprise User Security

This is the first phase in configuring Enterprise User Security and must be performed before you can configure any other part of this feature.

Enterprise User Security, 10g Release 1 (10.1) requires Oracle Internet Directory, Release 9.0.4, or later, which installs with the required version of the Oracle schema. This schema is backward compatible. After you have installed Oracle Internet Directory, perform the following directory usage configuration tasks:

Task 1: (Optional) Create an identity management realm in the directory

If necessary, use Oracle Internet Directory Self-Service Console (Delegated Administration Service) to create an identity management realm in the directory. You can also use this tool to upgrade an Oracle9i Oracle Context to a 9.0.4 version Identity Management Realm.

You must have a version 9.0.4 identity management realm to use an Oracle Database 10g. Version 9.0.4 realms are backward compatible to Oracle9i, so you can register Oracle9i and version 10g Oracle Databases in the same realm and place them in the same domain, if desired.

Task 2: (Optional) Set identity management realm properties

If you do not want to use the default settings, then use Enterprise Security Manager Console to set the user search base, group search base, attribute for login name (nickname attribute), and to set up the necessary context administrators in the identity management realm you plan to use in the directory. To perform this task, see "Setting Properties of an Identity Management Realm".

Note:

By default in a version 9.0.4 identity management realm, the user search base is set to cn=Users,cn=realm_name, the group search base is set to cn=Groups,cn=realm_name, and the attribute for login name is set to the user's id (uid). In previous releases, this used to be cn.

Task 3: Identity administrative users in the directory

Identify administrative users in the directory who are authorized to perform the following tasks:

If administrative users do not already exist who can perform these tasks, then see Chapter 13, "Administering Enterprise User Security" to create them.

Note:

Although one administrator can perform all Enterprise User Security administrative tasks, you can create many different kinds of administrators so security tasks can be assigned to different people. Separating security tasks in this way results in a more secure enterprise environment, but requires coordination between the different administrators.

Task 4: (Optional) Set the default database-to-directory authentication type for the identity management realm

By default, the identity management realm database-to-directory authentication type is set to passwords. If you do not want to use this default setting, then use Enterprise Security Manager to change it. For example, if you are using a public key infrastructure (PKI), then you would need to set this to SSL. See "Setting the Default Database-to-Directory Authentication Type for an Identity Management Realm".

Note:
  • This default realm-wide setting can be overridden on a database by setting the LDAP_DIRECTORY_ACCESS initialization parameter. See Oracle Database Reference for more information about this parameter.
  • If you are using SSL, then see Oracle Internet Directory Administrator's Guide for information about setting up SSL with two-way authentication for Oracle Internet Directory.
Task 5: (Optional) Configure your Oracle home for directory usage

If you use Domain Name System (DNS) discovery (automatic domain name lookup) to locate the directory on your network, then this step is not necessary. (See Oracle Internet Directory Administrator's Guide for information about DNS server discovery.) If you are not using DNS discovery, then you must use Oracle Net Configuration Assistant to create an ldap.ora file for your Oracle home. This configuration file specifies the directory host and port information, and the location of the identity management realm so the database can connect to the directory. (See "Starting Oracle Net Configuration Assistant")

To create an ldap.ora file for your Oracle home:
  1. In the Oracle Net Configuration Assistant welcome page, choose Directory Service Usage Configuration, and click Next.
  2. Select one of the options on the Directory Usage Configuration page that is appropriate for your environment. Then follow the prompts in the wizard and refer to the online help to create an ldap.ora file for your Oracle home.

    Note:
    • If you are using SSL authentication for your database-to-directory connection, then the SSL port entered in the ldap.ora file must support two-way authentication. This requires a PKI digital certificate and wallet for Oracle Internet Directory.
    • If you are using password authentication for your database-to-directory connection, then the SSL port entered in the ldap.ora file must support SSL with no authentication. (The directory SSL port on which the Diffie-Hellman-based SSL server is running.) This does not require a wallet or certificate for Oracle Internet Directory.
Task 6: Register the database in the directory

After you have configured your Oracle home for directory usage, use Database Configuration Assistant to register the database in the directory. Registration creates an entry in the directory so the database can bind, or log in, to it.

When a database is registered in the directory, Database Configuration Assistant performs the following configuration tasks:

You must be a member of the OracleDBCreators group, the OracleContextAdmins group, or you must be the directory superuser to perform this task.

To register a database in the directory:
  1. See "Starting Database Configuration Assistant" to start this tool.
  2. After starting Database Configuration Assistant, select Configure database options in a database and choose Next.
  3. Select a database and choose Next.
  4. Choose Yes, Register the Database. Enter the directory credentials for a user in the OracleDBCreators group.
  5. Enter a password for the database wallet.

    Note:

    Remember the database wallet password you entered in Step 5. It cannot be retrieved after you finish database registration, but can be changed later by using Oracle Wallet Manager. See "About the Database Wallet and Password" for further information about this database wallet.

  1. Choose Finish if you are only registering a database. Choose Next if you want to configure additional database features.
To change the database's directory password:
  1. After starting Database Configuration Assistant, select Configure database options in a database, and choose Next.
  2. Select a database and choose Next.
  3. Choose Regenerate database password.
  4. Choose Finish if you are only registering a database. Choose Next if you want to configure additional database features.
To cancel database registration:
Note:

Depending on user permissions, Database Configuration Assistant may be unable to remove a database from its domain in the directory. If it cannot, then use Enterprise Security Manager to remove it from the enterprise domain.

If you must unregister a database from the directory, then use Database Configuration Assistant and follow the same steps used for registering it, except choose the unregister option. When you unregister a database from the directory, Database Configuration Assistant performs the following configuration tasks:

About the Database Wallet and Password

The database requires the wallet even if no SSL (Secure Sockets Layer) is used to secure the connection between the database and the directory. If SSL is used, then this wallet should be used to store the database's digital PKI certificate.

The wallet password you enter when using Database Configuration Assistant to register a database in the directory is the password to the wallet itself, and is not the database's directory login credentials.

You can change this wallet password later by using Oracle Wallet Manager. However, if you forget this wallet password, you must delete the database wallet that was created, unregister the database from the directory, and reregister the database in the directory so another database wallet can be generated.

See Also:

Chapter 8, "Using Oracle Wallet Manager" for information about using Oracle Wallet Manager to change wallet passwords and, in general, to manage public key infrastructure (PKI) credentials.

After you have prepared the directory for Enterprise User Security, then you can create the Enterprise User Security database and directory objects as described in "Configuring Enterprise User Security Objects in the Database and the Directory".

See Also:

Configuring Enterprise User Security Objects in the Database and the Directory

This is the second phase of configuration steps required to implement Enterprise User Security. The configuration steps in this section assume the following recommended setup:

Note that databases must be in an enterprise domain that is in an identity management realm in order for enterprise user logins to work.

If you do not use the OracleDefaultDomain or store your users in an identity management realm Users subtree, then see the following documentation:
  • Oracle Internet Directory Administrator's Guide for information about creating a new identity management realm or modifying an existing one, and for information about setting access control lists on directory objects.
  • "Creating a New Enterprise Domain" to create another domain in which to put your database. Then substitute your new domain name for OracleDefaultDomain in the following configuration steps.

To configure Enterprise User Security objects in the database and directory perform the following tasks:

Task 1: Create Global Schemas and Global Roles in the Database

Although this step can also be completed by using Oracle Enterprise Manager, the following examples use SQL*Plus directly:

  1. Create a shared schema for enterprise users. The following syntax example creates a shared schema named guest: 
    SQL> CREATE USER guest IDENTIFIED GLOBALLY AS '';

    If you do not want to use a shared schema, then specify a user DN between the single quotation marks to create an exclusive schema.

  2. Grant the CREATE SESSION privilege to the shared schema created in Step 1 so users can connect to it. The following syntax example grants the CREATE SESSION privilege to the guest shared schema: 
    SQL> GRANT CREATE SESSION TO guest;

    Alternatively, you can grant the CREATE SESSION privilege to a global role, which you grant to specific users through an enterprise role. See Step 3.

  3. Create global roles for the database to hold relevant privileges. The following syntax examples create the emprole and custrole global roles: 
    SQL> CREATE ROLE emprole IDENTIFIED GLOBALLY;
SQL> CREATE ROLE custrole IDENTIFIED GLOBALLY;

    Global roles are associated with enterprise roles, which will be created later, and then are allocated to enterprise users.

  4. Grant privileges to the new global roles that were created in Step 3. The following syntax example grants the SELECT privilege to emprole and custrole global roles on the products table: 
    SQL> GRANT select ON products TO custrole, emprole;
    See Also:

    Oracle Database SQL Reference for information about the syntax used for these steps.

Task 2: Configure User-Schema Mappings for the Enterprise Domain

Use Enterprise Security Manager (see "Starting Enterprise Security Manager") to configure user-schema mappings for the OracleDefaultDomain by using the following steps:

  1. Select the OracleDefaultDomain in the navigator pane.
  2. Choose the Database Schema Mapping tabbed window and click Add....
  3. In the Add Database Schema Mappings dialog box enter the appropriate DN and the shared schema name that you created in Task 1 . Refer to the Enterprise Security Manager online help for information about how to enter these values.
  4. Choose OK. The new user-schema mappings apply to all databases in the enterprise domain.

For more information about this task, see "Managing Enterprise Domain Database Schema Mappings".

Note:

You also can create user-schema mappings under a database in an enterprise domain which only apply to that database.

Task 3: Create Enterprise Roles in the Enterprise Domain

Use Enterprise Security Manager to create enterprise roles in the OracleDefaultDomain by using the following steps:

  1. Right-click the OracleDefaultDomain in the navigator pane and choose Create Enterprise Role....

    The Create Enterprise Role dialog box appears with the appropriate realm Oracle Context and enterprise domain displayed.

  2. Enter the enterprise role name in the Role Name field.
  3. Click OK. The new enterprise role is added under the domain in the navigator pane.

For more information about this task, see "Creating a New Enterprise Role".

Task 4: Add Global Database Roles to Enterprise Roles

Use Enterprise Security Manager to add the global database roles that you created in Task 1 to the enterprise roles that you created in Task 3 by using the following steps:

  1. Select the enterprise role name in the navigator pane.
  2. Choose the Database Global Roles tabbed window and click Add....
  3. In the Add Global Database Roles dialog box, select the database from which to obtain global roles. A database logon window appears, prompting you for a username and password to authenticate to the database so global roles can be fetched. Typically, this is a DBA logon to the database.

    Note:

    You can use the database name that appears by default in the Service field to connect to the database if your Oracle home has LDAP as one of its selected Oracle Net naming methods, or if this name appears as a TNS alias in your local Oracle Net configuration. Otherwise, you can overwrite the Service field with any other TNS alias (from the database tnsnames.ora file), or by using a connect string in the following format:

    <host>:<port>:<oracle_SID>

    For example: machine111:1521:sales_db

  1. Click OK. Enterprise Security Manager connects to the selected database, fetches the global roles supported on that database, and displays them in the Add Global Database Roles dialog box.
  2. Select one or more global roles and click OK. The selected global roles appear in the Database Global Roles window.
  3. Click Apply. The new global roles are added to the enterprise role.

For more information about this task, see "Assigning Database Global Role Membership to an Enterprise Role".

Task 5: Grant Enterprise Roles to Enterprise Users for Database Access

Use Enterprise Security Manager to grant enterprise roles that you created in Task 3 to the enterprise users by using the following steps:

  1. In the navigator pane, select an enterprise role in the appropriate identity management realm.
  2. Select the Users tab adjacent to the main application window and click Add....
  3. In the Add Enterprise Users dialog box top panel, select a directory entry as a user search base, or edit the Selection field to manually define the user search base.
  4. In the middle Search Criteria panel, check Include Subtrees to enable searching for all users within the search, including subtrees.
  5. Enter any known user name in the Show Names Containing field. This limits the search to users in the directory who have a common name value that contains or starts with the specified text.
  6. Click Search Now. If there are any users in the directory that match your search criteria, then they are listed in the bottom panel.
  7. Choose a desired user by selecting the user in the bottom panel and clicking OK, or by double-clicking the user. Multiple users can be granted the enterprise role by selecting a range of users and clicking OK.

    The Add Enterprise Users dialog box automatically closes and you are returned to the main application window.

  8. The user names you added appear in the Users tab. Click Apply to grant the enterprise role to the users.

For more information about this task, see "Granting Enterprise Roles to Users".

Task 6: Configure Enterprise User Security for the Authentication Method You Require

Based on the authentication method you have chosen, go to one of the following sections to complete your Enterprise User Security configuration:

Configuring Enterprise User Security for Password Authentication

By default, new enterprise domains are configured to accept all supported user authentication types (password, Kerberos, and SSL). If you want enterprise users to be authenticated by passwords, then you must configure that as described in the following tasks.

The configuration steps in this section assume the following:

To configure Enterprise User Security for password authentication, perform the following tasks:

Task 1: (Optional) Enable the Enterprise Domain to Accept Password Authentication

By default, the OracleDefaultDomain is configured to accept password authentication. If this has been changed, then use Enterprise Security Manager to enable password authentication for the OracleDefaultDomain and add it to the Password-Accessible Domains List by using the following steps:

  1. Select the OracleDefaultDomain in the navigator pane.
  2. Choose the Databases tabbed window and select Password or All Types from the User Authentication methods listed.
  3. Click Apply.
  4. Select the identity management realm in the navigator pane.
  5. Choose the Accessible Domains tabbed window and click Add.
  6. In the Add Accessible Enterprise Domains dialog box, select the OracleDefaultDomain from the list of enterprise domains, and click OK. The OracleDefaultDomain is added to the password-accessible domains list.

For more information about this task, see "Managing Password Accessible Domains".

Task 2: Add the Enterprise Domain to the Password-Accessible Domains List

Use Enterprise Security Manager to add the OracleDefaultDomain to the Password-Accessible Domains List by using the following steps:

  1. Select the identity management realm in the navigator pane.
  2. Choose the Accessible Domains tabbed window and click Add.
  3. In the Add Accessible Enterprise Domains dialog box, select the OracleDefaultDomain from the list of enterprise domains, and click OK. The OracleDefaultDomain is added to the password-accessible domains list.

For more information about this task, see "Managing Password Accessible Domains".

Task 3: Connect as a Password-Authenticated Enterprise User

For an enterprise user whose directory login name is hscortea and whose password is welcome, enter the following to connect to the database by using SQL*Plus:

SQL> connect hscortea/welcome@<Oracle Net Service Name>

The database authenticates the enterprise user (hscortea) by verifying the username/password combination against the directory entry associated with this user. Then it identifies the proper schema and retrieves the user's global roles. If successful, the connection to the database is established.

If your connection succeeds, then the system responds Connected to:.... This is the confirmation message of a successful connect and setup. If an error message displays, then see "ORA-# Errors for Password-Authenticated Enterprise Users".

If you do connect successfully, then check that the appropriate global roles were retrieved from the directory by entering the following at the SQL*Plus prompt:

select * from session_roles

If the global roles were not retrieved from the directory, then see "NO-GLOBAL-ROLES Checklist".

You have completed password-authenticated Enterprise User Security configuration.

See Also:

Configuring Enterprise User Security for Kerberos Authentication

The configuration steps in this section assume the following:

To configure Enterprise User Security for Kerberos authentication, perform the following tasks:

Task 1: Configure the Enterprise Security Manager Console to display the Kerberos principal name attribute

Use Oracle Internet Directory Self-Service Console to configure the Enterprise Security Manager Console to display the Kerberos principal name attribute. For more information about this task, see "Configuring Enterprise Security Manager Console for Kerberos-Authenticated Enterprise Users".

Task 2: (Optional) Configure the Kerberos Principal Name Directory Attribute for the Identity Management Realm

Use Enterprise Security Manager Console to enter the directory attribute used to store the Kerberos principal name for the identity management realm you are using in the directory. By default Kerberos principal names are stored in the krbPrincipalName attribute, but can be changed to correspond to your directory configuration by changing orclCommonKrbPrincipalAttribute in the identity management realm. For more information about this task, see "Setting Login Name, Kerberos Principal Name, User Search Base, and Group Search Base Identity Management Realm Attributes".

Note:

By default, Enterprise Security Manager Console user interface does not display the field where you can configure Kerberos principal names. The first time you create Kerberos-authenticated users in the directory, you must configure the console to display the krbPrincipalName attribute in its Create User window. See "Configuring Enterprise Security Manager Console for Kerberos-Authenticated Enterprise Users" for details.

Task 3: Specify the Enterprise User's Kerberos Principal Name in the krbPrincipalName Attribute

Use Enterprise Security Manager Console to specify the enterprise user's Kerberos principal name (Kerberos_username@Kerberos_realm) in the krbPrincipalName attribute of the enterprise user's directory entry. For more information about this task, see "Creating New Enterprise Users".

Task 4: (Optional) Enable the Enterprise Domain to Accept Kerberos Authentication

By default, the OracleDefaultDomain is configured to accept all types of authentication. If this has been changed, or you are using another domain then use Enterprise Security Manager to enable Kerberos authentication for your enterprise domain by using the following steps:

  1. Select the enterprise domain in the navigator pane.
  2. Choose the Databases tabbed window and select Kerberos or All Types from the User Authentication methods listed.
  3. Click Apply.

For more information about this task, see "Managing Database Security Options for an Enterprise Domain".

Task 5: Connect as a Kerberos-Authenticated Enterprise User

If the KDC is not part of the operating system, such as Kerberos V5 from MIT, then the user must get an initial ticket with the FORWARDABLE flag set by using the okinit utility. See "Obtaining the Initial Ticket with the okinit Utility".

If the KDC is part of the operating system, such as Windows 2000 or some versions of Linux or UNIX, then the operating system automatically picks up the user's ticket (with the FORWARDABLE flag set) from the cache when the user logs in.

The user connects to the database by launching SQL*Plus and entering the following at the command line:

SQL> connect /@<net_service_name>

The database uses Kerberos to authenticate the user. The database authenticates itself to the directory by password.

If your connection succeeds, then the system responds Connected to:.... This is the confirmation message of a successful connect and setup. If an error message displays, then see "ORA-# Errors for Kerberos-Authenticated Enterprise Users".

If you do connect successfully, then check that the appropriate global roles were retrieved from the directory by entering the following at the SQL*Plus prompt:

select * from session_roles

If the global roles were not retrieved from the directory, then see "NO-GLOBAL-ROLES Checklist".

You have completed Kerberos-authenticated Enterprise User Security configuration.

See Also:

Configuring Enterprise User Security for SSL Authentication

The configuration steps in this section assume the following:

To configure Enterprise User Security for SSL authentication, perform the following tasks:

Task 1: Enable the Enterprise Domain to Accept SSL Authentication

Use Enterprise Security Manager to enable SSL authentication for the enterprise domain (OracleDefaultDomain) by using the following steps:

  1. Select the enterprise domain in the navigator pane.
  2. Choose the Databases tabbed window and select Oracle Wallet (SSL) or All Types from the User Authentication methods listed.
  3. Click Apply.

For more information about this task, see "Managing Database Security Options for an Enterprise Domain".

Task 2: Set the LDAP_DIRECTORY_ACCESS Initialization Parameter to SSL

You can change this initialization parameter either by editing your database initialization parameter file, or by issuing an ALTER SYSTEM SQL command with the SET clause.

For example, the following ALTER SYSTEM command changes the LDAP_DIRECTORY_ACCESS parameter value to SSL in the server parameter file:

ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS=SSL SCOPE=SPFILE
See Also:
Task 3: Connect as an SSL-Authenticated Enterprise User

Connecting as an SSL-authenticated enterprise user involves ensuring that you have the appropriate Oracle wallet features configured, and that you do not have a wallet location specified in the client sqlnet.ora file. If the client sqlnet.ora file contains a wallet location, then multiple users cannot share that file. Only the server sqlnet.ora file must have a value for the wallet location parameter.

To connect as an SSL-authentication enterprise user, perform the following steps:

  1. Use Oracle Wallet Manager to download a user wallet from the directory. See "Downloading a Wallet from an LDAP Directory".
  2. Use Oracle Wallet Manager to enable auto login for the user wallet. Enabling auto login generates a single sign-on (.sso) file and enables authentication to the SSL adapter. See "Using Auto Login".
  3. Set the TNS_ADMIN environment variable (to point to the client's sqlnet.ora file) for the client if the client Oracle home points to a server Oracle home. (Because a server must have a wallet location set in its sqlnet.ora file and a client cannot have a wallet location specified there, the server and client cannot share sqlnet.ora files.)

    If you have a separate client Oracle home, then you do not need to set the TNS_ADMIN environment variable.

  4. Launch SQL*Plus and enter the following at the command line: 
    SQL> /@connect_identifier

    where connect_identifer is the Oracle Net service name you set up when you configured SSL for the database client.

    If your connection succeeds, then the system responds Connected to:.... This is the confirmation message of a successful connect and setup. If an error message displays, then see "ORA-# Errors for SSL-Authenticated Enterprise Users".

    If you do connect successfully, then check that the appropriate global roles were retrieved from the directory by entering the following at the SQL*Plus prompt:

    select * from session_roles

    If the global roles were not retrieved from the directory, then see "NO-GLOBAL-ROLES Checklist".

You have completed SSL-authenticated Enterprise User Security configuration.

Note:

For security purposes, ensure that you disable auto login for the user wallet after logging out from the enterprise user session with the database. This is especially important if the client machine is shared by more than one user. See "Disabling Auto Login" for information about disabling this Oracle Wallet feature.

Viewing the Database DN in the Wallet and in the Directory

For SSL-authenticated Enterprise User Security to work, the database DNs in the database wallet, the database directory entry, and the database certificate must be identical. When you use Database Configuration Assistant to register your database in the directory, this tool automatically creates identical DNs for the database wallet and the database directory entry. To request a database certificate with the proper DN, you must view either the directory entry DN or the wallet DN.

To view the database DN so you can request a certificate with the appropriate DN use one of the following options:

Enabling Current User Database Links

Current user database links require SSL-enabled network connections between the databases. Before you can enable current user database links, you must enable SSL, create Oracle wallets, and obtain PKI credentials for all databases involved.

Then use Enterprise Security Manager to enable current user database links between databases within the enterprise domain in the directory by using the following steps:

  1. Select the enterprise domain in the navigator pane.
  2. Choose the Databases tabbed window and check Enable Current User Database Links.
  3. Click Apply.

For more information about this task, see "Managing Database Security Options for an Enterprise Domain".

Troubleshooting Enterprise User Security

This section describes potential problems and associated corrective actions in the following topics:

ORA-# Errors for Password-Authenticated Enterprise Users

If you receive an ORA-# error while using password-authenticated Enterprise User Security, then locate the error in the following section and take the recommended action.


ORA-1017: Invalid username/password; login denied

Action: See "USER-SCHEMA ERROR Checklist"


ORA-28030: Problem accessing LDAP directory service

Cause: Indicates a problem with the connection between the database and the directory.

Action: Check the following:

  1. Check that there is a correct wallet_location value in the database's sqlnet.ora file. If not, then use Oracle Net Manager to enter one.
  2. If Domain Name System (DNS) server discovery of Oracle Internet Directory is not used, check that there is a correct ldap.ora file in $LDAP_ADMIN, $ORACLE_HOME/ldap/admin, $TNS_ADMIN, or $ORACLE_HOME/network/admin. (See Oracle Internet Directory Administrator's Guide for information about DNS server discovery.)
  3. Check that the SSL port used (by way of either DNS discovery or an ldap.ora file) supports SSL with no authentication.
  4. Check that the LDAP_DIRECTORY_ACCESS parameter is set to PASSWORD in the database initialization parameters file.
  5. Use Database Configuration Assistant to reset the database password used to authenticate the database to Oracle Internet Directory. This resets it both locally in the database wallet, and remotely in the database entry in Oracle Internet Directory.
  6. Check that the database wallet has auto login enabled. Either use Oracle Wallet Manager, or check that there is a cwallet.sso file in $ORACLE_HOME/admin/<ORACLE_SID>/wallet/.
  7. Use the password stored in the database wallet to check that the database can bind to Oracle Internet Directory:
    • Use the mkstore command line utility to retrieve the database password from the wallet by using the following syntax: 
      mkstore -wrl <database wallet location> -viewEntry 
ORACLE.SECURITY.PASSWORD
    • Use the password returned from mkstore in the following ldapbind: 
      ldapbind -h <directory host> -p <non-SSL directory port> -D 
"<database DN>" -w <password returned by mkstore>
  8. Check to ensure the database belongs to only one enterprise domain.

    Note:

    The mkstore utility is for troubleshooting purposes only. The name and functionality of this tool may change in the future. In 10g Release 1 (10.1), Oracle supports only the viewEntry mode.


ORA-28271: No permission to read user entry in LDAP directory service

Action: Check the following:

  1. Use Enterprise Security Manager to check that a user search base containing this user is listed in the user search base attribute of the realm that you are using.
  2. Check the ACL on the User Search Base in Oracle Internet Directory to ensure that the verifierServices group has read permission on the user entry, and that this permission is not prevented by an ACL between the User Search Base entry and the user entry in the directory tree.
  3. Check that the enterprise domain is in the password-accessible domains group for that realm Oracle Context.

ORA-28272: Domain policy does not allow password-authenticated GLOBAL users

Action: Use Enterprise Security Manager to set the user authentication policy for this enterprise domain to Password or ALL.


ORA-28273: No mapping for user login name to LDAP distinguished name exists

Action: Check the following:

  1. Check that a user entry exists in Oracle Internet Directory for your user.
  2. Use Enterprise Security Manager to check that a user search base containing this user is listed in the identity management realm that you are using.
  3. Check that the user entry contains the right login name:
    • Use Enterprise Security Manager Console to find the login name attribute that is configured for the directory in your realm, and
    • Check that the name provided during the attempted user database login is the value for that attribute in the user directory entry.
  4. If you have an exclusive schema for the global user in the database, then check that the DN in the database matches the DN of the user entry in Oracle Internet Directory.

ORA-28274: No ORACLE password attribute corresponding to user login name exists

Action: Check the following:

  1. Check that the user entry in the directory has the orcluser object class. If it does not, then perform the following steps:
    • Use Oracle Internet Directory Self-Service Console to check that the default object classes for new user creation include orcluser, and then
    • Use Enterprise Security Manager Console or Oracle Internet Directory Self-Service Console to re-create the user, or
    • Add the orcluser and the orcluserV2 object classes.
  2. Check that there is a value for the attribute orclpassword in the user entry. If there is no value, then reset the user's directory password (userpassword attribute). This should prompt Oracle Internet Directory to regenerate the database password verifier for the user.
  3. Use Enterprise Security Manager to check that the user search base containing this user is listed in the user search base attribute of the realm that you are using.
  4. Use Enterprise Security Manager to check that the enterprise domain is in the password accessible domains group.
  5. Check that the ACL on the user search base attribute allows read and search access to the orclpassword attributes by the verifierServices group. This is set properly by default, but may have been altered.

ORA-28275: Multiple mappings for user login name to LDAP distinguished name exist

Cause: There are multiple user DNs in the directory within the user search base whose login name for the user matches what was provided during the database connection.

Action: Use Enterprise Security Manager Console to make the login name value unique (no two users share the same login name) within all user search bases associated with the realm Oracle Context.


ORA-28277: LDAP search, while authenticating global user with passwords, failed

Action: Check that the relevant directory instance is up and running.


ORA-28278: No domain policy registered for password-based GLOBAL users

Cause: The database cannot read the enterprise domain information that it needs.

Action: See "DOMAIN-READ-ERROR Checklist"


ORA-28862: SSL handshake failed

Action: Check that you are using a non-SSL connect string.

ORA-# Errors for Kerberos-Authenticated Enterprise Users

If you receive an ORA-# error while using Kerberos-authenticated Enterprise User Security, then locate the error in the following section and take the recommended action.


ORA-1017: Invalid username/password; login denied

Action: See "USER-SCHEMA ERROR Checklist"


ORA-28030: Problem accessing LDAP directory service

Cause: Indicates a problem with the connection between the database and the directory.

Action: See the actions listed for resolving "ORA-28030: Problem accessing LDAP directory service" in the troubleshooting section for password-authenticated enterprise users.


ORA-28271: No permission to read user entry in LDAP directory service

Action: See the actions listed for resolving "ORA-28271: No permission to read user entry in LDAP directory service" in the troubleshooting section for password-authenticated enterprise users.


ORA-28292: No domain policy registered for Kerberos-based authentication

Action: Perform the following actions:

  1. Use Enterprise Security Manager to set the user authentication policy for this enterprise domain to KERBEROS or ALL.
  2. See "DOMAIN-READ-ERROR Checklist"

ORA-28290: Multiple entries found for the same Kerberos principal name

Cause: The Kerberos principal name for this user is not unique within the user search base containing this user.

Action: Use Oracle Internet Directory Self-Service Console to change the Kerberos principal name, or to change the other copies so that it is unique.


ORA-28291: No Kerberos principal value found

Action: Check the following:

  1. Check that the user entry in the directory has the krbprincipalname attribute.

    If it does not have the krbprincipalname attribute, then check the following:

    • Check that the default attributes for new user creation by using Oracle Internet Directory Self-Service Console include krbprincipalname, and then
    • Use Enterprise Security Manager Console or Oracle Internet Directory Self-Service Console to create the user again, or
    • Add the orclcommonattributes object class.
  2. Check that there is a value for the attribute krbprincipalname in the user entry. If there is no value, then use Oracle Internet Directory Self-Service Console to enter one.
  3. Use Enterprise Security Manager to check that the user search base containing this user is listed in the realm Oracle Context that you are using.
  4. Check that the ACL on the user search base attribute allows read and search access to the krbprincipalname attributes by the verifierServices group. This is set properly by default, but may have been altered.

ORA-28293: No matched Kerberos principal found in any user entry.

Action: Check the following:

  1. Check that a user entry exists in Oracle Internet Directory for your user.
  2. Use Enterprise Security Manager or ldapsearch to check that a user search base containing this user is listed in the identity management realm that you are using.
  3. Check that the user entry in the directory contains the correct Kerberos principal name by using the following steps:
    • Use Enterprise Security Manager Console to find the Kerberos principal name attribute that is configured for the directory in your realm, and
    • Check that the correct Kerberos principal name appears in that attribute in the user's directory entry.
  4. If you have an exclusive schema for the global user in the database, check that the DN in the database matches the DN of the user entry in Oracle Internet Directory.

ORA-28300: No permission to read user entry in LDAP directory service

Action: Check that the database wallet contains the correct credentials for the database-to-directory connection. The wallet DN should be the DN of the database in Oracle Internet Directory. To retrieve the credentials, perform the following steps:

  1. Use the mkstore command line utility to retrieve the database password for the wallet by using the following syntax: 
    mkstore -wrl <database wallet location> -viewEntry 
ORACLE.SECURITY.PASSWORD -viewEntry ORACLE.SECURITY.DN
  2. If these values are incorrect, reset the database wallet by using Database Configuration Assistant.
  3. Use the DN and the password returned by mkstore in the following ldapbind: 
    ldapbind -h <directory host> -p <non-SSL directory port> -D "<database 
DN>" -w <password>
    Note:

    The mkstore utility is for troubleshooting purposes only. The name and functionality of this tool may change in the future. In 10g Release 1 (10.1), Oracle supports only the viewEntry mode.


ORA-28302: User does not exist in the LDAP directory service

Action: Check that the user entry is present in the directory.

ORA-# Errors for SSL-Authenticated Enterprise Users

If you receive an ORA-# error while using SSL-authenticated Enterprise User Security, then locate the error in the following section and take the recommended action.


ORA-1017: Invalid username/password; login denied

Action: See "USER-SCHEMA ERROR Checklist"


ORA-28030: Problem accessing LDAP directory service

Cause: Indicates a problem with the connection between the database and the directory.

Action: Check the following:

  1. Check that there is a correct wallet_location value in the database's sqlnet.ora file. If not, then use Oracle Net Manager to enter one.
  2. If Domain Name System (DNS) server discovery of Oracle Internet Directory is not used, check that there is a correct ldap.ora file in $LDAP_ADMIN, $ORACLE_HOME/ldap/admin, $TNS_ADMIN, or $ORACLE_HOME/network/admin. (See Oracle Internet Directory Administrator's Guide for information about DNS server discovery.)
  3. Check that the SSL port used (by way of DNS discovery or an ldap.ora file) supports SSL with two-way authentication.
  4. Check that the LDAP_DIRECTORY_ACCESS parameter is set to SSL in the database initialization parameters file.
  5. Check that the database wallet has auto login enabled. Either use Oracle Wallet Manager, or check that there is a cwallet.sso file in $ORACLE_HOME/admin/<ORACLE_SID>/wallet/.
  6. Use the mkstore command line utility to check that the database wallet has the database DN in it by using the following syntax: 
    mkstore -wrl <database_wallet_location> -viewEntry ORACLE.SECURITY.DN

    If the wallet does not contain the database DN, then use Database Configuration Assistant to re-register the database with Oracle Internet Directory.

  7. Check that the database can bind to Oracle Internet Directory by using its wallet with the following ldapbind: 
    ldapbind -h <directory_host> -p <directory_SSLport> -U 3 -W 
"file:<database wallet_location>" -P <wallet_password>
  8. Check to ensure the database belongs to only one enterprise domain.

    Note:

    The mkstore utility is for troubleshooting purposes only. The name and functionality of this tool may change in the future. In 10g Release 1 (10.1), Oracle supports only the viewEntry mode.


ORA-28301: Domain policy has not been registered for SSL authentication

Action: Use Enterprise Security Manager to set the user authentication policy for this enterprise domain to include SSL.


ORA-28862: SSL handshake failed

Action: See Chapter 7, "Configuring Secure Sockets Layer Authentication" for information about configuring your SSL connection.

NO-GLOBAL-ROLES Checklist

If the enterprise user can connect to the database, but a select * from session_roles returns no global roles, then check the following:

  1. Check that the global role has been created in the database. To create global roles, use the following syntax: 
    CREATE ROLE <role_name> IDENTIFIED GLOBALLY;
  2. Use Enterprise Security Manager to check that the global role is included in an enterprise role in the directory.
  3. Use Enterprise Security Manager to check that the enterprise role is assigned to the user in the directory.
  4. If these checks are OK, then see the "DOMAIN-READ-ERROR Checklist".

USER-SCHEMA ERROR Checklist

If your database cannot read the user schema, then check the following:

  1. If this is an SSL-authenticated enterprise user, then ensure that the correct user wallet is being used by checking the following:
    • There is no WALLET_LOCATION parameter value in the client sqlnet.ora file, and
    • The TNS_ADMIN parameter is set properly so that the correct sqlnet.ora file is being used.
  2. Check that the schema was created in the database as a global user by using the following syntax: 
    CREATE USER username IDENTIFIED GLOBALLY AS ' ';

    or by using the following syntax:

    CREATE USER username IDENTIFIED GLOBALLY AS '<DN>';
  3. If the following is true:
    • The user schema is an exclusive schema (created with the CREATE USER username IDENTIFIED GLOBALLY AS '<user_DN>'; syntax), and
    • This is an SSL-authenticated user.

    Then ensure that the DN in the user wallet matches the DN that was used in the CREATE USER statement.

    Use Oracle Wallet Manager to view the DN in the user wallet.

    Use the following syntax to view the DN that was used with the CREATE USER statement:

    SELECT EXTERNAL_NAME FROM DBA_USERS WHERE USERNAME='<schema>';
  4. If you are using a shared schema, then check the following:
    • Use Enterprise Security Manager to ensure that you have created a user-schema mapping either for the entire enterprise domain, or for the database.
    • If the user-schema mapping is intended to apply to this database (not to the entire enterprise domain), then check that the database can read its own entry and subtree in the directory.

      To check this, enter the following ldapsearch command for your database-to-directory connection type:

      • If the database connects to the directory over SSL, then use 
        ldapsearch -h <directory_host> -p <directory_SSLport> -U 3 -W 
"file:<database_wallet_path>" -P <wallet_password> -b "<database_
DN>" "objectclass=*"

        where <wallet_password> is the password to the wallet, which enables you to open or change the wallet.

      • If the database connects to the directory by using password authentication, then use 
        ldapsearch -h <directory_host> -p <> -D <database_DN> 
-w <database_directory_password> -b "<database_DN>" "objectclass=*"

        where <database_directory_password> is the password in the database wallet, which is the database's password to Oracle Internet Directory.

      You should see the database entry and the relevant mapping.

    • If the user-schema mapping applies to the entire enterprise domain rather than to only this individual database, then see "DOMAIN-READ-ERROR Checklist".

DOMAIN-READ-ERROR Checklist

If your database cannot read its enterprise domain information in Oracle Internet Directory, then check the following:

  1. Use Enterprise Security Manager to check that the database is a member of exactly one enterprise domain, and add it to one if it is not.
  2. Check that the database can see its domain by entering one of the following at the command line:
    • If the database connects to the directory over SSL, then use 
      ldapsearch -h <directory_host> -p <directory_SSLport> -U 3 -W 
"file:<database_wallet_path>" -P <wallet_password> -b "cn=OracleContext, 
<realm_DN>" "objectclass=orclDBEnterpriseDomain"

      where <wallet_password> is the password to the wallet, which enables you to open or change the wallet.

    • If the database connects to the directory by using password authentication, then use 
      ldapsearch -h <directory_host> -p <directory_port> -D <database_DN> -w 
<database_directory_password> -b "cn=OracleContext, <realm_DN>" 
"objectclass=orclDBEnterpriseDomain"

      where <database_directory_password> is the password in the database wallet, which is the database's password to Oracle Internet Directory.

    This ldapsearch should return exactly one enterprise domain.

    If no domain is returned, and Enterprise Security Manager shows the database as a member of a domain, then restart the database. Restarting the database updates the cached value for the enterprise domain.

    If more than one domain is returned, then use Enterprise Security Manager to remove the database from the additional domain.

  3. Check that the database can read the enterprise domain subtree, and thus can read its enterprise roles and mappings, by entering one of the following at the command line:
    • If the database connects to the directory over SSL, then use 
      ldapsearch -h <directory_host> -p <directory_SSLport> -U 3 -W 
"file:<database_wallet_path>" -P <wallet_password> -b "cn=OracleContext, 
<realm_DN>" "objectclass=orclDBEnterpriseRole"

      where <wallet_password> is the password to the wallet, which enables you to open or change the wallet.

    • If the database connects to the directory by using password authentication, then use 
      ldapsearch -h <directory_host> -p <directory_port> -D <database_DN> -w 
<database_directory_password> -b "cn=OracleContext, <realm_DN>" 
"objectclass=orclDBEnterpriseRole"

      where <database_directory_password> is the password in the database wallet, which is the database's password to Oracle Internet Directory.

    This ldapsearch should return all of the enterprise roles that you have created for this domain. If it does not, then use Enterprise Security Manager to create enterprise roles and mappings.

  4. Use Enterprise Security Manager to set or reset the user authentication policy for the relevant enterprise domain. See "Managing Database Security Options for an Enterprise Domain" for information about setting the user authentication policy for an enterprise domain.
Go to previous page
Previous		 Go to next page
Next
 Oracle
Copyright © 1996, 2003 Oracle Corporation
All Rights Reserved.
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Feedback