Release 9.0.2
Part Number A95192-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Internet Directory Administrator's Guide Release 9.0.2 Part Number A95192-01 |
|
This chapter explains how to manage an Oracle directory server by using Oracle Directory Manager and command-line tools.
This chapter contains these topics:
Chapter 3, "Preliminary Tasks and Information" for instructions on starting and stopping directory server instances
See Also:
When you start an Oracle directory server by using the OID Control Utility, that start message refers to a configuration set entry containing server parameters. You can add, modify, and delete configuration set entries by using either Oracle Directory Manager or the appropriate command-line tool.
|
See Also:
|
This section contains these topics:
Although you can change values in the default configuration set, namely, configset0, all of your changes will be carried over to every new configuration set entry that you create. This is because configset0 values are used as the template for all new configuration set entries.
When you want to change values that should not always be in effect for every instance of the server that you run, it is better to create new configuration set entries. Note that this applies to the Oracle directory server instances only. The Oracle replication directory server supports only one configuration set.
You may want to establish a separate instance of a directory server with different values. If you do not want those values to be exercised by all users, set up a new configuration set entry and run a separate server instance pointing to that configuration set entry for groups with special needs.
Figure 5-1 shows three separate directory server instances, each with a different value.
Figure 5-1 shows:
cn=osdldap) with:
cn=osdrepld) using configset0
See Also:
You can use Oracle Directory Manager to view, add, modify, and delete configuration set entries.
|
Important Note: You cannot change the parameters for an active instance directly; you must change the parameters in a configuration set entry and save it. After the configuration set entry is saved, use the OID Control Utility restart command to stop current Oracle directory server instances and restart them. You can change a configuration set entry and start fresh instances that use the new parameters. The changes will not affect the older instances that are still running, however, unless they have been restarted. For information on restarting directory server instances, see "Task 3: Reset the Default Security Configuration". |
To view configuration set entries:
You can see all the parameters for the instance by selecting the tabs across the top of the dialog box. However, you cannot change them in this dialog box. To change them, you must change the configuration set entry on which they are based.
The first time you add a configuration set entry, you can:
To add configuration set entries by copying the default configuration set entry:
Remember: The changes will not affect the active directory server instance until you restart it. See "Restarting Directory Server Instances".
Note:
See Also:
To create a new configuration set entry without copying from a previous configuration set entry:
To modify configuration set entries:
Modify the values in the fields for the General tab as described in this table:
You can change any of the values. Press Apply to save the changes.
Remember: The changes will not affect the active directory server instance until you restart it. See "Restarting Directory Server Instances".
Appendix D, "Oracle Wallet Manager" for information on setting the location of the Oracle Wallet and the Oracle Wallet password.
Note:
See Also:
To delete configuration set entries:
Remember: The changes will not affect the active directory server instance until you restart it. See "Restarting Directory Server Instances".
Note:
Although changing configuration set entries by using Oracle Directory Manager is desirable, it can sometimes be more convenient to use the available command-line tools--for example, when you want to make the same set of changes across multiple Oracle directory servers.
When you add or modify configuration set entries by using the command-line tools, the input file for adding a new configuration set entry should be written in LDAP Data Interchange Format (LDIF). It should contain only the attributes and values that differ from the installed defaults. The directory server uses the attribute values that you establish in the new configuration set entry to override its own existing values for these attributes.
|
See Also:
"LDAP Data Interchange Format (LDIF) Syntax" for information on LDIF |
If you are adding a new Oracle directory server instance, you can either use an existing configuration set entry, or add a new one for the new instance.
To add a new configuration set entry, create an input file, and then load the input file with ldapadd. Follow these steps:
Input files must use LDIF format. When you create the input file, you need to define or include only those attributes that differ from the current values in that configuration set entry.
In this example, the parameter configset2 is the RDN, or local name, of the new entry, the wallet location is: /HOME/test/wallet, and the password is welcome.
dn:cn=configset2, cn=osdldapd, cn=subconfigsubentry
cn:configset2
objectclass:orclConfigSet
objectclass:orclLDAPSubConfig
objectclass:top
orclsslauthentication:1
orclsslenable:1
orclsslport:5000
orclsslversion:3
orclsslwalletpasswd:welcome
orclsslwalleturl:file:/HOME/test/wallet
At the system prompt, type the command to add the input file. If the example shown above were given the file name newconfigs, the ldapadd command would look something like this:
ldapadd [options] -f newconfigs
|
See Also:
|
To modify or delete an existing configuration set entry, create an input file containing only the attributes that you want to change, and then load the input file with the ldapmodify command. Follow these steps:
When you create the input file, define or include only those attributes that differ from the installed defaults.
Input files must have LDIF format.
In the example shown below, the parameter cn=configset2,cn=osdldapd,cn=subconfigsubentry is the DN, or local name, of an existing configuration set entry. This example shows how to modify the ORCLSSLPORT parameter to 7000.
dn:cn=configset2,cn=osdldapd,cn=subconfigsubentry
changetype: modify
replace: orclsslport
orclsslport: 7000
Type the command to reference the input file at the system prompt. For example, if the input file were named configfile, your ldapmodify command would look something like the command shown that follows:
ldapmodify[options] -f configfile
|
See Also:
|
An operational attribute--as opposed to an application attribute--pertains to the operation of the directory itself. Some operational information is specified by the directory to control the server--for example, the time stamp for an entry. Other operational information, such as access information, is defined by administrators and is used by the directory program in its processing. You must have superuser privileges to set system operational attributes.
This section contains these topics:
You can view and set some of the operational attributes for each Oracle directory server to which you are connected by using Oracle Directory Manager. To do this, in the navigator pane, expand Oracle Internet Directory Servers, then select a server. System operational attributes appear in the right pane.
The next table describes the fields displayed in Oracle Directory Manager for each system operational attribute.
The modifiable system operational attributes are:
|
See Also:
"ldapmodify Syntax" for a more detailed discussion of ldapmodify, and a list of its options |
To enable users to search for specific naming contexts, you can publish those naming contexts. To do this, you specify the topmost entry of each naming context as a value of the namingContexts attribute in the root DSE.
For example, suppose you have a DIT with three major naming contexts, the topmost entries of which are c=uk, c=us, and c=de. If these entries are specified as values in the namingContexts attribute, then a user, by specifying the appropriate filter, can find information about them by searching the root DSE. The user can then focus the search--for example, by concentrating on the c=de naming context in particular.
To publish a naming context, you can use either Oracle Directory Manager or ldapmodify. The namingContexts attribute is multi-valued, so you can specify multiple naming contexts.
To search for published naming contexts, perform a base search on the root DSE with objectClass =* specified as a search filter. The retrieved information includes those entries specified inWthe namingContexts attribute.
Before you publish a naming context, be sure that:
This section contains these topics:
The following example input file specifies the entry c=uk as a naming context.
dn: changetype: modify add: namingcontexts namingcontexts: c=uk
A super user is a special directory administrator who typically has full access to directory information. The default user name of the super user is orcladmin; the default password is welcome. Oracle Corporation recommends that you change the password immediately.
A guest user is one who is not an anonymous user, and, at the same time, does not have a specific user entry. The default user name for a guest user is guest; the default password is guest.
A proxy user, as described in "Indirect Authentication", is typically used in an environment with a middle tier such as a firewall, a RADIUS server, or by an application like the Delegated Administration Service. The default user name for a proxy user is proxy; the default password is proxy.
You can administer user names and passwords for the super, guest, and proxy users by using either Oracle Directory Manager or ldapmodify.
|
See Also:
Chapter 13, "Directory Access Control" for information on how to set access rights |
This section contains these topics:
To set a user name or password for a super user, a guest user, or a proxy user by using Oracle Directory Manager:
The next table lists and describes the fields in the System Passwords tab page.
To set or modify a user name or password for a superuser, a guest user, or a proxy user, use ldapmodify to modify the appropriate attribute:
For example, to change the password of the super user to superuserpassword, use ldapmodify to modify the directory-specific entry (DSE) by using an LDIF file containing the following:
dn: changetype:modify replace:orclsupassword orclsupassword:superuserpassword
|
See Also:
"ldapmodify Syntax" for ldapmodify syntax and usage notes. |
You can set the maximum number of entries returned in searches, as well as the maximum amount of time, in seconds, for searches to be completed. You can do both of these by using either Oracle Directory Manager or ldapmodify.
This section contains these topics:
You can use Oracle Directory Manager to set the maximum number of retries returned in searches and the maximum amount of time to allow for searches.
You can use ldamodify to set the maximum number of retries returned in searches and the maximum amount of time to allow for searches.
Setting the Maximum Number of Entries Returned in Searches by Using ldapmodify
The following example changes the maximum number of entries to be returned in searches to 500.
ldapmodify -h myhost -p 389 -v <<EOF dn: changetype: modify replace: orclsizelimit orclsizelimit: 500 EOF
Setting the Maximum Amount of Time For Searches by Using ldapmodify
The following example changes the maximum amount of time for a search to 2400.
ldapmodify -h myhost -p 389 -v <<EOF dn: changetype: modify replace: orcltimelimit orcltimelimit: 2400
EOF
This section contains these topics:
The Oracle Internet Directory Server Manageability framework enables you to monitor the following directory server statistics:
Please note that no LDAP query interface is provided for these statistics and events.
Some monitored information is made available by means of a web-based Oracle Enterprise Manager GUI tool. Please refer to the online Help for the Oracle Enterprise Manager web-based GUI tool for OID Server manageability.
Figure 5-2 and the accompanying text explain the relationship between the various components of directory server manageability.
A directory server responds to directory requests from clients. It has four kinds of functional threads: dispatcher, listener, controller, and worker. It accepts LDAP requests from clients, processes them, and sends the LDAP response back to the clients.
When you use the Oracle Internet Directory Server Manageability framework to set runtime monitoring, the four functional threads of the server record the specified information and store it in local memory.
|
See Also:
"An Oracle Directory Server Instance" for a description of the directory server |
This is a local process memory. The Oracle Internet Directory Servers Manageability framework assigns one each for statistics, tracing, and auditing. Each has its own separate data structure maintained in the local memory storage.
These dedicated write threads differ from server functional threads in that they write server statistics, audit logging, and tracing information to the repository. To maintain reduced system overhead, their priorities are kept low.
This module, which is proprietary and external to the server manageability framework, collects the gathered statistics through a standard LDAP interface with the directory server and stores it in its own repository.
This is the repository that the monitoring agent uses to store the gathered directory server statistics. The monitoring agent determines how this repository is implemented.
Oracle Enterprise Manager extracts monitored data from the statistics and events repository, presenting it in a Web-based graphical user interface. Users can view the data in a normal browser. A repository can store the collected data for generic and custom queries.
This repository uses a file system to store information traced across various modules of the directory server. By using a file system for this purpose, the Oracle Internet Directory Server Manageability framework uses the features and security of the operating system.
This repository contains all user-entered data--for example, user and group entries.
This repository is like the tracing repository except that it stores the information in the same database as the directory data repository rather than in a file system. In this way, the Oracle Internet Directory Server Manageability framework uses:
The directory manageability framework isolates the gathered information from the directory data by storing the two separately.
The Oracle Internet Directory Server Manageability framework stores configuration parameters in the DSE root of the directory for all three modules--namely, server statistics, server tracing, and server auditing. To specify periodicity, amount, and level of information to be gathered, you must set appropriate values for these parameters.
To configure the Oracle Internet Directory Server Manageability framework, use ldapmodify to set positive integer values for these attributes in the DSE root entry:
You can set debug logging levels by using either Oracle Directory Manager or the OID Control Utility.
This section contains these topics:
To set the debug logging level:
Ordinarily, you can leave the check boxes on this tab page unselected. However, to generate a log for a specific problem, use this tab page to specify the debug logging level.
To set debug logging levels by using the OID Control Utility, restart the Oracle directory server using the -debug flag for an LDAP server, and the -d flag for the replication server. Use the debug level number based on Table 5-1.
Because debug levels are additive, you need to sum together the numbers representing the functions that you want to activate, and use that sum in the command-line option.
By default, debug logging is turned off. To turn it on, modify the directory-specific entry (DSE) attribute orcldebugflag to the level you want. You can configure debug levels to one of the following levels.
To see debug log files generated by the OID Control Utility, navigate to $ORACLE_HOME/ldap/log.
Table 5-1 provides the complete list of debug logging levels.
For example, to trace function calls (1) and active connection management (8), enter 9 as the debug level (8 + 1 = 9) as follows:
oidctl server=oidldapd instance=1 flags='-debug 9' restart oidctl server=oidrepld instance=1 flags='-h my_host -p 389 -d 9' restart
This example restarts both the Oracle directory server as well as the Oracle directory replication server with the debugging flags.
The audit log records critical events on the Oracle directory server that are important from both a security and an operational point of view. Because the log generation depends on events on the directory server, you cannot create audit log entries. Only the directory server itself can create them.
The audit log is made up of regular directory entries, one entry for each event. You can query the audit log by using ldapsearch, and you can view the audit log entries by using Oracle Directory Manager.
By default, audit logging is disabled. To enable it, modify the directory-specific entry (DSE) attribute orclauditlevel to the level you want. You can configure audit levels to audit only selected events.
|
See Also:
|
Each audit log entry contains the orclAuditoc object class. Like all other structural object classes, orclAuditoc inherits from top. Its attributes include:
Note that the audit log entries do not become part of a regular search result set even though the search filter can satisfy the query criteria. For example, a search with the condition objectclass=top does not yield results from the auditlog entries. Only a search with cn=auditlog as the base of the search can find audit log entries.
|
Note:
By default, the attributes |
|
See Also:
|
The audit log container is part of the DSE. It holds its entries as children, organized according to the orclsequence attribute. See Figure 5-3.
Table 5-2 shows the auditable events and their audit levels. The third column, Audit Levels, contains hexidecimal values. You can audit more than one event by adding their corresponding values found in this column.
The setting for the DSE attribute orclauditlevel indicates the current audit level. You can enable or disable the events described in the previous section. A value of 0 for this attribute, which is the default, disables auditing.
You can set the audit level by using either Oracle Directory Manager or ldapmodify. This section describes both methods.
To set the audit level by using Oracle Directory Manager:
Both successful and unsuccessful events are entered into the audit log if they are selected, except:
Restart the directory server instance after any changes are made to orclauditlevel for the changes to take effect.
|
See Also:
"Restarting Directory Server Instances" for instructions on how to restart the directory server |
|
See Also:
"Auditable Events" for a description of each audit level |
To audit more than one event, add the values of their the audit masks. For example, suppose you want to audit the following three events:
| Event | Audit Level | Value |
|---|---|---|
|
Schema element delete |
0x0004 |
4 |
|
DSE modification |
0x0020 |
32 |
|
Add |
0x0200 |
512 |
|
548 |
||
The total value of the audit levels is 548. The ldapmodify command would therefore look something like this:
ldapmodify -p port -h host << EOF dn: changetype:modify replace: orclauditlevel orclauditlevel: 548 EOF
Restart the directory server instance after any changes are made to orclauditlevel for the changes to take effect.
|
See Also:
"Restarting Directory Server Instances" for instructions on how to restart the directory server |
You can search for audit log entries by using either Oracle Directory Manager or ldapsearch.
To use Oracle Directory Manager to view audit log entries:
cn, you could type the particular common name you want to find.
"Configuring Searches" for instructions on setting the number of entries to display in searches, and to set the time limit for searches
See Also:
The DN for the audit log container is cn=auditlog. To search for audit log entries, perform a subtree or one-level search, with the container object cn=auditlog as the base of the search.
You can use bulkdelete to purge audit log objects under the container cn=auditlog. Run the following command:
bulkdelete.sh -connect net_service_name -base "cn=auditlog"
To view information about any active directory server instance--including type, instance number, debug level, host name, and configuration parameters--use Oracle Directory Manager. To do this:
"Managing Server Configuration Set Entries by Using Oracle Directory Manager" for instructions on changing configuration set entries
See Also:
The Oracle Internet Directory uses a password when connecting to an Oracle database. The default for this password when you install Oracle Internet Directory is ODS. You can change this password by using the OID Database Password Utility.
This section explains concepts about dereferencing alias entries, the usage model, and includes a list of messages.
This section contains these topics:
Alias entries in the LDAP directory enable one entry to point to another entry, so you can devise structures that are not strictly hierarchical. Alias entries perform a function like symbolic links in the UNIX file system or shortcuts in the Windows 95/NT file system.
In Figure 5-4, the ou=uk sales,ou=global sales,o=oracle,c=us entry is an alias entry pointing to the ou=sales,o=oracle,c=uk entry. The pointer (like all information) is held as an attribute, the aliased object name attribute of the alias entry. Alias entries have special object class alias to distinguish them from object entries in a directory.
(2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName)
(2.4.5.1 NAME 'aliasedObjectName" EQUALITY distinguishedNmameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE)
Anyone referencing ou=uk sales,ou=global sales,o=oracle,c=us is automatically rerouted to the real entry ou=sales,o=oracle,c=uk by the LDAP server. This process is called alias dereferencing.
This section contains these topics:
Use the following LDIF to create a normal entry and an alias entry pointing to the real entry. When you add the information in the steps, the tree in Figure 5-5 is the result.
dn: c=us c: us objectclass: country dn: o=oracle, c=us o: oracle objectclass:organization dn: ou=Area1, c=us objectclass: alias aliasedObjectName: o=oracle, c=us dn: cn=John Doe, o=oracle, c=us cn: John Doe objectclass: person dn: cn=President, o=oracle, c=us objectclass: alias aliasObjectName: cn=John Doe, o=oracle, c=us
ldapadd -p <port> -h <host> -f sample.ldif
|
See Also:
Entry Alias Dereferencing Messages for error messages |
In Figure 5-5, the letter A represents an alias entry, where:
A base search finds the top-most level of the alias entry you specify.
For example, perform a base search of "ou=Area1,c=us" with a filter of "objectclass=*" with the -deref option LDAP_DEREF_FINDING as follows:
ldapsearch -p <port> -h <host> -b "ou=Area1,c=us" -a find -s base "objectclass=*"
The directory server, during the base search, looks up the base specified in the search request and returns it to the user if located. If the base is an alias entry and, as in the example, -a find is specified in the search request,then the LDAP server automatically dereferences the alias entry and returns the dereferenced entry. Therefore, the search dereferences ou=Area1,c=us (which is an alias entry) and o=oracle,c=us is returned.
A one-level search finds only the child to the base level you specify.
In each search you specify, there are flags you can set. The search is performed based on the flag you specify.
The flags are as follows:
| Flag | Content |
|---|---|
|
|
|
|
|
|
By default, the dereference flag in ldapsearch is LDAP_DEREF_NEVER (that is, -a never) and thus the LDAP server does not perform any dereferencing for alias entries.
For example, perform a one-level search of "ou=Area1,c=us" with a filter of "objectclass=*" with the -deref option set to LDAP_DEREF_FINDING (-a find) as follows:
ldapsearch -p <port> -h <host> -b "ou=Area1,c=us" -a find -s one "objectclass=*"
The search operation is performed by the LDAP server in two steps.
In the example, -a find is specified in the search request, thus the LDAP server automatically dereferences while looking up the base (the first step), but does not dereference alias entries that are one level under the base. Therefore, the search dereferences ou=Area1,c=us (which is an alias entry) and then looks up one-level entries under o=oracle,c=us. One of the one-level entries is cn=President,o=oracle,c=us that is not dereferenced and is returned as is.
Thus, the search returns cn=President,o=oracle,c=us and cn=John Doe,o=oracle,c=us.
A subtree search finds the base, children, grand children, (the family tree).
In each search you specify, there are flags you can set. The search is performed based on the flag you specify.
The flags are as follows:
| Flag | Content |
|---|---|
|
|
|
|
|
|
By default, the dereference flag in ldapsearch is LDAP_DEREF_NEVER (that is, -a never) and thus the LDAP server does not perform any dereferencing for alias entries.
For example, perform a subtree search of "ou=Area1,c=us" with a filter of "objectclass=*" with the -deref option LDAP_DEREF_FINDING as follows:
ldapsearch -p <port> -h <host> -b "ou=Area1,c=us" -a find -s one "objectclass=*"
The search operation is performed by the LDAP server in two steps.
In the example, -a find is specified in the search request, thus the LDAP server automatically dereferences while looking up the base (the first step), but does not dereference alias entries that are under the base. Therefore, the search dereferences ou=Area1,c=us (which is an alias entry) and then looks up entries under o=oracle,c=us. One of the entries is cn=President,o=oracle,c=us that is not dereferenced and is returned as is.
Thus, the search returns the following:
You can modify alias entries.
For example, create a sample.ldif file with following entries:
dn: cn=President, o=oracle, c=us changetype : modify replace: aliasObjectName aliasObjectName: cn=XYZ, o=oracle, c=us
Modify the alias entry using the following command:
ldapmodify -p <port> -h <host> -f sample.ldif
The following messages are returned when encountering the alias issue in the description column.
|
 Copyright © 1999, 2002 Oracle Corporation. All Rights Reserved. |
|