After you have made the changes, click Apply.

29-26 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory The policy requirements for c=us are as follows: ■ Users can browse and read their information. ■ The user security admin can modify the information under c=us except for passwords and ACPs. ■ The security admin group can modify policies under c=us. ■ The global password admin and the user can reset a password. ■ All other users have no permissions. ■ This policy cannot be overridden. Required ACP: Access to entry DenyGroupOverride by dn=.,c=us browse,noadd,nodelete by group=cn=User admin group,cn=users,c=us browse,add,delete Access to attr=orclaci DenyGroupOverride by group=cn=security admin group,cn=users,c=us search,read,write,compare by none Access to attr=userpassword DenyGroupOverride by self search,read,write,compare by group=cn=password admin group search,read,write,compare by none Access to attr= DenyGroupOverride by self search,read,nowrite,compare by group=cn= User admin group,cn=users,c=us search,read,write,compare by none User admin group for this naming context cn= user admin group, cn=users,c=us Security admin group or this naming context cn= security admin group, cn=users,c=us Global password admin group for all naming contexts that reset passwords cn=password admin group Table 29–5 Cont. DNs Used in Example Container DN 30 Managing Password Verifiers 30-1 30 Managing Password Verifiers Password verifiers are the security credentials used to authenticate users to Oracle Internet Directory and other Oracle components. This chapter explains how Oracle Internet Directory centrally stores these password verifiers. This chapter contains these topics: ■ Introduction to Password Verifiers for Authenticating to the Directory ■ Managing Hashing Schemes for Password Verifiers for Authenticating to the Directory ■ Introduction to Password Verifiers for Authenticating to Components ■ Managing Password Verifier Profiles for Oracle Components by Using ODSM ■ Managing Password Verifier Profiles for Components by Using Command-Line Tools ■ Introduction to Generating Verifiers by Using Dynamic Parameters ■ Configuring Oracle Internet Directory to Generate Dynamic Password Verifiers Introduction to Password Verifiers for Authenticating to the Directory When a user leaves a company or changes jobs, that users privileges should change the same day to guard against misuse of old or unused accounts and privileges. Without centralized password administration, an administrator in a large enterprise with user accounts and passwords distributed over many databases may not be able to make the changes as quickly as good security requires. Oracle Internet Directory centrally stores security credentials to make their administration easy for both end users and administrators. It stores: ■ Passwords for authenticating users to the directory itself ■ Password verifiers for authenticating users to other Oracle components Users can store non-Oracle authentication credentials if the non-Oracle applications are directory enabled. These applications must create their own container under the Products entry. Oracle Internet Directory stores a users directory password in the userPassword attribute. You can protect this password by storing it as a Base64 encoded string of a one-way hashed value by using one of Oracle Internet Directorys supported hashing algorithms. Storing passwords as one-way hashed values—rather than as encrypted values—more fully secures them because a malicious user can neither read nor decrypt them. 30-2 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory The default userPassword hashing algorithm for Oracle Internet Directory has been changed from MD4 to SHA. This default scheme is in effect for new installations only. All userPassword attributes created after a new install are one-way hashed using SHA, then stored in Oracle Internet Directory. When you perform an upgrade, the default hashing scheme in effect before upgrade is retained. For example, if the default scheme before the upgrade was MD4, then MD4 remains the default scheme after the upgrade. To ensure greater security of userPasswords, change the default scheme to SHA immediately after the upgrade. When you change the default scheme to SHA, user login is unaffected. For greater security, require users to reset their passwords so that SHA values hash values are stored in Oracle Internet Directory. Oracle Internet Directory stores the user password in a reversible encrypted format in a configuration attribute called orclrevpwd. This attribute is generated only if the attribute orclpwdencryptionenable in the password policy entry is set to 1. The orclrevpwd attribute is maintained securely within the server and cannot be queried. This section contains these topics: ■ Userpassword Verifiers and Authentication to the Directory ■ Hashing Schemes for Creating Userpassword Verifiers ■ Managing Hashing Schemes for Password Verifiers for Authenticating to the Directory Userpassword Verifiers and Authentication to the Directory Oracle Internet Directory can protect a users directory password by storing it in the userPassword attribute as a one-way hashed value. You select the hashing algorithm you want to use. Storing passwords as one-way hashed values—rather than as encrypted values—more fully secures them because a malicious user can neither read nor decrypt them. During authentication to a directory server, clients supply a password to the directory server in clear text. The directory server hashes this password by using the hashing algorithm specified in the DSE attribute orclcryptoscheme. It then verifies it against the hashed password stored in the binding entrys userPassword attribute. If the hashed password values match, then the server authenticates the user. If they do not match, then the server sends the user an Invalid Credentials error message. For external users, Oracle Internet Directory generates the attribute orclrevpwd during authentication. In particular this attribute is generated when clients authenticate using ldapcompare on the users cleartext password. If the attribute orclrevpwd does not exist, then the Oracle Internet Directory server generates this attribute using the cleartext password provided for authentication. However this attribute is not generated if external users are authenticated against Oracle Internet Directory using ldapbind Hashing Schemes for Creating Userpassword Verifiers During installation, Oracle Identity Management 11g Installer sets the one-way hashing scheme for protecting user passwords to the directory to SHA. This value is Note: For even greater security, three variants of the more secure SHA-2 algorithm, as well as salted versions of those variants, are available, as of 11g Release 1 11.1.1.4.0. Managing Password Verifiers 30-3 stored in the orclCryptoScheme attribute in the root DSE. You can change that value to any of the following hashing schemes: ■ MD4: A one-way hash function that produces a 128-bit hash, or message digest ■ MD5: An improved and more complex version of MD4 ■ SHA-1: Secure Hash Algorithm, which produces a 160-bit hash, longer than MD5. The algorithm is slightly slower than MD5, but the larger message digest makes it more secure against brute-force collision and inversion attacks. Potential vulnerabilities have been found in SHA-1 ■ SSHA: Salted Secure Hash Algorithm. This is similar to SHA, but is generated by using a random salt with the password. ■ SHA256, SHA384, SHA512: Variants of the more secure SHA-2 algorithm. The numbers refer to the digest sizes of the hash functions. ■ SSHA256, SSHA384, SSHA512: Salted versions of the three SHA-2 algorithms. ■ SMD5: Salted MD5. This is similar to MD5, but is generated by using a random salt with the password. ■ UNIX Crypt: The UNIX hashing algorithm ■ None: Passwords are stored in clear text. See Managing Hashing Schemes for Password Verifiers for Authenticating to the Directory on page 30-3 and Managing System Configuration Attributes by Using ODSM Data Browser on page 9-18. Managing Hashing Schemes for Password Verifiers for Authenticating to the Directory The following example changes the password hashing algorithm to SHA512 by using an LDIF file named my_ldif_file: ldapmodify -D cn=orcladmin -q -h myhost -p 3060 -v -f my_ldif_file The LDIF file, my_ldif_file, contains: dn: changetype: modify replace: orclcryptoscheme orclcryptoscheme: SHA512 Introduction to Password Verifiers for Authenticating to Components Oracle components store both passwords and password verifiers in Oracle Internet Directory. This section contains these topics: Note: In the past Oracle Internet Directory supported the DES variant of UNIX Crypt. In 11g Release 1 11.1.1 Oracle Internet Directory has the capability to understand the MD5 and Blowfish variants of UNIX Crypt. This means pre-hashed passwords using these other variants can be imported into Oracle Internet Directory as-is and will continue to work. However, selecting UNIX Crypt as orclcryptoscheme will continue to only generate the DES variant of UNIX Crypt. 30-4 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory ■ About Password Verifiers for Authenticating to Oracle Components ■ Attributes for Storing Password Verifiers for Authenticating to Oracle Components ■ Default Verifiers for Oracle Components ■ How Password Verification Works for an Oracle Component ■ Managing Password Verifier Profiles for Oracle Components by Using ODSM ■ Managing Password Verifier Profiles for Components by Using Command-Line Tools About Password Verifiers for Authenticating to Oracle Components Oracle components can store their password values in Oracle Internet Directory as password verifiers. A password verifier is a hashed version of a clear text password, which is then encoded as a BASE64 encoded string. You can choose one of these hashing algorithms to derive a password verifier: ■ MD5: An improved, and more complex, version of MD4 ■ SHA-1: Secure Hash Algorithm, which produces a 160-bit hash, longer than MD5. The algorithm is slightly slower than MD5, but the larger message digest makes it more secure against brute-force collision and inversion attacks. ■ SSHA and SMD5 ■ SHA256, SHA384, SHA512: Variants of the more secure SHA-2 algorithm. The numbers refer to the digest sizes of the hash functions. ■ SSHA256, SSHA384, SSHA512: Salted versions of the three SHA-2 algorithms. ■ UNIX Crypt: The UNIX hashing algorithm ■ SASLMD5: Simple Authentication and Security LayerMD5, which adds authentication support to connection-based protocols and uses a challenge-response protocol. ■ O3LOGON: A proprietary Oracle algorithm for generating verifiers. It is similar to SASLMD5 in that it uses a challenge-response protocol. ■ ORCLWEBDAV: A proprietary algorithm identical to SASLMD5 which takes the user name in the format usernamerealm. ■ ORCLLM: Oracles representation of the SMBLM algorithm. The SMBLM algorithm is Oracles representation of the LM variant of the SMBCIFS challengeresponse authentication algorithm. ■ ORCLNT: Oracles representation of the SMBNT algorithm. The SMBNT algorithm is Oracles representation of the NT variant of the SMBCIFS challengeresponse authentication algorithm. During Oracle application installation, the Oracle Identity Management 11g Installer creates for that application a password verifier profile entry containing all the necessary password verification information. It places this entry, as shown in Figure 30–1 , immediately below the application entry, which resides under the products entry, which, in turn, resides under the realm-specific Oracle Context. This verifier profile entry is applicable to users in the specified realm only. For verifier generation to take effect, you must set the orclcommonusersearchbase attribute in the common entry of the realm-specific Oracle context to the appropriate value. Managing Password Verifiers 30-5 Figure 30–1 Location of the Password Verifier Profile Entry Attributes for Storing Password Verifiers for Authenticating to Oracle Components Both the directory and Oracle components store the user password in the user entry, but in different attributes. Whereas the directory stores user passwords in the userPassword attribute, Oracle components store user password verifiers in the authPassword, orclPasswordVerifier, or orclpassword attribute. Table 30–1 describes each of the attributes used by Oracle components. Table 30–1 Attributes for Storing Password Verifiers in User Entries Attribute Description authPassword Attribute for storing a password to an Oracle component when that password is the same as that used to authenticate the user to the directory, namely, userpassword. The value in this attribute is synchronized with that in the userpassword attribute. Several different applications can require the user to enter the same clear text password used for the directory, but each application may hash it with a different algorithm. In this case, the same clear text password can become the source of several different password verifiers. This attribute is multivalued and can contain all the other verifiers that different applications use for this users clear text password. If the userpassword attribute is modified, then the authpasswords for all applications are regenerated. orclPasswordVerifier Attribute for storing a password to an Oracle component when that password is different from that used to authenticate the user to the directory, namely, userpassword. The value in this attribute is not synchronized with that in the userpassword attribute. Like authPassword, this attribute is multivalued and can contain all the other verifiers that different applications use for this users clear text password. Password Verifier Profile Entry Password Verifier Profile Entry Password Verifier Profile Entry Subscriber or Default Subscriber Oracle Context Application 1 Application 2 Application 3 Products Groups 30-6 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory Each of these attribute types has appID as an attribute subtype. This attribute subtype uniquely identifies a particular application. For example, the appID can be the ORCLGUID of the application entry. This attribute subtype is generated during application installation. In Figure 30–2 on page 30-7, various Oracle components store their password verifiers in Oracle Internet Directory. Oracle Single Sign-On uses the same password as that for the directory, and hence stores it in the authPassword attribute.The other applications use different passwords and hence store their verifiers in orclPasswordVerifier attribute. The following is an example of an application-specific verifier profile entry. Any application that chooses not to use the common verifier framework must create its own verifier profile entry, similar to the one given in the following example. The orclappid is set to the GUID of the application container and it will also be used as a subtype in the verifier attributes authpassword and orclpasswordverifier. dn: cn=IFSVerifierProfileEntry,cn=IFS,cn=Products,cn=OracleContext,o=Oracle,dc=com objectclass:top objectclass:orclpwdverifierprofile cn:IFSVerifierProfileEntry orclappid:8FF2DFD8203519C0E034080020C34C50 orclpwdverifierparams;authpassword: crypto:SASLMDS realm:dc=com orclpwdverifierparams;orclpasswordverifier: crypto:ORCLLM orclpwdverifierparams;authpassword: crypto:ORCLWEBDAV realm:dc=com usernameattribute: mail usernamecase: lower nodomain: TRUE SASLMD5 and ORCLWEBDAV verifiers are generated by using user name, realm, and password. The user name attribute to be used can be specified in the verifier profile entry. The case of the user name can also be specified as either upper or lower. The ORLWEBDAV verifier is generated by appending the name of the identity management realm to the user name. If this is not required, then the verifier profile entry must specify nodomain: TRUE. In the previous example, ORCLWEBDAV verifier is generated by using the value of the mail attribute without appending the name of the realm. Also, the user name is converted to lowercase before generating the verifier. orclPassword Attribute for storing only the 03LOGON verifier for enterprise users. The 03LOGON verifier is synchronized with the userpassword attribute, and it is generated by default for all user entries associated with the orcluserv2 object class. When Oracle Internet Directory is installed, a database security profile entry is created by default in the Root Oracle Context. The presence of this entry triggers the generation of 03LOGON verifiers for user entries associated with the orcluserv2 object class. Table 30–1 Cont. Attributes for Storing Password Verifiers in User Entries Attribute Description Managing Password Verifiers 30-7 Figure 30–2 Authentication Model This illustration shows the authentication model used in password storage. At the center is an OID Password Store. To the right are applications 1, 2, and 3, each of which authenticates to the directory by way of Oracle9iAS Single Sign-On. The latter connects to the directory by way of a secure channel. On the other side of the OID Password Store, a database, three applications, and the directory administrator authenticate directly to the OID Password Store. Default Verifiers for Oracle Components To save you from having to create a profile for each Oracle component, and to enable sharing of password verifiers across all components, Oracle Internet Directory provides a default set of password verifiers. The default verifier types are MD5, MD5-IFS SASLMD5 with the user name set to the value of the nickname attribute and realm = Authorized_Users, WEBDAV, ORCLLM, and ORCLNT. Two profile entries are required: one for applications using personal identification numbers PINs, which use numeric values only, and another for applications using alphanumeric passwords. The verifiers for PIN-based applications—for example, the voice mail application in OracleAS Unified Messaging—are stored in the orclpasswordverifier;orclcommonpin attribute. The subtype orclcommonpin is used to distinguish numeric PINs from alphanumeric passwords. Application 4 OID Password Store Secure channel Application 1 Application 2 Oracle Application Server Single Sign-On Application 3 Database Application 5 Application 6 Directory Administration: Application Administration, Delegation, and Provisioning User Transfer and Migration Secure channel Secure channel Secure channel Secure channel Secure channel 30-8 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory Any application that uses numeric PINs can directly query or compare against the attribute orclpasswordverifier;orclcommonpin. The verifiers for alphanumeric password-based applications can be stored in either: ■ The authpassword;orclcommonpwd attribute—If an application requires its verifier to be synchronized with the userpassword attribute ■ The orclpasswordverifier;orclcommonpwd attribute—If synchronization with the userpassword attribute is not required The subtype orclcommonpwd is used to distinguish alphanumeric passwords from numeric PINs. The verifier attributes subtyped by orclcommonpwd can be queried against. These profile entries also contain the list of subscribed applications and these are specified as values in the uniquemember attribute in the profile entries. By default, the DN of the Oracle Single Sign-On identity is one of the subscribed applications. This means that Oracle Single Sign-On is a proxy member for all its partner applications. All applications not based on Oracle Single Sign-On must add their identities DNs to the uniquemember attribute in the appropriate profile entry. The following is an example of the profile entries. Cn=defaultSharedPwdProfileEntry, cn=common, cn=products, cn=oraclecontext Objectclass: orclpwdverifierprofile Objectclass: orclcommonpwdprofile Cn: defaultSharedPwdProfileEntry Orclappid: orclcommonpwd Orclpwdverifierparams;authpassword: crypto:SASLMD5 realm:Authorized_Users Orclpwdverifierparams;authpassword: crypto:ORCLWEBDAV realm:Authorized_Users Orclpwdverifierparams;authpassword: crypto:ORCLLM Orclpwdverifierparams;authpassword: crypto:ORCLNT Orclpwdverifierparams;orclpasswordverifier: crypto:SSHA Uniquemember: cn=SSO,cn=Products,cn=OracleContext Uniquemember: cn=IFS,cn=Products,cn=OracleContext Cn=defaultSharedPINProfileEntry, cn=common, cn=products, cn=oraclecontext Objectclass: orclpwdverifierprofile Objectclass: orclcommonpwdprofile Cn: defaultSharedPinProfileEntry Orclappid: orclcommonpin Orclpwdverifierparams;orclpasswordverifier: crypto:MD5 Orclpwdverifierparams;orclpasswordverifier: crypto:SSHA Uniquemember: cn=SSO,cn=Products,cn=OracleContext Uniquemember: cn=Unified Messaging,cn=Products,cn=OracleContext For PIN-based applications, authpassword is not an option. Such applications use the orclpasswordverifier attribute. How Password Verification Works for an Oracle Component Figure 30–3 shows an example of password verification for an Oracle component. In this example, the Oracle component stores its password verifiers in the directory. Managing Password Verifiers 30-9 Figure 30–3 How Password Verification Works 1. The user tries to log in to an application by entering a user name and a clear text password. 2. The application sends the clear text password to the directory server. If the application stores password verifiers in the directory, then the application requests the directory server to compare this password value with the corresponding one in the directory. 3. The directory server: a. Generates a password verifier by using the hashing algorithm specified for the particular application b. Compares this password verifier with the corresponding password verifiers in the directory. For the compare operation to be successful, the application must provide its appID as the subtype of the verifier attribute. For example: ldapcompare -p 3060 -D DN_of_the_appplication_entity -q \ -b DN_of_the_user -a orclpasswordverifier; appID \ -v password_of_the_user c. Notifies the application of the results of the compare operation. 4. Depending on the message from the directory server, the application either authenticates the user or not. If an application does not use the compare operation, then it: 1. Hashes the clear text password entered by the user 2. Retrieves from the directory the hashed value of the clear text password as entered by the user 3. Initiates a challenge to the user to which the client responds. If the response is correct, then the application authenticates the user. Managing Password Verifier Profiles for Oracle Components by Using ODSM You can use Oracle Directory Services Manager to view and modify password verifier profile entries, including password hashing schemes. To view and modify an applications password verifiers: Oracle Internet Directory Application user 1 2 3 6 30-10 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory 1. Invoke Oracle Directory Services Manager and connect to the Oracle Internet Directory server as described in Invoking Oracle Directory Services Manager on page 7-9.

2. From the task selection bar, select Security.

3. Expand Password Verifier in the left pane. All of the password verifiers appear in

the left pane. 4. Select the password verifier you want to view. The right pane displays the Password Verifier Profile tab page. 5. You can modify the hashing algorithm used to generate a password verifier. In the Password Verifier Profile dialog box, specify the hashing algorithm in the Oracle Password Parameters field. The syntax is: crypto:hashing_algorithm For example, if you are using the ORCLLM hashing algorithm, then you would enter: crypto:ORCLLM If you are using SASLMD5, for example, you can enter the following: crypto:SASLMD5 realm:dc=com Managing Password Verifier Profiles for Components by Using Command-Line Tools You can view and modify password verifier profiles by using command-line tools. Viewing a Password Verifier Profile by Using Command-Line Tools To view an applications password verifier, perform a search specifying the DN of the password verifier profile. Example: Modifying a Password Verifier Profile by Using Command-Line Tools This example changes the hashing algorithm in an application password verifier profile entry. This password verifier synchronizes with the users directory password. Type: ldapmodify -D cn=orcladmin -q -p 3060 -h my_host -v -f file.ldif where file.ldif contains: dn: cn=MyAppVerifierProfileEntry,cn=MyApp,cn=Products,cn=OracleContext, o=my_company,dc=com changetype: modify replace: orclPwdVerifierParams orclPwdVerifierParams;authPassword: crypto:SASLMD5 realm:dc=com Introduction to Generating Verifiers by Using Dynamic Parameters The password verifiers described previously are static password verifiers. That is, they are generated with preconfigured parameters, typically during application installation. Some applications, including Oracle Calendar, Oracle Email, and Oracle Wireless and Voice, require Oracle Internet Directory to generate dynamic password verifiers. Managing Password Verifiers 30-11 Oracle Internet Directory generates a dynamic password verifier when an application requests one. Dynamic verifiers are based on application parameters that are not available until run time. In order to generate a dynamic password verifier, Oracle Internet Directory needs a user password that was previously stored in a reversible encrypted format. Oracle Internet Directory stores such values in the configuration attributes orclrevpwd and orclunsyncrevpwd. Encrypted values based on userpassword are stored in the parameter orclrevpwd. Encrypted values based on passwords other than userpassword, such as the numeric PINs used by Oracle Calendar, are stored in the parameter orclunsyncrevpwd. Configuring Oracle Internet Directory to Generate Dynamic Password Verifiers If you are deploying applications that use userpassword and that need dynamic password verifiers, you must ensure that Oracle Internet Directory generates the orclrevpwd parameter. Oracle Internet Directory generates the attribute orclrevpwd when you provision a user if the attribute orclpwdencryptionenable in the realm password policy entry is set to 1. Therefore, you must set orclpwdencryptionenableto 1 before you provision users. To check the value of orclpwdencryptionenable, you can use ldapsearch to query the pwdpolicy entry effective on the entry being examined. For example, to query the default pwdpolicy, you would type: ldapsearch -p port -q -D cn=orcladmin \ -b cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext \ -s base objectclass= If orclpwdencryptionenable is not listed or is equal to 0, set it to 1 by using ldapmodify with an LDIF file similar to this: dn: cn=DefaultSharedPinProfileEntry,cn=Common,cn=Products,cn=Oraclecontext cn: DefaultSharedPinProfileEntry orclappid: orclpwdencryptionenable orclpwdencryptionenable: 1 Alternatively, if users were provisioned before you set orclpwdencryptionenable, all users must reset their user passwords to trigger the generation of the encrypted value. If you are deploying applications that use a numeric PIN and that need dynamic password verifiers, you must ensure that Oracle Internet Directory can use the crypto type 3DES in order to generate the value stored in orclunsyncrevpwd. You must specify 3DES as a value of the attribute orclpwdverifierparams;orclpasswordverifier in the common verifier profile entry under the root oracle context. The default DN of this entry is cn=DefaultSharedPINProfileEntry,cn=Common,cn=Products, cn=OracleContext. To set the value, you would use the following LDIF file: dn: cn=DefaultSharedPinProfileEntry,cn=Common,cn=Products,cn=Oraclecontext cn: DefaultSharedPinProfileEntry orclappid: orclcommonpin orclpwdverifierparams;orclpasswordverifier: crypto:MD5 orclpwdverifierparams;orclpasswordverifier: crypto:3DES Use a command-line such as: 30-12 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile 31 Delegating Privileges for Oracle Identity Management 31-1 31 Delegating Privileges for Oracle Identity Management This chapter explains how to store all the data for users, groups, and services in one repository, and delegate the administration of that data to various administrators. It also explains the default security configuration in Oracle Internet Directory. This chapter contains these topics: ■ Introduction to Delegating Privileges for Oracle Identity Management ■ Delegating Privileges for User and Group Management ■ Delegating Privileges for Deployment of Oracle Components ■ Delegating Privileges for Component Run Time Introduction to Delegating Privileges for Oracle Identity Management Oracle Identity Management enables you to store all the data for users, groups, and services in one repository, and to delegate a particular administrator for each set of data. By providing both a centralized repository and customized delegated access, Oracle Identity Management is both secure and scalable. This section contains these topics: ■ How Delegation Works ■ Delegation in an Oracle Fusion Middleware Environment ■ About the Default Configuration ■ Privileges for Administering the Oracle Technology Stack How Delegation Works Using the delegation model, a global administrator can delegate to realm administrators the privileges to create and manage the identity management realms for hosted companies. Realm administrators can, in turn, delegate to end users and groups the privileges to change their application passwords, personal data, and preferences. Each type of user can thus be given the appropriate level of privileges. Note: All references to Oracle Delegated Administration Services in this chapter refer to Oracle Delegated Administration Services 10g 10.1.4.3.0 or later. 31-2 Oracle Fusion Middleware Administrators Guide for Oracle Internet Directory To delegate the necessary privileges, you assign the user to the appropriate administrative group. For example, suppose that you store data for both enterprise users and the e-mail service in the directory, and must specify a unique administrator for each set of data. To specify a user as the administrator of enterprise users, you assign that user to, say, the Enterprise User Administrators Group. To specify a user as the administrator of the e-mail services, you assign that user to, say, the E-mail Service Administrators Group. Delegation in an Oracle Fusion Middleware Environment Figure 31–1 shows the flow of delegation in an Oracle Fusion Middleware environment. Figure 31–1 Delegation Flow in an Oracle Fusion Middleware Environment As Figure 31–1 on page 31-2 shows, in an Oracle Fusion Middleware environment the directory superuser cn=orcadmin creates: ■ The Oracle Context ■ The realm Oracle Internet Directory Superuser cn=orcladmin · Creates Oracle Context · Creates Realm · Creates Realm Oracle Context Realm Administrator cn=orcladmin, cn=users, Enterprise DN Oracle Context Administrators Oracle Application Server Administrators you can have an administrator for each component · Install components · Manage component security and configuration User and Group Administrators Create users and groups These administrators can also grant user and group administrator privileges to other users. Creates Delegates Oracle Context administration to Delegates Application Server administration to Delegates user and group administration to Delegating Privileges for Oracle Identity Management 31-3 ■ The realm-specific Oracle Context ■ The entry for the realm administrator cn=orcladmin, cn=users, Enterprise DN The realm administrator, in turn, delegates administration of the Oracle Context to specific users by assigning those users to the Oracle Context Administrators Group. Oracle Context Administrators then delegate administration of the Oracle Application Server to one or more users by assigning them to the Oracle Fusion Middleware Administrators Group. The Oracle Fusion Middleware Administrators install and administer Oracle Fusion Middleware components and delegate administration of user and group data to the User and Group Administrators group. The User and Group Administrators create users and groups. They can also grant user and group administrator privileges to other users. About the Default Configuration When you first install Oracle Internet Directory, the default configuration establishes access control policies at various points in the directory information tree DIT. Default access controls are placed on the User and Group containers as described later in this chapter. Likewise, default privileges for specific directory entities are discussed later in this chapter. In addition, certain default privileges are granted to Everyone and to each user as described in Table 31–2 . You can customize this default configuration to meet the security requirements of your enterprise. Privileges for Administering the Oracle Technology Stack Administering the Oracle technology stack requires the privileges described in Table 31–2 . Table 31–1 Default Privileges Granted to Everyone and to Each User Subject Default Privileges Everyone The following privileges at the Root DSE: ■ Permission to browse user entries ■ Search, read, and compare access for all user attributes except the following userpkcs12, orcluserpkcs12hint, userpassword, orclpassword, and orclpasswordverifier Each user Complete access to his or her own attributes—including the userpassword, orclpassword, and orclpasswordverifier attributes.