Release 8.1.7
Part Number A85430-01
 Library |
 Product |
 Contents |
 Index |
| Oracle Advanced Security Administrator's Guide Release 8.1.7 Part Number A85430-01 |
|
Enterprise user security management 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 management, in the following sections:
This section describes fundamental concepts related to enterprise user security management:
Administrators must manage complex user information, keeping it current and secure. These tasks become all the more challenging with increased use of technology and a high user turnover in enterprises. For example, in a typical enterprise, individual users can have multiple accounts on multiple databases. This can produce too many passwords for users to remember, and too many accounts for administrators 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 misuse of that user's accounts and privileges. However, in a large enterprise, with user accounts and passwords distributed over multiple databases, an administrator may not be able to make the timely changes required by good security practices.
Enterprise user security management 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 need only modify information in one location--the directory--to make effective changes in multiple databases and systems. This centralization lowers administrative costs and improves enterprise security.
Enterprise user security provides single sign-on to Oracle8i using interoperable X.509 v3 certificates over Secure Sockets Layer (SSL) v3, and supports the following LDAP-compliant directory services:
It also provides a tool, Oracle Enterprise Security Manager, to create user entries in the directory and manage authorizations for those users.
A directory is an index to information, organized so that you can find it easily. It lists objects--for example, people, books in a library, merchandise in a department store--and gives details about each one. Examples of directories include a telephone book, a library card catalog, and a department store catalog.
In a computerized environment, a directory is a specialized database that stores collections of information about objects. The information in such a directory might represent any resources that require management--for example, employee names, titles, and security credentials, information about e-commerce partners, or about shared network resources such as conference rooms and printers.
Some of the key concepts for understanding directories include:
In a directory, each collection of information about an object is called an entry. Just as a telephone directory includes entries for people, an online directory might include entries for employees, conference rooms, e-commerce partners, or shared network resources such as printers.
Each entry in a directory is uniquely identified by a distinguished name (DN). The distinguished name tells you where the entry resides in the directory's hierarchy, called a directory information tree (DIT), illustrated by Figure 17-1:
The DIT in Figure 17-1 is structured along geographical and organizational lines. The branch on the right represents the entry for Anne Smith, who works in the organizational unit (ou) Server Development, in the country (c) of Great Britain (uk), in the organization (o) Acme.
The DN for this Anne Smith entry is:
cn=Anne Smith,ou=Server Development,c=uk,o=acme.
Note that the conventional format of a distinguished name starts with the least significant component (that naming the entry itself) and proceeds to the most significant component (that just below the root).
|
Note: The example in Figure 17-1 uses the following notation to define distinguished name components: |
A directory's information is divided into units called directory naming contexts. A directory naming context is a subtree that resides entirely on one server. It must be contiguous, beginning at an entry that serves as the top of the subtree, and extending downward to either leaf entries or references to subordinate naming contexts. It can range in size from a single entry to the entire DIT.
With Oracle8i Release 8.1.7, as described later in this chapter, you choose one or more naming contexts to contain Oracle enterprise information. These are called administrative contexts, and within each one, you can create a container to hold Oracle enterprise information--called an Oracle Context.
The authorization process ensures that a user has access to only that information for which that user has privileges. When directory operations are attempted within a directory session, the directory server ensures that the user has the required permissions to perform those operations. Otherwise, the operation is disallowed. Through this mechanism, the directory server protects directory data from unauthorized operations by directory users. This mechanism is called access control.
Access control policies are captured in an Access Control List (ACL). An ACL is associated with each directory object and governs the access policies for that object.
ACLs specify the following:
Combining the flexibility of the Internet's LDAP standard with the robustness of the Oracle8i platform, the Oracle Internet Directory provides a scalable, reliable and secure LDAPv3 directory service for mission critical applications.
Oracle Internet Directory is an LDAP Version 3 service that combines the mission critical strength of Oracle's database technology with the flexibility and compatibility of the LDAP directory standard. Oracle Internet Directory is tightly integrated with the Oracle management environment, making it the enterprise directory of choice for Oracle using organizations. Its scalability, high availability and security features make it the ideal customer choice for internet service provider (ISP) and telecommunications carrier implementations.
The Oracle Internet Directory server is implemented as an application running on an Oracle8i database. Through its tight integration, Oracle Internet Directory effectively leverages the features of the Oracle platform to make it the compelling choice for mission-critical applications.
Oracle Internet Directory provides comprehensive and flexible support for LDAP v3 directory access control. This includes entry level, attribute level, and prescriptive access controls to provide varying levels of security to custom fit enterprise and service provider needs. An administrator can grant or control access to a specific directory object or an entire directory subtree. Oracle Internet Directory implements three levels of user authentication: anonymous, password-based, and certificate-based, using the Secure Socket Layer (SSL) v3 protocol for authenticated access and data privacy.
Oracle Internet Directory and Oracle Enterprise Manager both include Oracle Directory Manager, a graphical directory administrative tool for managing and administering directory information from anywhere in the distributed environment. It also manages directory schema, replication agreements, and access control information. Oracle Directory Manager provides administrative transparency for Oracle using organizations deploying both Enterprise Manager and Oracle Internet Directory. Written entirely in Java, Oracle Directory Manager is portable to all Oracle platforms.
The principal directory entries that relate to enterprise user security management include the following:
An enterprise user is one that is defined and managed in a directory. Each enterprise user has a unique identity across an enterprise.
Enterprise users can be assigned enterprise roles, which determine their access privileges on databases. These enterprise roles are also stored and managed in a directory.
An enterprise role consists of one or more global roles. 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 CLERK could contain the global role HRCLERK with its unique privileges on the Human Resources database, and the ANALYST role with its unique privileges on the Payroll database.
An enterprise role can be granted to or revoked from one or more enterprise users. For example, you could grant the enterprise role CLERK 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 grant and revoke their roles. A user can be granted local roles and privileges in a database in addition to enterprise roles.
An enterprise domain subtree includes an enterprise role object that contains information about global roles for each server and enterprise roles for the domain. These are created and managed by the Domain Administrator by using Oracle Enterprise Security Manager.
Local roles are stored in the database, and can be used in combination with enterprise roles. Local roles and privileges can also be created in the database. They can be granted directly to a shared schema, or they can be granted to a global role--that is part of an enterprise role and granted to a user.
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. It is here, at the enterprise domain level, that the Domain Administrator, using Oracle Enterprise Security Manager, allocates enterprise roles to users and manages enterprise security. An enterprise domain subtree in a directory is composed of two objects: enterprise role objects (discussed by Enterprise Roles and Global Roles), and mapping objects.
Each mapping object contains mapping information between a full or partial DN and an Oracle database user name. Mapping objects are created by the Domain Administrator for a particular domain. Mapping objects also reside under server objects, and are created by the Database Administrator for a particular database.
An Oracle Context (cn=OracleContext) is a special entry in the directory that contains various Oracle entries to support directory naming and enterprise user security. An Oracle Context contains three administrative groups and a product subtree, and can also include server and Net8 objects.
The Oracle Context also contains the database security subtree under the cn=products and cn=OracleDBSecurity container objects. This subtree contains enterprise domains, which are the groups of database servers and enterprise roles. The Oracle Context subtree is created by Oracle Net8 Configuration Assistant (Net8CA), and is populated with server entries by Oracle Database Configuration Assistant (DBCA) during the database install, and by Oracle Enterprise Security Manager during administration. Databases (and other Oracle LDAP clients) refer to entries in the context to determine enterprise user authorization at login.
During database installation, a default enterprise domain (cn=OracleDefaultDomain) is established. The domain administrator can later add additional enterprise domains (represented in Figure 17-2 as cn=Domain1) by using Oracle Enterprise Security Manager.
The administrative context is the location for an Oracle Context. It can be any directory entry. During directory access configuration, which is completed with Oracle Net8 Configuration Assistant during or after installation, you select an administrative context. An administrative context, an Oracle Context, and its subtrees are illustrated by Figure 17-2:
The Oracle Context contains three administrative groups, each with its associated ACL. The user who creates the Oracle Context with Net8CA automatically becomes the first member of each of these groups. The three administrative groups in an Oracle Context are described in Table 17-1:
You can also have a Domain Administrator responsible for managing a single domain. This administrator is less privileged than the Database Security Administrator. Similarly, you can have a Database Administrator responsible for a single database directory entry.
|
See Also:
Net8 Administrator's Guide for information about adding members to the OracleNetAdmins group |
In addition to server-related objects, an Oracle Context may also include other types of objects (Table 17-2):
| Object | Description |
|---|---|
|
Database server object |
A database server object (represented as |
|
Net service name object |
Net service name objects can be created during the database installation by using the Net8 Assistant. They can also be created later by members of the OracleNetAdmins group. |
Figure 17-3 provides an overview of the Enterprise User Security Management process:
Figure 17-4 describes the operation of the Enterprise User Security Management process, assuming:
The following sections describe shared schema features, and how to set them up:
Users do not necessarily require individual accounts or schemas set up in a database they wish to access. Alternatively, they can be granted access to common, shared schemas (also called user/schema separation) 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--they do need access to the Payroll schema.
Oracle8i Release 8.1.7 supports mapping multiple users stored in an enterprise directory to shared schema on an individual database. This separation of users from schemas reduces administration costs by reducing the number of user accounts. It means that you do not need to create an account for each user--a user schema--in multiple databases, 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 might have some 5,000 enterprise users mapped to just one of three or four shared schemas.
Summary:
To configure shared schemas, the local Database Administrator 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 global role HRMANAGER to the enterprise role MANAGER.
MANAGER to Harriet.
When Harriet connects to the database, she is automatically connected to the EMPLOYEE schema and is given the global role 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.
Shared schema functionality relies on SSL for authentication to the database. SSL authentication occurs as follows:
This method associates the DN of a single directory user with a particular schema on a database. It results in one mapping entry per user.
When using full DN mapping, each enterprise user can be mapped either to a unique schema, or to a shared schema.
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.
If the database does find either the DN locally or the appropriate DN mapping object in the directory, the database allows the user to log on.
For example, suppose that Harriet is trying to connect to the HR database, but the database does not find Harriet's DN. In this case, the HR database looks up the 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 maps her to the EMPLOYEE schema.
The database also retrieves from its own tables any local roles and privileges associated with the database schema to which the user is mapped.
The database uses both the global and the local roles to determine the information that the user can access.
|
See Also:
|
Continuing this example, assume that the enterprise role MANAGER contains the global roles ANALYST on the HR database, and CLERK 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. Her privileges on that database are determined by:
ANALYST
When Harriet connects to the Payroll database, her privileges are determined by:
CLERK
EMPLOYEE schema on the Payroll database
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 SALES_APPLICATION as follows:
CREATE USER sales_application IDENTIFIED GLOBALLY AS ''
To load entries one at a time, you can use Oracle Enterprise Security Manager. To load large numbers of entries, use other LDAP processes such as the Oracle Internet Directory bulk load tool.
|
See Also:
|
The mapping between enterprise users and a schema can be done in either the database or the directory.
The mapping 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, contained in a user's X.509 certificate, to a database schema that the user will access. You create a mapping object by using Oracle Enterprise Security Manager. This mapping can be either of the following:
When determining the schema to which it should connect the user, the database uses the following precedence rules:
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.
Oracle8i supports current user database links, which let you make a procedural connection to a second database as another user and with that user's privileges--though it does not require that the second user's credentials be stored in the database link definition. Such access is limited to the scope of the database link procedure.
For example, a current user database link lets Harriet, a user of the Accounts Payable database, procedurally access the Human Resources 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 Human Resources databases, you must enter the following command in each database:
CREATE USER Scott IDENTIFIED GLOBALLY AS 'CN=Scott,OU=Sales,C=US,O=Acme'
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 databases within a single enterprise domain, and only if that domain is trusted. You specify a domain as trusted by using Oracle Enterprise Security Manager. 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:
|
Oracle enterprise user security functionality uses the following administration tools:
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. Wallet Manager tasks include:
Chapter 18, Using Oracle Wallet Manager, for detailed information about using this application
See Also:
Use Oracle Enterprise Login Assistant to open and close a user wallet in order to enable or disable secure SSL-based communications for an application. A functional subset of Oracle Wallet manager, this easy-to-use tool lets users 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. It lets users securely access multiple databases and applications using a single password, entered only once per session.
|
See Also:
Chapter 19, Using Oracle Enterprise Login Assistant, for additional information about this tool |
Oracle Enterprise Security Manager is an administration tool that provides a graphical user interface to help you manage enterprise users, enterprise domains, databases, and enterprise roles that are stored in a directory server. Use Oracle Enterprise Security Manager to:
Chapter 20, Using Oracle Enterprise Security Manager, for detailed instructions about using this application
See Also:
This section describes how to set up enterprise user security. The required tasks follow:
Oracle Wallet Manager requires you to 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 18, Using Oracle Wallet Manager, for a description of certificate authorities and Oracle Wallet Manager |
Conceptually, there are four major prerequisites for an Oracle RDBMS to communicate with the directory:
ldap.ora) that tells the RDBMS how to connect to the directory, including host, port, and directory type-- and the location in the directory of the Oracle Context.
Net8CA performs the first three steps (called directory service access configuration), and the Oracle Database Configuration Assistant (DBCA) performs the fourth. Note that you must create the Oracle Context once per directory, but you need to create an ldap.ora file for each ORACLE_HOME used to access the directory. If there is no context, Net8CA asks if you want to create one; if one already exists, it asks which one you want to use. If there is no Oracle schema installed in the directory (which is done automatically for Oracle Internet Directory), Net8CA prompts you to install it.
If you run the recommended custom database install, Net8CA and DBCA automatically complete the directory-related configuration.
If you install the Oracle8i database using a typical install, Net8CA and DBCA do not complete the directory-related configuration. In this case, you must run both Net8CA and DBCA in standalone mode.
To install and configure a directory service:
Oracle8i Release 8.1.7 supports the following:
This requires the creation of an Oracle wallet for the directory. If you are using Oracle Internet Directory, use Oracle Wallet Manager and Oracle Directory Manager to create a wallet for the directory and to configure SSL. If you are using Microsoft Active Directory, see the product-specific documentation for instructions about enabling two-way SSL authentication.
Create administrative contexts beneath the directory naming contexts in the DIT.
For example:
If your naming context is dc=my_company,dc=com, you can enter dc=us,dc=my_company,dc=com as an administrative context.
Create administrative users--especially those authorized to register databases.
If you are using Oracle Internet Directory, use Net8CA to create Oracle Contexts (the Oracle schema is installed automatically).
If you are not using Oracle Internet Directory, you can use Net8CA later to install the Oracle schema and create Oracle Contexts.
|
See Also:
|
To install and configure one or more databases:
Use the Oracle Universal Installer to install Oracle8i databases. Before installation, obtain the following from the directory administrator:
During installation, select Oracle8i Enterprise Edition and the Custom installation type with Oracle Advanced Security.
Net8CA runs automatically at the end of the Oracle8i installation process; see Step 2 for related instructions.
To configure directory service access configuration, use Net8CA:
Directory Service Access Configuration; choose Next.
Perform directory access configuration for a server; choose Next.
Yes, I want to create a new Oracle Context; choose Next.
Either select an existing naming context, or enter the distinguished name (DN) of a directory entry under which you want to create your new context; choose Next.
Next.
ldap.ora file that tells the database where to find the context and the directory, and which port to use. Choose Finish to exit Net8CA.
ldap.ora file is located in one of the following directory paths:
X:\Oracle\Ora81\network\admin (Figure 17-5)
$ORACLE_HOME/network/admin
cn=OracleContext,o=nmt,c=us.
To register your database in the directory (using DBCA), you must provide directory credentials for either (i) a user in the database Installation Administrator's group, or (ii) the directory superuser. If you choose the first approach, you may need to add appropriate users to that group before running DBCA. Use Oracle Enterprise Security Manager to put the appropriate directory users into the Database Installation Admin group--so they can register the database in the directory.
To authorize users for administrative functions:
This step is necessary because Oracle Enterprise Security Manager logs you into the directory anonymously by default.
Directory-->Login and log in as a directory administrator, or as a user with permission to modify the context. If it is a new context, this user is the one who created the context. If it is a pre-existing context, any user in the database security admin group is acceptable; the Directory Server Login window appears (Figure 17-7); choose Login.
Yes.
Change database configuration and choose Next.
Next (this process typically takes about a minute to complete).
Next.
Next; the final Oracle Database Configuration Assistant window appears (Figure 17-8):
Yes, Register the Database, and enter the directory credentials for a user in the Database Installation Administrators group.
Finish; the Locate Initialization File window appears (Figure 17-9):
RDBMS_SERVER_DN initialization parameter to the init.ora file for the database. This parameter represents the distinguished name (DN) of the database as registered in the directory.
To configure the database for SSL:
If you are using an LDAP directory service for enterprise security, you can use Net8 directory naming. This lets the client connect to the database using the database entry registered with the directory by Oracle Database Configuration Assistant. You can alternatively use one of the other Net8 naming methods, such as local naming (tnsnames.ora file), to configure a net service name for the database. See the Oracle Net8 Administrator's Guide for more information.
Net8 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 Net8 Assistant to do this (See: Enabling SSL):
To configure the SSL service name:
Next.
TCP/IP with SSL; choose Next.
Next.
Finish.
File-->Save the network configuration; your TNSNAMES.ORA file is updated, and can be reviewed later.
To configure the listener:
Listeners and select Listener (in the expandable tree menu on the left side of the window).
Listening Locations from the drop-down menu at the top right side of the window.
Add Address button at the bottom right side of the window.
File-->Save Network Configuration; your listener.ora file is updated. Exit Net8 Assistant.
tnsnames.ora for the client; edit $ORACLE_HOME/network/admin/tnsnames.ora by adding the following to your SSL service name:
SECURITY = (AUTHENTICATION_SERVICE = TCPS)
To facilitate review of your .ora files, some Microsoft NT examples follow:
NAMES.DEFAULT_DOMAIN = WORLDOSS.SOURCE.MY_WALLET =(SOURCE =(METHOD = FILE)(METHOD_DATA =(DIRECTORY = C:\WINNT\Profiles\DATABASES\oe)))SQLNET_AUTHENTICATION_SERVICES = (TCPS,NTS)SSL_CLIENT_AUTHENTICATION = TRUESSL_VERSION = 0SQLNET.CRYPTO_SEED = 4fhfquweotcadsfdsafjkdsfqp5f201p45mxskdlfdasf
OESSL.WORLD =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCPS) (HOST = host1) (PORT = 5000))(CONNECT_DATE =(SERVICE_NAME = oe.world))(SECURITY = (AUTHENTICATION_SERVICE = TCPS))OE.WORLD =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP) (HOST = host1) (PORT = 1521))(CONNECT_DATA =(SERVICE_NAME = oe.world)))
OSS.SOURCE.MY_WALLET =(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 wallet:
To create a database wallet:
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=database_name,cn=OracleContext,administrative_context
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.acme.com, and the administrative context selected within Net8CA is ou=division1,c=us,o=acme, the complete DN of the database that you enter into Oracle Wallet Manager is:
cn=sales,cn=OracleContext,ou=division1,c=us,o=acme
The certificate text includes the lines BEGIN CERTIFICATE and END CERTIFICATE and the text between them.
BEGIN CERTIFICATE and END CERTIFICATE and the text between them.
For users to access the database using two-way SSL authentication, the database wallet must be open, and the listener must be running. To open the wallet and run the listener:
lsnrctl stop
lsnrctl stop
You can alternatively stop Oracle Listener Services in the Services Control Panel. See: Notes.
Note for NT:
cwallet.sso file in the wallet directory.
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 (Figure 17-10):
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.
lsnrctl start
lsnrctl start
The database wallet is now open, and the database is able to participate in authenticated communications using SSL; the OracleTNSListener service is also started.
|
See Also:
Chapter 18, Using Oracle Wallet Manager, for detailed instructions about creating a wallet. |
To log out of the database:
To verify that the database was successfully installed:
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, the Net8CA failed. Verify that the ORACLE_HOME is set and TNS_ADMIN is not set. Rerun Net8CA.
ldap.ora file exists and is correct. Then register the database again, using DBCA.
Although this step can be completed using Oracle Enterprise Manager, the following procedures use SQL*Plus directly.
To create global schemas and roles:
Using SQL*Plus, create a shared schema (called Guest, for example) for enterprise users by entering:
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.
Users connecting to this schema require a CREATE SESSION privilege. You can grant a CREATE SESSION privilege either to the guest schema, or to a global role which you grant to specific users though 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;
Once you have installed Oracle8i clients, configure Net8 on the clients by using Net8 Assistant. You may complete this step during or after installation of Oracle8i Release 8.1.7.
Because you will be using an LDAP directory service for enterprise security, you may also want to use Net8 directory naming. Net8 directory naming lets the client connect to the database using the database entry registered with the directory by Oracle Database Configuration Assistant. Alternatively, you can use one of the other Net8 naming methods, such as local naming (tnsnames.ora file), to configure a net service name for the database.
Use SSL to enable clients to connect and authenticate to a database. Use Net8 Assistant to configure SSL on UNIX; configure an SSL net service name, as described by Step 2 and Table 17-2. Do not enter a wallet location when configuring a client profile. The lack of a specific wallet location indicates that SSL should find the default wallet for the current OS user. In this way, the sqlnet.ora file can be shared by enterprise users, providing easier administration and deployment. If you use a non-default wallet location, you must create separate sqlnet.ora files for each user.
c:\winnt\profiles\<user>\ORACLE\WALLETS
/etc/ORACLE/WALLETS/<OS username>
|
Note: Wallets for specific users are set up when you create enterprise users. See Chapter 20, Using Oracle Enterprise Security Manager, for instructions about creating enterprise users. |
|
See Also:
|
Oracle Enterprise Security Manager is installed automatically as part of the Oracle8i installation, and 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 DBCA. Table 17-3 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. Make the enterprise domain trusted/untrusted. Only a trusted domain permits current user database links between member databases. |
|
|
3. Create enterprise roles in the domain. |
Creating an Enterprise Role within an Enterprise Domain
|
|
4. Use Oracle Enterprise Security Manager to make the database a member of the desired enterprise domain. |
Adding a Database to an Enterprise Domain
|
|
5. Create global roles on the databases. The SQL*Plus command is:
|
|
|
6. Assign a global role to each enterprise role. |
Creating an Enterprise Role within an Enterprise Domain
|
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:
You may want to populate the directory with users before using Oracle Enterprise Security Manager.
|
See Also:
|
To create a user wallet, refer to Chapter 18, 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 user or 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 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) for the users to connect to. These three users will not be able to 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 the Enterprise User:
The enterprise user must open the wallet created in Task 9 in order to log in to the database. Use Oracle Enterprise Login Assistant to open or close the wallet. Opening a user wallet generates a single sign-on file and allows authentication to the SSL adapter.
To open a user wallet:
Start-->Programs-->Oracle - OraHome81-->Network Administration-->Enterprise Login Assistant
elogin at the command line
The Oracle Enterprise Login Assistant window appears (Figure 17-11):
AutoLogin-->Login, and enter the wallet password.
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 sqlnet.ora file--that you created in Task 7: Configure Database Clients.
If you have a separate client ORACLE_HOME, you do not need to set the TNS_ADMIN environment variable.
Launch SQL*Plus and enter:
sqlplus/@connect_identifier
where connect_identifier is the net service name you set up in Task 7: Configure Database Clients. If you are using Net8 directory naming, the connect identifier is the simple database name.
The system should respond Connected to:...; this is the principal confirmation of a successful connection and setup. If an error message is displayed, see: Troubleshooting Enterprise User Login.
If you do connect successfully, check that the appropriate global roles were retrieved from the directory by entering:
select * from session_roles
In the Oracle Enterprise Login Assistant, select Autologin > Logout to disable authentication with the SSL adapter.
|
See Also:
Chapter 19, Using Oracle Enterprise Login Assistant, for instructions about using Oracle Enterprise Login Assistant. |
This section describes potential problems and associated corrective actions.
The following tips help you verify that the user has been allocated the correct global roles upon database login and, if necessary, help determine the cause of failure:
SELECT * FROM session_roles;
Do an LDAP search to display the appropriate roles by entering the following:
ldapsearch -h <directory hostname> P <SSL directory port number> -U 3
-W "file:<walletpath>" -P [database wallet password]
-b "[n=oracleDBSecurity, cn=Products, cn=OracleContext, [admin context]"
"objectclass=orclDBenterprisedomain"
If you do not see the roles, the database is not in the correct domain--or there is an incorrect distinguished name (DN) in the database wallet certificate. If the database appears to be receiving information from the wrong domain, try restarting the database to update its internal domain membership information.
This error may indicate that you attempted to configure a domestic cipher suite. Run the Net8 Assistant again, and be sure that you choose the Show Domestic Cipher Suites button.
This error indicates that the connection was not over SSL. Look at the tnsnames.ora file to verify the protocol value of the net service name that you are using. The value must be TCPS and not TCP.
The distinguished name that the wallet uses to connect does not match the DN in the CREATE USER statement for any schema in the database, and it does not match the DN in any relevant mapping.
set NLS_LANG=AMERICAN_AMERICA.UTF8
ldapbind -h <directory hostname> -p <directory SSL port number> -U 3 -W "file:[database wallet path]" -P [database wallet password]
Bind successful should be displayed. If the bind fails, try restarting the SSL instance of your directory.
Then try the bind again.
If it still doesn't work, carefully check the wallet location in the configuration set via Oracle Directory Manager. Make sure that it is set to the proper path name.
guest to be a non-shared schema. In sqlplus as
system/manager@database_name, enter:
alter user guest identified globally as 'cn=oe20emp,c=us';
and then try the connect /@connect_identifier again. If this succeeds, the problem is associated with the mapping of the user to the schema; use Oracle Enterprise Security Manager to check that mapping in the directory.
Alter this user back to a shared schema by entering:
alter user guest identified globally as '';
This error usually means that something is wrong with the wallet. Look in the sqlnet.log file in the current operating system directory for more information. Also, on Microsoft NT, this can mean that the Oracle service has stopped; check the Services control panel.
This error occurs when you attempt to open a wallet that you are not allowed 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.
This is a catch-all Oracle8i error that indicates something unanticipated went wrong with the RDBMS to LDAP directory query.
You can use tracing to help debug. This is appropriate if the ldapbind (See: ORA-1017: Invalid username/password) 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:
oidctl conn=oiddb1 server=oidldapd instance=2 stop
oidctl conn=oiddb1 server=oidldapd instance=2 conf=1
flags="debug=65535" start
This starts up the SSL Oracle Internet Directory instance in full debug mode. Log files will be written to $ORACLE_HOME\ldap\log. Look at the file with an 02 and an s in its filename, because it is for the instance 2 server. 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.
To turn off Oracle Internet Directory tracing, restart via oidctl without the flags parameter.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|