10g Release 1 (10.1) Part Number B10772-01 |
|
|
View PDF |
This chapter describes the User Migration Utility, which can be use d to perform bulk migrations of database users to an LDAP directory where they are stored and managed as enterprise users. It contain s the following topics:
Migrating from a database user model to an enterprise user model provides solutions to administrative, security , and usability challenges in an enterprise environment. In an enterprise user model, all user information is moved to an LDAP direct ory service.
Enterprise user security provides the ability to easily and securely manage ent erprise-wide users by providing the following benefits:
Because an enterprise user model is easier to manage, security administrators can perform necessary maint enance changes to user information immediately so they have better control over access to critical network resources. In addition, an enterprise user model is easier for users to use because they have fewer passwords to remember so they are less likely to choose eas ily guessed passwords or write them down where others can copy them.
| See Also:
"Introduction to Enterprise User Security" for detailed conceptual infor mation about enterprise user security. |
The User Migration Utility is a command-line utility that is used when enterprise user administra tors decide to move their users from a local database model to an enterprise user model. This utility makes it easy to migrate thousa nds of local and external database users to an enterprise user environment in an LDAP directory where they can be managed from a cent ral location. It uses the Oracle JDBC OCI driver to connect to the database.
Enterprise user administrators can select for migration any combination of the following user subsets in a database:
In addition, enterprise user administrators can specify values for utility parameters that determine how the use rs are migrated such as
The following sections explain the migration process and the changes that occur to users' schemas.
Bulk user migration is a two-phase process. In phase one, you start the migration process by populating use r information into an interface database table, where enterprise user administrators can verify that the information is accurate befo re committing the changes to the database and the directory in phase two. The process is described in the following steps:
In the first part of the migration proc
ess, the utility checks if the ORCL_GLOBAL_USR_MIGRATION_DATA interface table exists in the enterprise user administrato
r's schema. If it exists, then the administrator can choose to reuse the table (clearing its contents), reuse the table and its conte
nts, or re-create the table. Phase one can be run multiple times, each time adding to the interface table. If the table does not exis
t, then the utility creates it in the administrator's schema. The interface table is populated with information about the migrating u
sers from the database and the directory. The command line options used determine what information populates this table.
This is an intermediate step to allow the enterprise user administrat or to verify that the user information is correct in the interface table before committing the changes to the database and the direct ory.
After the interface table user i nformation is checked, then in phase two the utility retrieves the information from the table and updates the directory and the datab ase.
Depending on whether directory entries exist for migrating users, the utility creates r andom passwords as follows:
In either case, after generating the required random passwords, the utility then stores them in the DBPASSWORD an
d DIRPASSWORD interface table columns. The enterprise user administrator can read these passwords from the interface tab
le and inform migrating users.
| See Als
o:
"User Migration Utility Parameters" for a list of command line options and their descriptions. |
This is the interface table which is populated with inform ation about the migrating users during phase one of the bulk user migration process. The information that populates this table is pul led from the database and checked against existing entries in the directory. If there is corresponding information in the directory, then that is marked in the table for that user. After enterprise user administrators verify the information in this table, changes ar e made to the directory and the database in phase two.
|
Caution: The |
| MAPSCHEMA Parameter Setting | CASCADE Parameter Setting | User Migration Successful? | User Schema Objects Dropped? |
|---|---|---|---|
|
PRIVATE |
NO (default setting) |
Yes |
No |
|
SHARED |
NO |
YesFoot 1 |
No |
|
SHARED |
YES |
YesFoot 2 |
Yes |
| See Also:
"User Migration Utility Parameters" for detailed information about the |
Enterprise user s, those that are defined and managed in the directory, can be authenticated to the database either with a password or with a certifi cate. Users that authenticate with a password require an Oracle database password, which is stored in the directory. Users that authe nticate with a certificate must have a valid X.509 v3 certificate.
This utility performs the following steps during migration:
See
Also:
|
The User Migration Utility is automatically installed in the following location when you install Oracle Database Client:
$ORACLE_HOME/rdbms/bin/umu
The following secti ons describe what programs must be running and what user privileges are required to successfully migrate users with the User Migratio n Utility.
To successfully use this utility, enterp rise user administrators must have the following database privileges:
These privileges enable the enterprise user administrator to alter users, drop users, look at dictionary views, and create the in terface table that is used by this utility.
In add ition to the required database privileges, enterprise user administrators must have the directory privileges which allow them to perf orm the following tasks:
Perfo rm the following steps before using the User Migration Utility:
cn=users subtree in the identity management realm.ldap.ora file. Note that the ldap.ora file must include the identity management real
m DN so the utility can locate the correct administrative context. The utility searches for this file under $LDAP_ADMIN,
$ORACLE_HOME/ldap/admin, $TNS_ADMIN, $ORACLE_HOME/network/admin, and, finally, the Domain Nam
e System (DNS) server, if you are using DNS discovery. (See Oracle Internet Directory Administrator's Guide for information about DNS server discovery.)
See Also:
|
To perform a bulk migration of database users to enterprise u sers, use the following syntax:
umu parameter1 parameter2 ...
For parameters that take a single value use t he following syntax:
keyword=value
For parameters that take multiple values, use a colon (:) to separate the values as in the following syntax:
keyword=value1:value2:...
Example 13-1 shows the syntax used to run the utility through both phases of the bulk user migration process.< /p>
umu PHASE=ONE DBADMIN=dba _username:password ENTADMIN=enterprise_admin_DN:password USERS=[ALL_GLOBAL | ALL_EXTERNAL | LIST | FILE] DBLOCATION=database_host:database_port:database_sid < /a>DIRLOCATION=ldap_directory_host:ldap_directory_port USERS LIST=username1:username2:username3:... USERSFILE=filename MAPSCHEMA=[PRIVATE | SHARED]:schema_name MAPTYPE=[DB | DOMAIN]:[ENTRY | SUBTREE] CASCADE=[YES | NO] CONTEX T=user_entries_parent_location LOGFILE=filename PARFILE=filenameumu PHASE=TWO
DBADMIN=dba_username:password ENTADMI N=enterprise_admin_DN:password DBLOCATION=database_host:database_port:database_sid DIRLOCATION =ldap_directory_host:ldap_directory_port LOGFILE=filename PARFILE=filename
|
Note: If the enterprise user adm inistrator does not specify the mandatory parameters on the command line, then the utility will prompt the user for those parameters interactively. |
See Also:
|
To display the command-line synta x for using the User Migration Utility, enter the following command at the system prompt:
um u HELP=YES
While the HELP parameter is set to YE
S, the utility cannot execute.
The foll owing sections list the available parameter keywords and the values that can be used with them when running this utility. The keyword s are not case-sensitive.
|
Valid Values: |
userDN:password |
|
Default Setting: |
<
a name="635172">
No default setting. |
|
Syntax Examples: |
a>
|
|
Description: |
User Distinguish ed Name (UserDN) and the directory password for the enterprise directory administrator with the required privileges for logging in to the directory. UserDN can also be specified within double quotation marks ("..."). |
|
Restrictions: |
This parameter is mandatory. |
|
Valid Values: |
Va lues can be:
This parameter takes multiple values. Separate values with a colon (:). (These values are not case-sensitive.) |
|
Default Setting: |
No default setting. |
|
Syntax Examples: |
|
|
Description: |
Specifies which users are to be migrated. If multiple values are specified for this parameter, then the utility uses the union of these sets of users. |
|
Restrictions: |
This parameter is mandatory for phase one only, and it is ignored in phase two. |
|
Valid Values: < /td> |
Separate user names with a colon (:). |
|
Default Setting: |
<
a name="635240">
No default setting. |
|
Syntax Examples: |
a>
|
|
Description: |
Specifies a list of database users for migration. The users in this list are migrated with
other users that are specified with the |
|
This optional parameter is effective only when |
|
V alid Values: |
Schema type can be:
(These values are not case-sensitive.) |
|
Default Setting: |
<
/a>
|
|
Syntax Examples: |
|
|
Description: |
Spe cifies whether the utility populates the interface table with schema mapping information. |
|
Restrictions: |
|
Valid Values: |
Mapping type can be: Mapping level can be: Separate mapping type from mapping level with a colon (:). (These values are not case-sensitive.) |
|
Default Setting: |
|
|
Syntax Examples: |
|
|
Description: |
Specifies the type of schema mapping that is to be applied when "Keyword: MAPSCHEMA" is set to |
|
Restrictions: |
This parameter is effective only when |
| See Also:
"About Using the SUBTREE Mapping Level Option" for more information about using this mapping level option. |
|
Valid Values: |
(These values are not case-sensitive.) |
|
Default Setting: |
|
|
Syntax Examples: |
a>
|
|
Description: |
Specifies whether a user's local schema is dropped when the user is mapped to a shared schema. |
|
Restrictions: |
<
td class="Simple">
|
Valid Values: |
Distinguished Name (DN) of the par ent for user entries. This is the same as the user search base or user create base in an Oracle Internet Directory identity managemen t realm. Parent DN can also be specified within double quotation marks ("..."). |
|
Default S etting: |
This value is automatically populated from the In 10g Release 1 (10.1), this is not t
he preferred location for user entries, so do not use the default setting for this parameter unless it is specifically desired. Inste
ad, Oracle recommends that you use " |
|
Syntax Examples: |
|
|
Description: |
Spe cifies the DN of the parent entry under which user entries are created in the directory if there is no directory entry that matches t he userID for the user. |
|
Restrictions: |
This parameter is only valid for phase one. |
The following sections contain examples of the syntax for some typical uses of this utility.
To migrate users while retaining their old database schemas, set
the MAPSCHEMA parameter to PRIVATE, which is the default setting. For example, to migrate users scott
1, scott2, and all external database users, while retaining their old schemas, to the directory at c=Users,
c=us with the newly generated database and directory passwords, the syntax shown in Example 
;13-2 is used.
umu PHASE=ONE DBLOCAT ION=machine1:1521:ora_sid DBADMIN= system:manager USERS=ALL_EXTERNAL:LIST USERSLIST=scott1:scott2 DIRLOCATION=mac hine2:636 CONTEXT="c=Users,c=us" E NTADMIN="cn=janeadmin":welcomeumu PHASE=TWO
DBLOCATION=machine1:1521:ora_sid DBADMIN=system:manager DIRLOCATION=machine2:636 ENTADMIN="cn=janeadmin":welcome
Af
ter phase one completes successfully, the interface table is populated with the user migration information. Then the enterprise user
administrator can review the table to confirm its contents. Because no value was specified for the MAPSCHEMA parameter,
the utility runs phase one using the default value, PRIVATE, so all users' old database schemas and objects are retained
.
To migrate users and map them t
o a new shared schema, dropping their old database schemas, set the MAPSCHEMA parameter to SHARED. The shar
ed schema must already exist or the enterprise user administrator must create it before running the utility with this parameter setti
ng. In the following example, users scott1, scott2, and all external database users are migrated to the dir
ectory at c=Users, c=us with newly generated database and directory passwords, while mapping all migrated users to a new
shared schema in the database.
Use the syntax shown in Example
G-1 to run the migration process with MAPSCHEMA set to SHARED.
umu PHASE=ONE DBLOCATION=machine1:1521< /em>:ora_sid DBADMIN=system:manager USERS=ALL_EXTERNAL:LIST USERSLIST=scott1:s cott2 MAPSCHEMA=SHARED:schema_32 DIRLOCATION=machine2:636 CONTEXT="c=Users, c=us" ENTADMIN="cn=janeadmin":welcomeumu PHASE=TWO
DBLOCATION=machine1:15 21:ora_sid DBADMIN=system:manager DIRLOCATION=machine2:636 ENTADMIN= "cn=janeadmin":welcome
After phase one completes successfully, the interface table is populated with the user migration information. Then the admini
strator can review the table to confirm its contents. Users scott1, scott2, and the external users are assi
gned new randomly generated database and directory passwords. Because no value was specified for the CASCADE parameter,
the utility runs phase one using the default value, NO, which means that migrating users who own database objects in the
ir old database schemas will fail and their schemas will not be automatically dropped. To determine which users have failed, review t
he log file that is located at $ORACLE_HOME/network/log/umu.log by default.
The CASCADE parameter setting determines wheth
er users' old database schemas are automatically dropped when mapping to a shared schema during migration. CASCADE can b
e used only when MAPSCHEMA is set to SHARED.
If it is known that no migrating users own database objects or want to retain the objects that they own in their old database
schemas, then setting the CASCADE parameter to YES automatically drops all users' schemas and schema objec
ts and maps them to the new shared schema. Example G-2 shows the syntax to use when setting YES. In this example, users scott1, scott2, and all external database use
rs are migrated to the directory at c=Users, c=us, while mapping all migrating users to a new shared schema in the datab
ase.
umu PHASE=ONE DBLOCATION=< em class="Variable">machine1:1521:ora_sid DBADMIN=system:manager USERS=ALL_EXTERNAL:LIST USERS LIST=scott1:scott2 MAPSCHEMA=SHARED:sch ema_32 CASCADE=YES DIRLOCATION=machine2:636 CONTEXT="c=Users, c=us" ENTADMIN=" cn=janeadmin":welcomeumu PHASE=TWO
DBLOCATION=machine1:1521:ora_sid DBADMIN=system:manager DIRLOCATION=machine2 :636 ENTADMIN="cn=janeadmin" :welcome
After phase one completes succes
sfully, the interface table is populated with the user migration information. Then the administrator can review the table to confirm
its contents. Because the CASCADE parameter is set to YES, all migrated users' old database schemas are automatically dr
opped, including those who own database objects.
When MAPSCHEMA is set to SHARED, the mapping type can be set by specifying a value for the
MAPTYPE parameter. This parameter takes two values, which are the mapping type and the mapping level.
Mapping type can be set at DB, for database, or DOMAIN, for enterprise domain. When mappin
g type DB is specified, the mapping is applied only to the database where the shared schema is stored. When DOMAIN
is specified as the mapping type, then the mapping is applied to the enterprise domain that contains the database where the s
hared schema is stored and also applies to all databases in that domain.
Mapping level can b
e set to ENTRY or SUBTREE. When ENTRY is specified then users are mapped to the shared schema
using their full distinguished name (DN). This results in one mapping for each user. When SUBTREE is specified then grou
ps of users who share part of their DNs are mapped together. This results in one mapping for user groups already grouped under some c
ommon root in the directory tree. Example G-3 shows the syntax to use when using the MAPT
YPE parameter. In this example, users scott1, scott2, and all external database users are migrated t
o the directory at c=Users, c=us, while mapping all migrated users to a new shared schema in the database. In this examp
le, the mapping will apply to the enterprise domain that contains the database and the mapping will be performed at the entry level,
resulting in a mapping for each user.
umu PHASE=ONE DBLOCATION=machine1:1521:or a_sid DBADMIN=system:manager USERS =ALL_EXTERNAL:LIST USERSLIST=scott1:scott2 MAPSCHEMA=SHARED:schema_32 MAPTYPE=DOMAIN:ENTRY DIRLOCATION=< em class="Variable">machine2:636 CONTEXT="c=Users, c=us " ENTADMIN="cn=janeadmin":welcomeumu PHASE=TWO
DBLOCATION=machine1:1521:ora_sid DBADMIN=system:manager DIRLOCATION=machine2:636 ENTADMIN="cn=janeadmin":welcome
If a user (scott, for example) who is being migrated will have
future user entries in a subtree under it, then it makes sense to create a subtree level mapping from this user entry (cn=scot
t) to a schema. However, the database does not interpret the user to be in the subtree so the mapping does not apply to
scott himself. For example, if you are migrating the user scott with the DN cn=scott,o=acme, and you
choose SUBTREE as the mapping level when you run the utility, then a new mapping is created from cn=scott,o=acme<
/code> to the shared schema, but the user directory entry are mapped to the shared schema. Consequently, the scott is not mapped to that schema. Only new users who are created under the <
code>scottSUBTREE mapping level should only b
e specified when user directory entries are placed under other user directory entries, which would be an unusual directory configurat
ion.
If you want an arbitrary subtree user to be mapped to a single shared schema with only one mapping entry, then you must use Enterprise Security Manager to create that mapping.
| See Also:
"Managing Enterprise Domain Database Schema Mappings" for information about using Enterprise Security Manager. |
It is possible to enter user information and User Migration Utility parameters into a text
file and pass the information and parameters to the utility using the PARFILE and USERSFILE parameters. The
LOGFILE parameter sets the directory path for the log file where details about the migration for each user are written.
The PARFILE parameter tells the utility where a text file is located that cont
ains the parameters for a bulk user migration. The USERSFILE parameter works like the PARFILE parameter, ex
cept it contains database users instead of parameters. The parameters and users lists contain one parameter or user for each line. Th
e LOGFILE parameter tells the utility where to write the system events that occur during a user migration, such as error
s. Use the USERSFILE parameter during phase one of the migration process. The PARFILE and LOGFILE parameters can be used in both phases.
Example G-4
shows the syntax for a typical parameter text file to migrate users scott1, scott2, and all external datab
ase users, while retaining their old schemas, to the directory at c=Users, c=us. In this example a log of migration even
ts is written to the file errorfile1 in the directory where the utility is run. If another location is desired, then inc
lude the path with the file name.
DBLOCATION=machine1:1521:ora_sid DBADMIN=system:manager USERS=ALL_EXTERNAL:LIS T:FILE USERSLIST=scott1:scott2 USERSFIL E=usrs.txt DIRLOCATION=machine2:636 CONTEXT="c=Users, c=us" ENTADMIN="cn=janea dmin":welcome LOGFILE=errorfile1
Example G-5 shows the syntax for a typical users li st text file.
user1 user2 user3
To exec ute phase one of the migration process with these parameters and users list text files, use the syntax shown in Example G-6.
umu PHASE=ONE DBADMIN=system:manager PARFILE=par.txt LOGFILE=errorfile2
|
Note: Although the |
Migration failures are reported to the enterprise user administrator with error messages and log mess ages. The following sections describe common error and log messages and what administrators can do to resolve them.
| See Also:
"Summary of User Migration Utility Error and Log Messages" for an alphabetical listing of error and log messages and links to where they are described in this section. |
When the utility encounters any err or while running, it displays an error message and stops running. The following sections describe these messages and explain how to r esolve the errors:
The following error messages may display while the utility is running either phase one or phase two of the migrat ion:
Action: Use Enterprise Security Manager Console to set the nickname attribute for the ide ntity management realm.
Cause: The utility was unable to connect to the database.
Action: Perform these steps:
Cause: The utility encountered a database error.
Action: Check the database error message details for the database.
Cause: The database is not a member of any enterprise domain.
Action: Use Enterprise Security Manager to add the database to an enterprise domain in the directory. p>
Cause: There is no entry for the database in the Oracle con text that the ldap.ora file points to.
Action: Use Database Confi guration Assistant or Enterprise Security Manager to register the database in the directory.
Cause: The utility was unable to connect to the directory.
Action: Perform these steps:
< /dd>Cause: The utility encountered a directory error.
Action: Check the directory error message details for the directory.
< div align="center">| See Also:
Oracle Internet Directory Administrator's Guide f or information about resolving error messages for Oracle Internet Directory. |
Cause: The database belongs to more than one enterprise domain in the directory.
Action: Use Enterprise Security Manager or Oracle Directory Manager to ensure t hat the database belongs to only one enterprise domain.
While the utility is running phase one of the migration, syntax or other types of errors may occur . The following error messages may display while the utility is running phase one of the migration:
Cause: Syntax error. A parameter is missing or has been entered multiple times.
Action: Check the usage syntax.
Cause: The shared schema is not present in the database.
Action: Create the shared schema.
Cause: Syntax error. The utility cannot read the file that contains the users list that is specified in the USERSFILE parameter.
Action: Perform these steps:
Cause: Syntax error. The utility cannot read the file that contains the list of para meters that is specified in the PARFILE parameter.
Action: Perfor m these steps:
Cause: Syntax error. The utility is unable to read the local host name for the database location or the directory location.
Action: Explicit
ly enter the hostname information with the DBLOCATION and DIRLOCATION parameters.
Cause: The interface table cannot be created in the SYS schema.
p>
Action: Specify another user in the DBADMIN parameter
.
| See Also:
"Keyword: DBADMIN" for information about
setting the |
Cause: Syntax error. The argument name or value has been entered incorrectly.
Action: Check the usage syntax.
See Als
o:
For information about using the command line syntax for this utility. | <
/tr>
Cause: Syntax error. This occurs when you have used a command line argument that is o nly intended for phase one, but you are running phase two.
Action: Check the usage syntax.
Cause: Syntax error. The user that is specified in this err
or message is invalid because they are not a user in the database that is specified in the DBLOCATION parameter.
Action: Remove the invalid user from the file that is specified with the
USERSFILE parameter.
Cause: Syntax error. The file that
is specified in the USERSFILE parameter contains the user who is running the migration utility.
Action: Remove that user from the file.
Cause: Syntax error. The user that is specified in this error message is invalid because they are not a user in the database that is
specified in the DBLOCATION parameter.
Action: Remov
e the invalid user from the USERSLIST parameter.
Cause:
Syntax error. The USERSLIST parameter contains the user who is running the migration utility.
Action: Remove that user from the USERSLIST.
Cause: Syntax error. The utility cannot find the log file or it cannot open the file to write to it.
Action: Perform these steps:
Cause: The CONTEXT entry is not present in the directory.
Action: Perform one of the following options:
Most of the error messages that you encounter while running this utility occur in phase one. After phase one has completed successfully, and while phase two is running, the follo wing error may occur:
Cause: The utility cannot find th e interface table.
Action: Perform one of the following options:< /p>
Typically, log messages are written to the log file for each user who is migrated, whether the user was migrated successfully or not. The following sections describe these messages and explain how to resolve the err ors:
While the utility is running phase one of the migration, messages that indicate a user's information has not been successfully populated in the interface table may be written to the log file. After the utility completes phase one, review the log file to check for the following messages:
Cause: The nickname attribute matches multiple users or the user matches with multipl e nickname attributes.
Action: Resolve the multiple matches and r un the utility again for the users whose log file entry displayed this message.
Cause: No entry was found for the nickname matching, but an entry already exists for the DN in the directory.
Action: Specify a different DN for the user.
While the utility is runni ng phase two of the migration, messages that indicate a user has not successfully migrated may be written to the log file. After the utility completes phase two, review the log file to check for the following messages:
This message typically occurs with the message Invalid value::<c
olumn_name>=<column_value>.
Cause: The entry
already contains a value for the orclPassword attribute.
Act
ion: Check the DBPASSWORD_EXIST_FLAG column in the interface table for a T/F value that correctly
reflects whether a database password exists for this user.
This message typically occurs with
the message Invalid value::<column_name>=<column_value>.
Cause: The orclPassword attribute of this user's entry has a null value.
Action: Check the DBPASSWORD_EXIST_FLAG column in the interface table for a <
code>T/F value that correctly reflects whether a database password exists for this user.
Cause: The shared schema that was specified for this user does not exist in the database.
Action: Perform one of the following options:
SHARED_SCHEMA column of the interface table and run phase two of the u
tility for this user again.This message typically occurs with the message
Invalid value::<column_name>=<column_value>.
Actio
n: Check the USERDN_EXIST_FLAG column in the interface table for a T/F value that correctly reflec
ts whether a user entry already exists in the directory for this DN.
Cause: The value in the interface table column for this user is invalid. Typically, this message is a ccompanied by additional log messages for this user.
Action: Chec k to ensure that the correct value has been entered for this user.
This message typically occ
urs with the message Invalid value::<column_name>=<column_value>.
Cause: The entry for the DN is missing in the directory.
Action: Check the USERDN_EXIST_FLAG column in the interface table for a T/F value th
at correctly reflects whether a user entry already exists in the directory for this DN.
Table G-4 and Table G-5 list all of the error and log messages in alphabetical order and provides links to the sect ion in this chapter that describes the message and how to resolve it.
| User Migration Utility Error Message | Phase |
|---|---|
|
1 | |
|
Both |
tr>
|
|
B oth | |
|
Both | |
|
Both | |
|
Database not registered with th e directory : : DB-NAME = < dbName > |
Both |
|
Database object missing : : SHARED-SCHEMA = <shared_schema_name > |
1 |
|
2 |
|
|
B oth | |
|
Both | |
|
Error reading file : : < file_name > : : < io_error_message > |
1 |
|
Error reading file : : PARFILE = < file_name > : : < io_error_message> |
1 |
|
1 | |
|
1 | |
|
1 | |
|
1 < /td> | |
|
1 | |
|
1 | |
|
1 | |
|
Invalid value : : & lt; user > [ USERSLIST ] { = = DBADMIN } |
< p class="TB">1 |
|
1 | |
|
Both | |
|
1 |
| User Migration Utility Log Message | Phase |
|---|---|
|
2 | |
|
2 | |
|
Database object missing : : SHARED-SCHEMA = < shared_schema > |
2 |
|
2 | |
|
Invalid value : : <inte rface_table_column_name> = < interface_table_column_value > |
2 |
|
Multiple entries found : : < nickname_attribute > = < username >< a href="asoappg.htm#636044"> |
1 |
|
2 |
|
|
No entry found : : < nickname_attribute > = < username > : : Entry found : DN = < dn > |
1 |