Setting Up EUS

In this section, you’ll learn how to configure your Oracle databases to use EUS. Note that the actual steps for this setup vary depending on database and LDAP versions. This description is for the Oracle Database 10g. See the Oracle Advanced Security Administrator’s Guide for details on setup for Oracle9i Database.

Note 

The steps for EUS setup depend on the database and LDAP version that you are using.

LDAP Setup

The first step required for EUS is to install the LDAP directory. The most desirable architecture isolates the directory from other enterprise applications. This will ensure that the database providing the centralized directory services isn’t overwhelmed because, for example, it also has to support the company’s accounting application. When using OiD, the server requires enough capacity to support the OiD database and the throughput requirements necessary for all the users in your enterprise. A more powerful machine will be needed if you have a large user population with many applications and if you require high throughput.

These are the two basic requirements for the directory setup:

• Create the IM infrastructure in the directory. This is done by default if you’re using OiD as part of the IM capability to the Oracle Application Server. If you don’t have the infrastructure installed, the database registration process, detailed in the upcoming “Database Setup” section, will allow you to install the needed directory schema.

• Modify the default properties to accommodate any differences in your desired configuration and the default. You can change the attribute for the user’s log-on name (the default is cn for common name) and modify where searches begin within the directory tree.

Database Setup

Given an existing directory with the IM infrastructure installed, you’re now ready to configure the database(s). For clients wishing to use the username and password I&A to EUS, there is no configuration required. You’ll be using the username and password I&A for the examples in this chapter.

For the database, there are two things that have to be done to complete the setup. First, you need to tell the database where the directory server is. This can be done by either registering the directory in the corporate Domain Name System (DNS) or by creating an ldap.ora file. For this setup, you’ll use the ldap.ora file. More information on using DNS for directory discovery can be found in the Oracle Internet Directory Administrator’s Guide. The second step for database setup is to register the database with the directory.

Creating ldap.ora

To create the directory configuration file, you’ll need to run the Network Configuration Assistant tool. This is invoked by running netca on the command line.

When the Network Configuration Assistant (netca) starts, select the Directory Usage Configuration button. The next screen prompts you for a directory type. The two directory types supported are Oracle Internet Directory and Active Directory. If you select Active Directory, netca will ask you if the directory already has the necessary IM infrastructure or if you want it to be created. If you don’t have the infrastructure installed, netca can create one for you. You’ll not be able to proceed without the IM LDAP schema installed in your directory.

The third screen asks for the hostname, port, and SSL port of the directory. The final screen asks you to choose the security context in which the user information will be placed. A default context is created when the infrastructure is installed, and you can add contexts later to support delegated administration.

The preceding steps serve as an easy way to create an ldap.ora file. This file, which resides in your $ORACLE_HOME/network/admin directory, tells your database where the directory is and where in the directory to look when authenticating users. An example file will look as follows:

# Generated by Oracle configuration tools. DIRECTORY_SERVERS= (sabre.us.oracle.com:389:636) DEFAULT_ADMIN_CONTEXT = "dc=iac,dc=oracle,dc=com" DIRECTORY_SERVER_TYPE = OID 

This file is critical because the next step relies on its existence.

Registering the Database

The second task required to complete the database setup is to register the database with the directory and set the database authentication mode. The Database Configuration Assistant performs these tasks for you.

To run the database configuration assistant program, type dbca on the command line. Once the ldap.ora file has been created, the Database Configuration Assistant (dbca) will allow you to register the database.

Note 

If the ldap.ora file doesn’t exist, the option to register the database in a directory will not be available to you.

In the first step of the dbca wizard, select the Configure Database Options radio button. On the next screen, the wizard asks for the database instance you want to configure and a user with the DBA role for that instance. What it’s really asking for is a user with the SYSDBA role. If you supply a user without the SYSDBA role, you’ll get an error indicating insufficient privileges.

Providing the database instance and a privileged user leads you to step 3, which asks if you want to register the database. When you select the Yes, register the database radio button, you’ll also have to supply the administrator user and password for your directory. In the default Oracle installation, the administrator user has the username orcladmin. However, you can’t enter orcladmin in the username field; you have to enter the username as cn=orcladmin. Access to this directory account is required because the dbca has to insert records that will be used to identify the database for the directory.

This screen also requires you to enter an Oracle wallet password. Oracle uses the wallet as a metaphor for how an entity stores its security credentials. This is the technological equivalent of a person’s wallet. Just as you would keep your security credentials—driver’s license and credit cards—in your wallet for identification purposes, the Oracle wallet stores the credentials needed by users or the database. The dbca generates a random strong password and stores it securely in the wallet. This enables the database to authenticate to the directory when it needs to perform user authentication. The actual password the database uses to authenticate to the directory is not the same as the one you provide for the wallet. (Note that prior to Oracle Database 10g, the wallet was used only to hold PKI credentials.)

ldap_directory_access

The last part in the process is the modification of an init.ora parameter called ldap_directory_access. The ldap_directory_access initialization parameter is new to Oracle Database 10g. It replaces the rdbms_server_dn parameter used in Oracle8i Database and Oracle9i Database. The rdbms_server_dn served three purposes.

First, rdbms_server_dn defined the database’s identity within the directory. The value stored was the database’s distinguished name (DN), which was used to uniquely identify the database in the central directory. Unfortunately, you had to manually set the value and many people set it incorrectly because the correct value wasn’t obviously defined. In Oracle Database 10g, the database’s identity is created automatically and securely stored in the database’s wallet.

The second purpose of the rdbms_server_dn parameter was to act as a directory lookup indicator for the database. The database would use this value to determine whether it should consult the directory for user authorizations and mappings. In Oracle8i Database and Oracle9i Database, an SSL-authenticated user could either be a directory user (an Enterprise User) or a nondirectory user. If the rdbms_server_dn parameter was set, then the database used the directory for user authorizations and mappings; otherwise, the user was self-contained in the database. Thus, the database supported SSL-authenticated users without requiring the use of the directory.

A third use of this parameter was as a shutoff switch for directory access. It allowed DBAs to easily disable directory access for either performance or security reasons by simply setting the value to null.

In Oracle Database 10g, the ldap_directory_access still serves as an indicator of directory access. It supports the use of nondirectory-based SSL-authenticated users and can be used to quickly disable directory use. To disable directory access, a DBA simply issues the following:

ALTER SYSTEM SET ldap_directory_access = NONE SCOPE=MEMORY;

The possible values for this parameter are NONE, SSL, and PASSWORD with NONE set as the default during database creation. The dbca changes this value to PASSWORD and then reboots the database during this part of the EUS configuration. The other use for this parameter, as the parameter’s name implies, is to instruct the database on the I&A method it’ll use to connect to the directory.

Verifying the Database Setup

You can do three things to verify the database setup. After the database has rebooted, you can check the value of the ldap_directory_access parameter. It should now be set to PASSWORD:

sec_mgr@KNOX10g> show parameter ldap NAME                                 TYPE        VALUE ------------------------------------ ----------- --------- ldap_directory_access                string      PASSWORD

The next item to validate is the existence of the database wallet. This wallet will securely hold the database’s distinguished name and its directory password. The actual values are inaccessible from the wallet manager. The wallet will be located in a subdirectory called wallet in the same directory where the database dump files are written. On UNIX, the default directory is in $ORACLE_HOME/admin/<SID>/wallet.

Figure 5-1 illustrates what the wallet looks like when you open it with the Oracle Wallet Manager, which is invoked by typing owm from the command line on UNIX or running the Wallet Manager program from Windows. You can see the Secret Store contains the database identity and password.

Figure 5-1: The Oracle Wallet securely stores sensitive information for users and databases.

The database is now registered in the directory, and that too can be viewed and verified. The best way to see this is to launch the Oracle Enterprise Security Manager program by typing esm from the command line.

Note 

The Enterprise Security Manager is installed with the Oracle Client Software, not with the Oracle Database software.

You must log on as the directory administrator. After expanding the directory tree, you should see the database you just registered. Figure 5-2 shows the results of registering your database instance KNOX10G.

Figure 5-2: The Enterprise Security Manager shows five registered databases participating in EUS for the iac security realm.

SSL I&A

The database can be configured to authenticate to the directory with SSL. This provides not only strong encryption but also strong I&A for both the database and the directory.

This was the default I&A prior to Oracle Database 10g. It’s no longer the default because it’s much more difficult to set up the PKI infrastructure, and it potentially operates more slowly. The performance is due to the PKI processes and network encryption that occur. For some, the database and the directory may reside on a switched network or private network and the addition of SSL is not necessary. For unprotected networks, Oracle recommends using SSL for database-to-directory I&A.

Configuring SSL is unnecessary for the examples required in this chapter, and you should consider using password authentication first; it’s trivial to configure and it’ll allow you to begin using and understanding EUS. After you’re comfortable with the EUS abilities, switch the database authentication to SSL. You should strongly consider using SSL on your production systems unless the network can be protected through some other mechanism. SSL also provides strong database and directory authentication. Details for configuring your networks for SSL are given in the Oracle Advanced Security Administrator’s Guide 10g.