Release 2 (9.2)
Part Number A96573-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle Advanced Security Administrator's Guide Release 2 (9.2) Part Number A96573-01 |
|
Enterprise User Security lets you create and administer large numbers of users in a secure, LDAP-compliant directory service. This chapter describes the configuration and setup of Enterprise User Security.
This chapter contains the following topics:
This part introduces Oracle Enterprise User Security, and describes its fundamental concepts.
Part I contains the following sections:
This section describes fundamental concepts related to Enterprise User Security:
Administrators must manage complex user information for the entire enterprise, keeping it both current and secure. This task becomes increasingly difficult as the use of technology expands and the user turnover rate increases throughout an enterprise. In a typical enterprise, every user can have multiple accounts on different databases, requiring users to remember passwords for each of these accounts. This can produce too many passwords for users to remember, and too many accounts for administrators to effectively manage.
With thousands of users accessing thousands of database accounts, administrators must devote substantial resources to user administration. Common information used by multiple applications, such as usernames, telephone numbers, and system roles and privileges, is typically fragmented across the enterprise, contributing to data that is redundant, inconsistent, and difficult to manage.
There are security problems as well. For example, any time a user leaves a company or changes jobs, that user's privileges should be changed the same day in order to guard against their misuse. However, in a large enterprise, with user accounts and passwords distributed over multiple databases, an administrator may be unable to make such timely changes. In addition, users may elect to write down their passwords (making them easy for others to copy), or make them easy to remember (making them easy for others to guess), or simply choose the same password for multiple applications. All of these user efforts to keep track of their multiple passwords compromise the security of the enterprise.
Enterprise User Security addresses these user, administrative, and security challenges by centralizing storage and management of user-related information in an LDAP-compliant directory service. When an employee changes jobs in such an environment, the administrator needs to modify information in only one location--the directory--to make effective changes in multiple databases and systems. This centralization can substantially lower administrative costs while materially improving enterprise security.
Enterprise users benefit from Enterprise User Security as well, through single sign-on (SSO) or single password authentication, depending on the configuration chosen by the administrator.
Using single sign-on users need to authenticate only once and subsequent authentications take place transparently. It addresses the multiple password problem, and provides stronger, PKI-based authentication, combined with an improved user experience.
Single password authentication lets enterprise users authenticate to multiple databases with a single global password although each database requires a separate authentication. The password is securely stored in the centrally located, LDAP-compliant directory, and protected with security mechanisms including encryption and an Access Control List (ACL). This approach improves usability by reducing the number of passwords to remember and eliminating the overhead of setting up SSL.
Oracle9i, Release 2 (9.2) Enterprise User Security supports the following LDAP-compliant directory services:
Oracle Advanced Security also provides a tool, Oracle Enterprise Security Manager, to create user entries in the directory and manage authorizations for those users.
Enterprise User Security lets administrators manage two types of users in a single LDAP-compliant directory:
Password-authenticated enterprise users use single password authentication.
SSL-authenticated users use single sign-on (SSO) and strong authentication, using industry-standard, interoperable X.509 v3 certificates over Secure Sockets Layer (SSL) v3.
Each authentication method has its own set of selection criteria, as summarized by Table 15-1:
| Selection Criteria, Applicable to: | |
|---|---|
| Password Authentication | SSL-Authentication |
|
Supports password-based logins. |
Provides stronger, systemwide security. |
|
Does not support PKI, or PKI certificate-based client authentication. |
Supports PKI, certificate-based authentication. |
|
Does not employ SSL, wallets, or X.509 certificates. |
Supports PKI, SSL, and industry-standard X.509 certificates. |
|
Supports single, global user passwords, with separate authentications required for each database and application (single password authentication). |
Supports single sign-on (SSO) using SSL. |
|
Provides faster processing, because there is no SSL processing required between clients and servers (supports Oracle Advanced Security native encryption). |
Somewhat slower connection processing, but with higher network security. |
|
From the user/client point of view, password authentication may be viewed as easier-to-use, particularly for notebooks and home workstations. |
SSL is more difficult to configure initially because PKI credentials must be generated for all users, but it provides stronger security. |
|
Password authentication is compatible with either a two-tier or three-tier environment. |
SSL-authentication is compatible with either a two-tier or three-tier environment. |
|
Password authentication supports Oracle Release 7.3 or 8.0 clients, with an Oracle9i database. |
SSL-authentication supports Oracle8i or Oracle9i clients with an Oracle9i database. |
|
Note: Enterprise User Security supports three-tier environments. Oracle9i proxy authentication features enable (i) proxy of user names and passwords through multiple tiers, and (ii) proxy of X.509 certificates and distinguished names through multiple tiers. |
Oracle8i releases of Oracle Advanced Security use SSL processing to establish secure channels between (i) the client and the server, and (ii) the database server and the LDAP-compliant directory. The client authentication mechanism uses SSL and X.509 v3 certificates, which requires installed Oracle wallets on both the client and the server.
Oracle9i complements certificate-based authentication with password-based authentication for enterprise users, including the following principal features:
The following directory entries relate to Enterprise User Security:
An enterprise user is one that is defined and managed in a directory. Each enterprise user has a unique identity across an enterprise. Enterprise user entries can reside at any location within the directory.
The entries described in the following sections can only reside within an Oracle Context.
Enterprise users can be assigned an enterprise role, which determines their access privileges on databases. These enterprise roles are also stored and managed in a directory. Figure 15-1 shows an example of an enterprise role called Manager under the OracleDefaultDomain.
An enterprise role can consist of one global role or many, each one of which is defined in a specific database. A global role includes privileges contained in a database, but the global role is managed in a directory. An enterprise role is thus a container of global roles. For example, the enterprise role USER could contain the global role HRCLERK with its privileges on the Human Resources database, and the ANALYST role with its privileges on the Payroll database.
An enterprise role can be assigned to one or more enterprise users. For example, you could assign the enterprise role USER to a number of enterprise users who hold the same job. This information is protected in the directory, and only the administrator can manage users and assign their roles. A user can be granted local roles and privileges in a database in addition to enterprise roles.
An enterprise domain subtree includes enterprise role entries, each of which contains information about associated global roles on each server and authorized enterprise users. These are created and managed by the Domain Administrator by using Oracle Enterprise Security Manager.
|
Note: The database obtains a user's global roles when the user logs in. If you change a user's global roles in the directory, those changes do not take effect until the next time the user logs in. |
An enterprise domain is a group of databases and enterprise roles. An example of a domain could be the engineering division in an enterprise or a small enterprise itself. Figure 15-1 show an example of an enterprise domain called Services that resides under the OracleDBSecurity entry in an Oracle Context. It is here, at the enterprise domain level, that the Domain Administrator, using Oracle Enterprise Security Manager, assigns enterprise roles to users and manages enterprise security. An enterprise domain subtree in a directory is composed of three types of entries: enterprise role entries (discussed by Enterprise Roles), User-Schema Mappings, and the Domain Administrator's group for that domain.
A database server entry (represented as "Sales" in Figure 15-1) contains information about a database server. It is created by the Database Configuration Assistant or Oracle Enterprise Security Manager during database registration. A database server entry is the parent of database level mapping entries that contain mapping information between full or partial DNs and Oracle shared schema names. Database-level mapping entries are created by the Database Administrator by using Oracle Enterprise Security Manager. A Database Administrator's group, containing administrators for that database, is located under the server entry.
A user-schema mapping entry contains mapping information between a DN and an Oracle database user name. The users referenced in the mapping are connected to the specified schema when they connect to the database. User-schema mapping entries can apply only to one database or they can apply to all databases in a domain.
The Oracle Context contains administrative groups that are related to Enterprise User Security. Figure 15-1 shows these administrative groups in the Oracle Context. Each administrative group includes an Access Control List (ACL) that controls access to the group itself. ACLs elsewhere in the directory may refer to these groups, which allows directory administrators access to perform necessary administrative tasks. The user who creates the Oracle Context with Oracle Net Configuration Assistant automatically becomes the first member of each of these groups.
You can also have a Domain Administrator responsible for managing a single enterprise domain. Similarly, you can have a Database Administrator responsible for a single database directory entry. These administrative groups reside directly under the relevant database or domain entry.
The OracleContext creator is a member of each group by default, but can be removed. Note: every group must have at least one member according to LDAP restrictions.
The relevant administrative groups in an Oracle Context are described in Table 15-2.
In all secure password-based authentication methods, a server authenticates a client with a password verifier, typically a hashed version of the password that must be rigorously protected. Password-based authentication to an Oracle database is no different. There is an Oracle proprietary password verifier, and it must be protected as well. This is true if the verifier is stored locally in the database or centrally in the directory. Note that a password verifier cannot be used to derive its original password.
In the current release an enterprise user's database password can be stored in a central directory service for access by multiple databases, and is viewable and shared by all trusted databases to which the user has access. Although the password verifier stored in the directory is not the cleartext password, it is still necessary to protect it from casual or unauthorized access. It is therefore extremely important to define password-related ACLs in the directory that are as restrictive as possible, while still enabling necessary access and usability.
Oracle tools help set up ACLs in the directory to protect these password verifiers. The approach that Oracle Corporation recommends is intended to balance security and usability considerations. If you require maximum security and can set up wallets for all users, you should require only SSL connections from users to databases. This SSL-only approach circumvents the entire directory password protection issue.
The OraclePasswordAccessibleDomains group in each Oracle Context is created automatically when the context is created, and can be managed using Oracle Enterprise Security Manager. Enterprise domains with member databases that must view users' database password verifiers in the directory are placed into this group. Enterprise Security Manager can be used to place an appropriate ACL on user subtrees, so that databases in this group can read the password verifier for users in that subtree.
There are two steps involved in this approach:
This step places an ACL on the selected user search base entry in the directory that permits access to the attribute that holds the Oracle database password verifier as follows:
These ACLs allow access to the Oracle database password verifier value only (the orcldbpassword attribute). No other attributes in the user entries are affected.
| See Also:
Oracle9i Directory Service Integration and Deployment Guide for more information about the LDAP schema for Enterprise User Security |
Figure 15-2 displays the Enterprise User Security elements for SSL authentication:
Text description of the illustration ano81019.gif
Figure 15-3 displays the Enterprise User Security elements for password authentication:
Text description of the illustration ano81031.gif
Figure 15-4 shows the operation of the Enterprise User Security process. For an SSL processing environment, the following assumptions apply:
Text description of the illustration ano81022.gif
This section describes the operation of the Enterprise User Security process, with password-based authentication. The following step numbers correspond to the steps shown in Figure 15-4:
|
Note: In a three-tier environment, enterprise users can authenticate to the database through any middle tier using proxy authentication. |
The following sections describe shared schemas, and how to set them up:
Users do not necessarily require individual accounts or schemas set up in each database. Alternatively, they can be granted access to a shared schema that is associated with target applications. For example, suppose that users Tom, Dick, and Harriet require access to the Payroll application on the Finance database. They do not need to create unique objects in the database, and therefore do not need their own schemas, but they do need access to the Payroll schema.
Oracle9i Release 2 (9.2) supports mapping multiple users stored in an enterprise directory to a shared schema on an individual database. This separation of users from schemas reduces administration costs by reducing the number of user accounts on databases. It means that you do not need to create an account for each user, also referred to as a user schema, in addition to creating the user in the directory. Instead, you can create a user in one location, the enterprise directory, and map the user to a shared schema that other enterprise users can also be mapped to. For example, if Tom, Dick and Harriet all access both the Sales and the Finance databases, you do not need to create an account for each user on each of these databases. Instead, you can create a single shared schema on each database, such as SALES_APPLICATION and FINANCE_APPLICATION, respectively, that all three users can access. A typical environment can have up to 5,000 enterprise users mapped to one shared schema and each user can be assigned a set of enterprise roles.
Oracle Corporation recommends that you create a separate shared schema that contains no objects to use as an entry point. Then grant access to application objects in other schemas through enterprise roles. Otherwise, application objects can be inadvertently deleted.
In summary, shared schemas provide the following benefits:
To configure shared schemas, the local database administrator (DBA) must create at least one database schema in a database. Enterprise users can be mapped to this schema.
In the following example, the administrator creates a shared schema and maps users to it:
EMPLOYEE and the global role HRMANAGER on the HR database.MANAGER. The administrator then assigns the HR database global role of HRMANAGER to the enterprise role MANAGER.MANAGER to Harriet.When Harriet connects to the HR database, she is automatically connected to the EMPLOYEE schema and is given the global role of HRMANAGER. Multiple enterprise users can be mapped to the same shared schema. For example, the enterprise security administrator can create another enterprise user Scott and map Scott to the EMPLOYEE schema. From that point on, both Harriet and Scott automatically use the EMPLOYEE schema when connecting to the HR database, but each can have different roles and can be individually audited.
The syntax for creating a shared schema is:
CREATE USER [shared schema name] IDENTIFIED GLOBALLY AS ''
For example, the administrator for the HR database creates a shared schema for the user EMPLOYEE as follows:
CREATE USER employee IDENTIFIED GLOBALLY AS ''
|
Note: There is no space between the single quotation marks in the syntax for creating a shared schema. |
A discussion of the schema identification process follows:
Global schemas (those created with CREATE USER IDENTIFIED GLOBALLY AS " ") can be owned by one enterprise user (private schema) or shared among multiple enterprise users (shared schema). The mapping between a single enterprise user and his or her private schema is stored in the database as an association between the user DN and the schema name. The mapping between enterprise users and a shared schema is done in the directory by means of one or more mapping objects. A mapping object is used to map the distinguished name (DN) of a user to a database schema that the user will access. You create a mapping object by using Oracle Enterprise Security Manager. This mapping can be one of the following:
This method associates the DN of a single directory user with a particular schema on a database. It results in one mapping entry for each user.
This method lets multiple enterprise users share part of their DN to access the same shared schema. This method is useful if multiple enterprise users are already grouped under some common root in the directory tree. The subtree that these users share can be mapped to a shared schema on a database. For example, you can map all enterprise users in the subtree for the engineering division to one shared schema, BUG_APPLICATION, on the bug database. Note that the root of the subtree is not mapped to the specified schema.
When an enterprise user connects to a database, the database retrieves a DN for the user, either from the network (in the case of SSL) or from the directory (in the case of password-authenticated enterprise users).
When determining which schema to connect the user to, the database uses the user DN and the following precedence rules:
For example, suppose that Harriet is trying to connect to the HR database, but the database does not find Harriet's private schema (in the database). In this case, the HR database looks up a user schema mapping with Harriet's DN in the directory. The directory has a mapping of Harriet to the shared schema EMPLOYEE and returns this schema. The database logs Harriet in and connects her to the EMPLOYEE schema.
Continuing this example, assume that the enterprise role MANAGER contains the global roles ANALYST on the HR database, and USER on the Payroll database. When Harriet, who has the enterprise role MANAGER, connects to the HR database, she uses the schema EMPLOYEE on that database.
You can grant privileges to a specified group of users by granting roles and privileges to a database schema. Every user sharing such a schema gets these local roles and privileges in addition to personal enterprise roles. However, you should exercise caution when doing this, because every user who is mapped to this shared schema can exercise the privileges assigned to it. Accordingly, Oracle does not recommend granting roles and privileges to a shared schema.
Oracle9i supports current user database links for both SSL-authenticated and password-authenticated enterprise users. Current user database links let you connect to a second database as yourself, or as another user when used from within a stored procedure owned by that user. Such access is limited to the scope of the procedure. The security advantage of current user database links is that the other user's credentials are not stored in the database link definition, and are not sent across the network connection between databases. Instead, security of these links is based on mutual trust, mutual authentication, and a secure network connection between the databases themselves.
For example, a current user database link lets Harriet, a user of the Finance database, procedurally access the Accounts Payable database by connecting as Scott, and using Scott's credentials.
For Harriet to access a current user database link to connect to the schema Scott, Scott must be a schema created as IDENTIFIED GLOBALLY in both databases. Harriet, however, can be a user identified in one of three ways:
To create Scott as a global user in both the Accounts Payable and Finance databases, you must enter the following command in each database:
CREATE USER Scott IDENTIFIED GLOBALLY as 'CN=Scott,O=nmt'
Note that the syntax for creating this kind of schema is slightly different from the syntax for creating a shared schema described in Creating a Shared Schema. In this case, the schema is Scott's alone. In order for the current user database link to work, the schema created for Scott cannot be shared with other users.
Current user database links operate only between trusted databases within a single enterprise domain--databases within the domain trust each other to authenticate users. You specify an enterprise domain as trusted by using Oracle Enterprise Security Manager. By default, if current user database links are enabled for a domain by using Enterprise Security Manager, they will work for all databases within that domain. To specify a database as untrusted that is part of a trusted enterprise domain, use the PL/SQL package DBMS_DISTRIBUTED_TRUST_ADMIN. To obtain a list of trusted servers, use the TRUSTED_SERVERS view.
See Also:
|
Enterprise User Security functionality uses the following administration tools:
Oracle Enterprise Security Manager is an administration tool that provides a graphical user interface to help you manage
Use Oracle Enterprise Login Assistant to enable autologin, to upload wallets to or download them from a directory, and to change wallet, directory, and database passwords. This tool lets enterprise users use SSL to connect to multiple services with a single sign-on. Oracle Enterprise Login Assistant masks the complexity of SSL, wallets, enterprise users, and the process of authenticating to multiple databases.
Oracle Enterprise Login Assistant also supports password authentication, letting users securely access multiple databases and applications using a single password, entered once for each session.
Oracle Wallet Manager is a standalone Java application that wallet owners and security administrators use to manage and edit the security credentials in their Oracle wallets.
| See Also:
Chapter 17, Using Oracle Wallet Manager, for detailed information about using this application |
Consider the following before deploying Enterprise User Security:
Beyond the general benefits that flow from the centralization of enterprise users and their associated credentials, there are a number of security-related benefits and risks that should be reviewed.
One security benefit is that centralizing management makes it easier and faster to administer users, credentials, and roles, and to quickly revoke a user's privileges on all applications and databases across the enterprise. With centralized management, the administrator can delete a user in one place to revoke all global privileges, minimizing the risk of retaining unintended privileges.
Another security benefit is that it can be more secure to centrally control security information, because you can centralize the organization's security expertise. Specialized, security-aware administrators can manage all aspects of enterprise user security, including directory security, user roles and privileges, and database access. This is a substantial improvement over the traditional model, where Database Administrators are typically responsible for everything on the databases they manage, including security.
The downside is that, while Oracle Internet Directory is a secure repository, there is a security challenge and inherent risk in centralizing credentials in any publicly accessible repository. Although centralized credentials can be protected at least as securely as distributed credentials, the very nature of centralization increases the consequences of inadvertent credential exposure to unauthorized parties. It is therefore imperative to limit the privileges of administrators, to set restrictive Access Control Lists (ACLs) in the directory, and to implement good security practices in the protection of security credentials when they are temporarily outside of the directory.
Consider the following criteria when defining the database membership of a domain:
This part describes the initial Enterprise User Security configuration tasks for both SSL and password authentication.
This part contains the following tasks:
The following prerequisites are required:
To create valid wallets, you must have a certificate authority (CA) in your environment. You can use a CA vendor's certificates, or you can use your own CA that can process PKCS#10 certificate requests in Base 64 format and return X509v3 certificates--also in Base 64 format.
| See Also:
Chapter 17, Using Oracle Wallet Manager, for a description of certificate authorities and Oracle Wallet Manager |
Oracle9i Enterprise User Security, Release 2 (9.2) requires Oracle Internet Directory, Release 9.2. This installs with the required version of the Oracle schema. Install and configure Oracle Internet Directory. Note that Enterprise User Security requires an Oracle Internet Directory SSL instance, which in turn requires that the directory have a wallet.
|
Caution: For security reasons, do not store the wallet password in the configuration set in Oracle Internet Directory. Instead, enable autologin for the directory wallet. |
Ensure that the directory has an Oracle9i, Release 2 (9.2) schema and an appropriate Oracle Context installed. The Oracle9i, Release 2 (9.2) version schema is backward compatible.
Oracle Internet Directory is shipped with a pre-installed Oracle Context at the directory root. You can use Oracle Net Configuration Assistant to create additional Oracle Contexts.
You must upgrade an Oracle8i Oracle Context before registering an Oracle9i database with that context in the directory. You can use this upgraded Oracle Context to register any Oracle8i databases that are created in the future. If you have a combination of Oracle8i and Oracle9i databases deployed, set the VERSIONCOMPATIBILITY parameter to 8i and 9i, using Oracle Enterprise Security Manager. Oracle recommends that you set this to 9i if you deploy only Oracle9i databases. This parameter determines if some of the database security attributes must be represented in the directory in two places to support both Oracle8i and Oracle9i databases. If you are deploying only Oracle8i databases, there is no requirement to upgrade the Oracle Context--and no requirement to set this parameter.
If they do not already exist, create enterprise users in the directory who are authorized to perform the following functions:
See Also:
|
Set up directory access for an Oracle home using Oracle Net Configuration Assistant and register the database in the directory using Database Configuration Assistant or Oracle Enterprise Security Manager.
When a database is properly registered in the directory, the following changes occur:
spfile.ora file as an RDBMS_SERVER_DN initialization parameter value.A database can be registered in the directory using either Oracle Enterprise Security Manager or Database Configuration Assistant. However, each tool performs a different set of automatic configurations. These differences are summarized in Table 15-3.
This tool requires that individual local DBAs be granted access to the directory by adding the DBA to the Database Registration Admins group in Oracle Enterprise Security Manager.
| See Also:
Oracle9i Directory Service Integration and Deployment Guide for information about using Database Configuration Assistant to register a database in the directory. |
This tool can be used to register a database with the directory from a centralized location without granting directory access privileges to individual local DBAs. If you use Oracle Enterprise Security Manager to register databases in the directory, then after registration, you must
RDBMS_SERVER_DN parameter in the spfile.ora file for the database using the ALTER SYSTEM command| See Also:
Chapter 19, "Using Oracle Enterprise Security Manager" for information about using Oracle Enterprise Security Manager to register a database in the directory. |
To configure the database for SSL:
Oracle Net must be configured for SSL on both the listener and the database. The listener must have a listening endpoint that is configured for the TCP/IP with SSL protocol, and the location of the database wallet must be specified. Use Oracle Net Manager to do this (See: Enabling SSL):
Configure the SSL service name using Oracle Net Manager.
Do not test this connection when asked. It will fail because (i) you have not set up the listener to listen for SSL connections, and (ii) if you have used the database configuration assistant to register a database with the directory, then you have not set up the database wallet.
| See Also:
,"Enabling SSL" for information about using Oracle Net Manager to configure an SSL service name (Step 2) and to configure the listener (Step 3). |
Use Oracle Net Manager to configure the listener to have an SSL listening endpoint.
To facilitate review of your .ora files, some Windows NT examples follow:
NAMES.DEFAULT_DOMAIN = WORLDWALLET_LOCATION =(SOURCE =
(METHOD = FILE)(METHOD_DATA =
(DIRECTORY = C:\WINNT\Profiles\DATABASES\oe)
)
)
SQLNET_AUTHENTICATION_SERVICES = (TCPS,NTS) SSL_CLIENT_AUTHENTICATION = TRUE SSL_VERSION = 0
OESSL.WORLD =(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS) (HOST = host1) (PORT = 5000)
)(CONNECT_DATA =
(SERVICE_NAME = finance)
)(SECURITY = (AUTHENTICATION_SERVICE = TCPS)
(SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,o=Oracle,c=us")
)
)
OE.WORLD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP) (HOST = host1) (PORT = 1521)
)(CONNECT_DATA =
(SERVICE_NAME = oe.world)
)
)
WALLET_LOCATION =(SOURCE =
(METHOD = FILE)(METHOD_DATA =
(DIRECTORY = C:\WINNT\Profiles\DATABASES\oe)
)
)
LISTENER =(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (host = HOST1) (port = 1521)
)(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCPS) (HOST = host1) (PORT = 5000))
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = oe.world)(ORACLE_HOME = D:\Oracle\Ora81)(SID_NAME = oe)
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
To create and configure the database wallet:
Create a database wallet.
| See Also:
"Managing Wallets" for information about creating a database wallet. |
When you select New from the wallet menu, do not create a new default directory when asked--this is for user wallets. During certificate request creation, type the distinguished name (DN) of the database exactly:
cn=simple_database_name, cn=OracleContext,<location of Oraclecontext>
It is found in the initialization parameter file, in the parameter
RDBMS_SERVER_DN
For example:
If the global database name chosen during installation is sales.us.nmt.com, and the location selected within Oracle Net Configuration Assistant for the Oracle Context is o=nmt, the complete DN of the database that you enter into Oracle Wallet Manager is:
cn=sales,cn=OracleContext,o=nmt
For the database to communicate securely with Oracle Internet Directory, autologin must be enabled for the database wallet. If users will be authenticated with SSL, then the database listener needs to be started. The listener reads the cwallet.sso file created when autologin is enabled for the database. To enable database autologin:
cwallet.sso file in the wallet directory.To stop the listener, enter the following at the command line:
To change the Oracle Services login:
OracleService <database name>; choose the Stop button; choose Yes to confirm.Startup button.Log On As region of the Service window, Choose This Account and enter <domain>\< NT user login> for the user who enabled autologin for the database wallet.
Alternatively, you can choose the browse button (...) to select from a list; enter your password in the Password and Confirm Password fields; choose OK. The Oracle Service window is shown in Figure 15-5.
Text description of the illustration eus0004.gif
Start to start up the Oracle database.Oracle-<ORACLE_HOME_NAME>->TNSListener; do not start the listener service.The database wallet is now open, and the database is able to participate in authenticated communications using SSL; on Windows, the OracleTNSListener service is also started.
| See Also:
Chapter 17, Using Oracle Wallet Manager, for detailed instructions about creating a wallet |
If the database is to be shut down for an extended period of time, then disable use of the database wallet for security purposes by disabling autologin with Oracle Wallet Manager.
To verify that the database has been successfully configured:
cwallet.sso file located in the database wallet directory. If not, autologin was not successfully enabled. If this happens, go back to the Oracle Wallet Manager, open the wallet, select the Autologin check box, and save the wallet.ldap.ora file located in
$ORACLE_HOME/network/admin
If there is no ldap.ora file, Oracle Net Configuration Assistant failed to configure directory access. Verify that the ORACLE_HOME is set and rerun the network configuration assistant.
ldap.ora file exists and is correct. Then register the database again, using Database Configuration Assistant or Oracle Enterprise Security Manager.Although this task can be completed using Oracle Enterprise Manager, the following examples use SQL*Plus directly.
To create global schemas and roles:
Using SQL*Plus, create a shared schema for enterprise users. For example, to create a shared schema called guest, enter the following:
CREATE USER guest IDENTIFIED GLOBALLY AS ''
Note the two single quotation marks with no space between them at the end of the line. If you enter a specific distinguished name (DN) between the quotation marks, only that user is able to connect to that schema, and it is not shared.
Users connecting to this schema require a CREATE SESSION privilege. You can grant the CREATE SESSION privilege either to the global schema, or to a global role which you grant to specific users through an enterprise role.
Create global roles for the database to hold relevant privileges. These roles are associated with enterprise roles to be created later. Enterprise roles are allocated to users.
For example:
CREATE ROLE emprole IDENTIFIED GLOBALLY;CREATE ROLE custrole IDENTIFIED GLOBALLY;
Associate privileges with the new global roles.
For example:
GRANT select ON products TO custrole, emprole;
|
Note: Oracle Advanced Security can be configured to authenticate enterprise users using SSL or password authentication, or both.
|
This section describes the final steps to complete the installation and configuration of Enterprise User Security for SSL authentication. The required tasks (numbered in sequence from Part II) follow:
|
Note: The configuration tasks for Enterprise User Security are numbered consecutively, and continue in sequence from Part II. This part includes Task 5 through Task 8.
|
Once you have installed Oracle9i clients, configure Oracle Net on the clients by using Oracle Net Manager. You may complete this step during or after installation of Oracle9i Release 2 (9.2).
Because you will be using an LDAP directory service for enterprise security, you may also want to use Oracle Net directory naming. Oracle Net directory naming lets the client connect to the database using the database entry registered with the directory by Database Configuration Assistant. Alternatively, you can use one of the other Oracle Net naming methods, such as local naming (tnsnames.ora file), to configure a net service name for the database.
To configure database clients:
sqlnet.ora file can be shared by enterprise users, providing easier administration and deployment. Each user whose wallet is in a nondefault wallet location must have a separate sqlnet.ora file that contains that user's wallet location.
Default Wallet Directories for the User Wallets:
<userprofile>\ORACLE\WALLETS
/etc/ORACLE/WALLETS/<operating_system_username>
|
Note: Wallets for specific users are set up when you create enterprise users. See Chapter 19, Using Oracle Enterprise Security Manager, for instructions about creating enterprise users. |
See Also:
|
Oracle Enterprise Security Manager is installed automatically as part of the Oracle9i installation, and is used to configure an enterprise domain. Note that the Oracle default domain is created by default when the Oracle Context is created in the directory, and databases are automatically added as members of that domain when they are registered by Database Configuration Assistant or Oracle Enterprise Security Manager. Table 15-4 lists the steps required to set up an enterprise domain, and cross-references related instructions. If you are using the Oracle default domain, you can skip steps 1 and 4.
| Step | Related Instructions |
|---|---|
|
1. Create an enterprise domain. |
|
|
2. Enable or disable current user database links between member databases. |
|
|
3. Select authentication type for the domain. Must be (i) SSL only, or (ii) both password and SSL. |
"Managing Database Security Options for an Enterprise Domain". |
|
4. Enroll the database as a member of the desired enterprise domain.Foot 1 |
|
|
5. (Optional) Add domain administrators for the domain. |
|
|
6. Configure user-schema mappings for the domain; alternatively, you can configure database-specific user-schema mappings. |
|
|
7. Create enterprise roles in the domain. |
|
|
8. Create global roles on the databases. The SQL*Plus command is:
|
|
|
9. Assign global roles to each enterprise role. |
| 1 A database can be a member of no more than one domain at a time. If you change a database's domain membership, then you need to restart the database. |
To create a new enterprise user:
Any directory user can be an enterprise user. You can add users to the directory by using one of the following tools:
If you do not use Oracle Enterprise Security Manager to populate the directory with users, then you need to add the orcluser objectclass to their user entries in the directory.
If Oracle Enterprise Security Manager is used to prepare existing user entries for Oracle use (provision), the orcluser objectclass is added to the existing entry.
See Also:
|
To create a user wallet, See: Chapter 17, Using Oracle Wallet Manager.
You can do either or both of the following:
Use Oracle Enterprise Manager or SQL*Plus to grant local roles and privileges to the database schema. This step is optional.
Use Oracle Enterprise Security Manager to grant enterprise roles to the enterprise user in the directory.
If you are using a shared schema, use Oracle Enterprise Security Manager to map the user to a schema. You can choose either of the following mapping options:
Applies to one database.
Applies to all databases in the enterprise domain.
For example:
If you are creating a domain mapping from three users to a shared schema called guest, and you have more than one database in the domain, each database must have a shared schema (called guest) that all three users can access. These three users cannot connect to any database in the domain that does not have a shared schema called guest.
Alternatively, you can create a mapping under a particular database. If you do it this way, the mapping applies only to that database, and not to all databases in the domain. If you have mappings in both places, the database mapping takes precedence.
See Also:
|
To log in as an Enterprise User:
To download a user wallet from the directory:
| See Also:
"Connecting to LDAP Directory and Downloading New Wallet" for information about downloading the wallet from the directory by using Oracle Enterprise Login Assistant. |
The enterprise user must enable autologin for the user wallet (created in Task 10) in order to connect to the database. Enabling autologin generates a single sign-on file and enables authentication to the SSL adapter.
To enable autologin, use Oracle Enterprise Login Assistant.
| See Also:
Chapter 18, Using Oracle Enterprise Login Assistant, for information about downloading a user wallet and enabling autologin. |
ORACLE_HOME.
If the ORACLE_HOME is set to a server ORACLE_HOME, you must set the TNS_ADMIN environment variable to address the directory where you placed the client sqlnet.ora file--that you created in Task 5: Configure Database Clients.
If you have a separate client ORACLE_HOME, you do not need to set the TNS_ADMIN environment variable.
sqlplus/@connect_identifier
where connect_identifier is the net service name you set up in Task 5: Configure Database Clients.
If you are successful, the system responds Connected to:...; this is the principal confirmation of a successful connection and setup. If an error message is displayed, see: "Part V: Troubleshooting Enterprise User Security".
If you do connect successfully, check that the appropriate global roles were retrieved from the directory by entering:
select * from session_roles
Using Oracle Enterprise Login Assistant, choose the Logout button (Figure 18-2) to disable authentication with the SSL adapter.
| See Also:
Chapter 18, Using Oracle Enterprise Login Assistant, for instructions about using Oracle Enterprise Login Assistant |
|
Note: You have competed the configuration of Enterprise User Security for SSL authentication, then do not proceed to Section IV, which describes the configuration of password authentication only. |
At this point, you should already have a directory server and a database that are SSL-enabled. In addition, you should already have created global schemas and roles on the database.
This section describes how to set up password authentication for enterprise users. The required tasks (numbered in sequence from Part III) follow:
|
Note: The configuration tasks for Enterprise User Security are numbered consecutively, and continue in sequence from Part III. This part includes Task 9 through Task 12.
|
Configure the enterprise domain for password authentication.
Oracle Enterprise Security Manager is used to manage enterprise domains, users, roles, and databases. It can be used to configure an enterprise domain. Note that the Oracle default domain is created by default when the Oracle Context is created in the directory, and databases are automatically added as members of that domain when they are registered by Database Configuration Assistant or Oracle Enterprise Security Manager.
Table 15-5 lists the steps required to set up an enterprise domain, and cross-references related instructions. If you are using the Oracle default domain, you can skip step 1 and step 4.
In the General tab of the Oracle Context Properties Window add the user search bases under which the databases are to search for user entries. A user search base is the root of a subtree under which you have stored your enterprise user entries in the directory.
|
Note: When you enter user search bases, Oracle Enterprise Security Manager attempts to grant access permissions in the user search base subtree so the appropriate databases can read users' login credentials. If the current enterprise administrator (the user of Oracle Enterprise Security Manager) does not have permission in the directory to modify the Access Control List (ACL) on the user search base entry, then Oracle Enterprise Security Manager will fail with an error message in this part of the user search base setup. If this happens, then an enterprise administrator with the appropriate directory privileges must use Oracle Enterprise Security Manager to enable database access on this user search base. See: "Step 2: Enable Database Access". |
The user entry must reside in a directory subtree of users that has been enabled for Oracle database access. You can set Oracle Database Access permissions for a selected subtree to let databases within a domain in the Password-Accessible Domains group of a particular Oracle Context read the user's login credentials.
To enable database access:
Under an Oracle Context, select a user search base on a selected subtree of directory users, set Oracle Database Access permissions to permit databases in the Password-Accessible Domains group to access the user's database login credentials:
Choose the General tab in the Root Oracle Context Properties window. In the Context Attribute Settings region, enter the name of the user entry attribute that holds the UserID (nickname) that uniquely identifies each enterprise user.
If you do not want to have the user nicknames (UserID) stored in the cn attribute (which is the default), then this must be configured for the entire directory in the Root Oracle Context.
Choose the Administrators tab in the Root Oracle Context Properties window. Set up necessary administrators for this Oracle Context, if you haven't already done so.
In order to accept password-authenticated connections, a database must belong to a domain in the Password Accessible Domains group.
In a selected Oracle9i Oracle Context, put your database into the Password-Accessible Domains group. Choose Add and select one of the current enterprise domains from the resulting dialog. To remove an enterprise domain from the group, select it in the Accessible Domains window and choose Remove.
See Also:
|
Any directory user can be an enterprise user. You can add users to the directory by using one of the following tools:
See Also:
|
You can do any of the following:
Use Oracle Enterprise Manager or SQL*Plus to grant local roles and privileges to the database user or schema; this step is optional.
Use Oracle Enterprise Security Manager to grant enterprise roles to the enterprise user in the directory. User authorizations are the aggregate of both local database roles and enterprise roles.
If you are using a shared schema, use Oracle Enterprise Security Manager to map the user to a schema. You can choose either of the following mapping options:
For example:
If you are creating a domain mapping from three users to a shared schema called guest, and you have more than one database in the domain, each database must have a shared schema (called guest) that all three users can access. These three users cannot connect to any database in the domain that does not have a shared schema called guest.
Alternatively, you can create a mapping under a particular database. If you do it this way, the mapping applies only to that database, and not to all databases in the domain. If you have mappings in both places, the database mapping takes precedence.
See Also:
|
For each user, define a UserID that is unique across the enterprise. The default UserID is the value in the common name (cn) attribute defined in the LDAP directory.
Choose a UserID that conforms to the following:
cn to be the UserID attribute, and Scott's cn attribute value is Scott.us, there can be no other cn=Scott.us defined in any of the users specified in the user search base field.Choose the Password tab of the Create User Window to create a password for each enterprise user. Oracle Enterprise Security Manager automatically creates the associated password verifiers and stores them in the orclPassword attribute of the user entry.
|
Note: You can use Oracle Enterprise Login Assistant to change passwords at any time. However, you cannot use the directory manager tools or LDAP command line calls to set users' database passwords. |
For an enterprise user whose UserID is hscortea and whose password is welcome, enter the following to connect using sqlplus:
SQL>connect hscortea/welcome@<TNS Service Name>
The database authenticates the enterprise user (hscortea) by verifying the username/password combination against the directory entry associated with this user. If successful, the connection to the database is established.
This section describes potential problems and associated corrective actions in the following topics:
If you receive an ORA-# error, locate the error in Table 15-6 and take the recommended action.
| Error | Action |
|---|---|
|
ORA-1017: Invalid Username/password; login denied |
|
|
ORA-28271: No permission to read user entry in LDAP directory service |
|
|
ORA-28272: Domain policy does not allow password-authenticated GLOBAL users |
Use Oracle Enterprise Security Manager to set the user authentication policy for this enterprise domain to "Oracle Wallet (SSL) And Password." |
|
ORA-28273: No mapping for user nickname to LDAP distinguished name exists. |
|
|
ORA-28274: No ORACLE password attribute corresponding to user nickname exists. |
|
|
ORA-28275: Multiple mappings for user nickname to LDAP distinguished name exist. |
This means that there are multiple user DNs in the directory within the user search base whose nickname/UserID for the user matches what was provided during the database connection. Use Oracle Enterprise Security Manager to make the nickname/UserID value unique (no two users share the same nickname) within all user search bases associated with the Oracle Context listed in the |
|
ORA-28277: LDAP search, while authenticating global user with passwords, failed. |
Check that the directory SSL instance is up and running. |
|
ORA-28278: No domain policy registered for password-based GLOBAL users. |
This means that the database cannot read the enterprise domain information that it needs. See: "DOMAIN-READ-ERROR Checklist" |
|
ORA-28279: Error reading |
Check that the |
|
ORA-28030: LDAP problems |
Possible reasons:
|
If you receive a User-Schema error, then check the following:
IDENTIFIED GLOBALLY AS '<full_DN_of_user>'?
ldapsearch -h <directory_host> -p <directory_SSLport> -U 3 -W "file:<database_wallet_path>" -P <database_wallet_password> -b "<database_DN>" "objectclass=*"
You should see the database entry and the relevant mapping, at least. Stop here.
ALTER USER <username> IDENTIFIED GLOBALLY AS '<full_DN_of_user>'
If you receive a DOMAIN-READ-ERROR, then check the following:
ldapbind -h <directory_host> -p <directory_SSLport> -U 3 -W "file:<wallet_ location>" -P <wallet_password>
If this fails, then ensure that the directory has a running SSL instance.
| See Also:
Oracle Internet Directory Administrator's Guide for information about managing a directory SSL instance. |
RDBMS_SERVER_DN parameter in the spfile.ora file matches the DN in the database wallet. Note that the attribute identifiers [those that are located to the left of the equals (=) signs] are not case-sensitive, but the attribute values [those that are located to the right of the equals (=) signs] are case-sensitive. For example, cn=database1 and CN=database1 are the same (match), but cn=database1 and cn=DATABASE1 are different (do not match). If these do not match, then you need to get a new certificate in the database wallet.ldapsearch -h <directory_host> -p <directory_SSLport> -U 3 -W "file:<database_wallet_path>" -P <database_wallet_password> -b "cn=OracleContext, <admin_context>" "objectclass=orclDBEnterpriseDomain"
If this fails, then try restarting the database to update the cached value for the enterprise domain.
ldapsearch -h <directory_host> -p <directory_SSLport> -U 3 -W "file:<database_wallet_path>" -P <database_wallet_password> -b "cn=OracleContext, <admin_context>" "objectclass=orclDBEnterpriseRole"
You should see all of the enterprise roles that you have created for this domain.
DOMAIN-READ-ERROR, then restart the directory SSL instance and the database.Applies to Window NT only.
This error occurs when you attempt to open a wallet that you are not permitted to open.
For Example:
user-x, but you do not have a local sqlnet.ora file that identifies c:\winnt\profiles\user-x\oracle\wallets as your wallet location.sqlnet.ora file in the default location to find the wallet location, and then tries to open the database wallet to get your login credentials.user-x does not have permission to open the database wallet.You can use tracing to help debug. This is appropriate if the ldapbind fails, indicating that the directory's SSL instance is not working properly.
If you are using Oracle Internet Directory as your LDAP directory, use the following tracing procedure:
|
Note: See Also: Oracle Internet Directory Administrator's Guide |
$ORACLE_HOME\ldap\log. Look at the file with your SSL directory instance number and an s in its filename. The log files without the s are for the monitor process (oidmon) and the dispatcher. Look at the end of the log file immediately after you have tried your connect /@connect_identifier. One thing to look for is the string Distinguished Name to ensure that it matches the DN of your user.
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|