Skip Headers
Oracle® Access Manager Installation Guide
10g (10.1.4.3)
E12493-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Index
Index
Go to Feedback page
Contact Us

Previous
Previous
 
Next
Next
 

A Installing Oracle Access Manager with Active Directory

This chapter summarizes prerequisites, installation, and set up for Oracle Access Manager with Active Directory. The following topics are included:

Some introductory information is included for configurations that use both LDAP (the default), LDAP over SSL, and the optional Active Directory Services Interface (ASDI) as the communication protocol between Oracle Access Manager and Active Directory.

The Oracle Access Manager Identity and Common Administration Guide also includes details about:

A.1 About Active Directory

This discussion provides a general overview of Active Directory in broad strokes. See also, "About Oracle Access Manager and Active Directory". Active Directory stores information about objects in one or more domains on a network and makes this information available to users and network administrators.

An Active Directory that supports multiple trees or domains is called an Active Directory forest. Active Directory uses a structured data store as the basis for a logical, hierarchical organization of directory information. The Active Directory includes:

An Active Directory that supports multiple trees or domains is called an Active Directory forest. Active Directory uses a structured data store as the basis for a logical, hierarchical organization of directory information. The Active Directory includes:

A.1.1 Domain Controllers and Partitions

Every Active Directory server (domain controller) in an Active Directory forest participates in replication and contains a complete copy of all directory information for their domain. Any change to directory data is replicated to all domain controllers within the domain. Every domain controller in an Active Directory forest stores three full, writable directory partitions. In Active Directory, a directory partition is a contiguous Active Directory subtree that is replicated as a unit to other domain controllers in the forest that contain a replica of the same subtree.

A single domain controller always holds at least three directory partitions:

  • Schema: one schema for each forest with class and attribute definitions for the directory

  • Configuration: one for each forest with replication topology and related metadata

  • Domain: many in a forest with a subtree that contains the per-domain objects for one domain

A.2 About Oracle Access Manager and Active Directory

Oracle Access Manager supports Active Directory on Windows Server 2000 and Windows 2003 Server platforms. On a server running Windows Server 2003, Web Edition:

Oracle Access Manager supports storing user data on a separate directory server type from configuration and policy data. For more information, see "Data Storage Requirements" and details about "ADSI Option Considerations". With Oracle Access Manager, use of the Global Catalog is not required.Oracle Access Manager supports structural and auxiliary object classes. A structural object class can stand on its own and contains basic attributes required for use within Oracle Access Manager applications. A structural object class must be assigned when you create a tab within a Oracle Access Manager application. An auxiliary object class cannot stand alone because it contains supplementary attributes not necessarily found in a structural object class, for example, a billing address, challenge phrase, or a response to a challenge phrase. An auxiliary object class must be assigned to an entry that is based on an existing structural object class.Oracle Access Manager supports both InetOrgperson and GroupofUniqueNames as standard Person and Group object classes, respectively, in addition to User and Group. Oracle Access Manager also supports both statically-linked and dynamically-linked auxiliary classes.For additional information, see "About Oracle Access Manager and Active Directory Forests" and "Installation and Setup Considerations for Active Directory".

A.2.1 About Statically-Linked Auxiliary Classes

With Windows Server 2000, Active Directory supported only statically-linked auxiliary classes and provided support for statically linking auxiliary classes to another objectclass in the schema definition itself. A statically-linked object class is one that is included in the auxiliaryClass or systemAuxiliaryClass attribute of an object class's classSchema definition in the schema. A statically-linked object class is part of every instance of the class with which it is associated.When designing the schema for implementation on Active Directory for statically-linked auxiliary classes, which is the default with Oracle Access Manager:

  • Define oblixOrgPerson and oblixPersonPwdPlicy objects in your user (Person) object class.

  • Define oblixGroup and oblixAdvancedGroup in your Group object class.

For details, see the procedure "To modify your schema for statically-linked auxiliary classes".

A.2.2 About Dynamically-Linked Auxiliary Classes

With a Windows 2003 Server, Active Directory provides support for dynamically linking auxiliary classes to individual objects (not just entire classes of objects). In this case, you add the name of the auxiliary objectclass to the values of an object's objectclass attribute for an entry. If there are mandatory attributes in the auxiliary class, then those need to be set at the same time as well.

Dynamic linking enables you to store additional attributes with an individual object without the forest-wide impact of extending the schema definition for an entire class. For example, an enterprise can use dynamic linking to attach a sales-specific auxiliary class to the user objects of its sales people, and other department-specific auxiliary classes to the user objects of employees in other departments.

Oracle Access Manager provides a static auxiliary schema, which specifies the associations between auxiliary classes and their corresponding structural object classes in the schema. When using static auxiliary classes, Oracle Access Manager will not update the objectclass attribute for auxiliary classes to be added/removed. For dynamic auxiliary support, there is no separate schema file as such and Oracle Access Manager will update the objectclass attribute with auxiliary class name as appropriate.

During Identity Server setup and Access System installation and setup, you will be asked if you want the target directory to support dynamically-linked auxiliary classes. The following overview identifies the tasks that will ensure dynamically-linked auxiliary classes are associated in Oracle Access Manager at runtime.

Oracle Access Manager supports both statically- and dynamically-linked auxiliary classes, but not both simultaneously.


WARNING:

Dynamic auxiliary classes are supported when all domain controllers in the forest are running Windows Server 2003 and the forest functional mode is Windows Server 2003. A mixed environment, with 2003 domain controllers and earlier domain controllers, is not supported. Be sure to restart the Active Directory server after raising the forest level.


Task overview: Enabling dynamically-linked auxiliary classes

  1. Before Oracle Access Manager installation, you must ensure that the Active Directory domain and forest functionality are operating at a Windows 2003 Server level, as described in the Microsoft documentation.

  2. During Identity System installation and set up, specify dynamically-linked auxiliary classes as described in Chapter 4, "Installing the Identity Server" and Chapter 6, "Setting Up the Identity System".

  3. During Policy Manager installation and set up, specify dynamically-linked auxiliary classes as described in Chapter 7, "Installing the Policy Manager".

  4. During Access Server installation, specify dynamically-linked auxiliary classes as described in Chapter 8, "Installing the Access Server".

  5. After installation and setup, configure Oracle Access Manager for dynamic auxiliary class support, as described in the Oracle Access Manager Identity and Common Administration Guide

A.3 About Oracle Access Manager and Active Directory Forests

In earlier versions of Oracle Access Manager, it was possible to install Oracle Access Manager within only one Active Directory forest.Figure A-1 depicts a single Active Directory forest with three domains: Root_domain, Sub_domain, and Disjoint_domain.

Figure A-1 A Single Active Directory Forest with Three Domains

Active Directory forest with three domains.
Description of "Figure A-1 A Single Active Directory Forest with Three Domains"

Today, Oracle Access Manager components may reside either inside the Active Directory forest with Oracle Access Manager user, configuration, and policy data, or outside the forest containing Oracle Access Manager data. If you have installed Oracle Access Manager components inside a single Active Directory forest, you may use either of the following communication protocols between Oracle Access Manager and Active Directory:

Figure A-2 shows Oracle Access Manager components installed in one forest (Forest 1) with user, configuration, and policy data in another (Forest 2). This type of configuration is also known as having "Oracle Access Manager outside the forest". Using ADSI is optional.

Figure A-2 Oracle Access Manager Outside the Forest

Oracle Access Manager Outside the Forest image.
Description of "Figure A-2 Oracle Access Manager Outside the Forest"

In a two forest configuration a single domain controller in a forest, the schema master, is responsible for all changes to the schema directory partition. One domain controller for each forest, the domain-naming master, is responsible for ensuring that domain names are unique in the forest and that cross-reference objects to external directories are maintained. For more information, see your Microsoft documentation.A two forest configuration does not require setting up a trust relationship between the forest containing user, policy, and configuration data and the forest where the Oracle Access Manager servers are installed. Your environment may include configuration and policy data in one forest and user data in another forest.

A.3.1 Oracle Access Manager and the Searchbase in a Parent-Child Domain

Active Directory domains can be organized into parent-child relationships to form a hierarchy. A parent domain is one that is directly superior in the hierarchy to one or more subordinate, or child, domains. A child domain may also be the parent of one or more child domains.The searchbase in Oracle Access Manager defines the node in the directory information tree under which data is stored and the highest possible base for all searches. However, you may not locate an entry in a child domain. The default Oracle Access Manager directory server profile is created for only your Root_domain. You must set up directory profiles for the remaining domains in your installation, for example, Disjoint_domain and Sub_domain. For more information, see the Oracle Access Manager Identity and Common Administration Guide. In the Access System, a sub-tree-level search is performed during authentication using the credential_mapping plug-in and during authorization using LDAP rules when the rule (for instance, LDAP URL) explicitly states the search is to occur at a sub-tree-level. Using the ObMyGroups action with an LDAP URL returns all groups to which the user belongs. Table A-1 summarizes configurations that support a parent-child domain.

Table A-1 Configurations that Support a Parent-Child Domain

Function Configurations for Parent-Child Domains

Authentication

Use credential mapping to authenticate users against both the parent and child domain.

The Oracle Access Manager credential_mapping plug-in can be used to obtain the user's DN. For an Active Directory forest, typical credential_mapping plug-in parameters are similar to:

credential_mapping?ObMappingBase="%domain%, ObMappingFilter="(&(objectclass=user) (samaccountname=%login%))", Obdomain="domain" accountname=%login%))", Obdomain="domain"

Authorization

Use multiple LDAP URLs within an authorization rule.

ObMyGroups

Use ObMyGroups with an LDAP URL. If the user belongs to groups from both parent and child domains, you must define separate header variables for groups from each domain.

Using ObMyGroups with no URL will yield groups from the Access System searchbase only. If the searchbase is that of the parent domain, groups from the child domain will not be obtained at all.

For example, suppose you have two domains and you want to obtain groups from both searchbases:

dc=goodwill,dc=oblix,dc=com and dc=dilbert,dc=goodwill,dc=oblix,dc=com

In this case, you must have two separate header variables, one for each domain.

Return

Type Name Return Attribute

headervar HTTP_PARENT_GROUP "obmygroups:ldap:///dc=goodwill,dc=oblix,dc=com??sub?(group_type=role)"

headervar HTTP_CHILD_GROUP "obmygroups:ldap:///dc=dilbert,dc=goodwill,dc=oblix,dc=com??sub?(group_type=role)"

Hence in HTTP_PARENT_GROUP: all the groups in "dc=goodwill,dc=oblix,dc=com" tree for which the logged-in user is a member and the group_type is "role" is returned.

HTTP_CHILD_GROUP: all the groups in "dc=dilbert,dc=goodwill,dc=oblix,dc=com" tree for which the logged-in user is a member and the group_type is "role" is returned.


A.4 Installation and Setup Considerations for Active Directory

An overview of specific considerations are summarized for your review before you begin installing Oracle Access Manager with Active Directory:

A.4.1 Active Directory Schema Choices

There are several differences between the Active Directory 2000 and Active Directory 2003 schemas and how they apply to Oracle Access Manager:

Key Differences—The key differences between the Windows 2000 (ADSchema.ldif) and Windows 2003 schemas (dotnetschema.ldif) as it relates to Oracle Access Manager are the support of inetOrgPerson and groupofuniquenames. These two object classes exist in most other LDAP directories and were officially added to the Windows 2003 schema. The addition of the inetOrgPerson object class allows Oracle Access Manager to be configured using this object class without manually adding that object class as was required in Windows 2000.

Affect on Oracle Access Manager Schema Files—The main differences between the Oracle Access Manager Windows 2000 schema file (ADschema.ldif) and the Windows 2003 schema file (ADdotnetschema.ldif) are:

  • The following entries are in the ADSchema.ldif, but not in ADdotnetschema.ldif

    dn: cn=groupOfUniqueNames,cn=schema,cn=configuration,<domain-dn> dn: cn=uniquemember,cn=schema,cn=configuration,<domain-dn>

  • The oblixgroupofuniquenames class definition is different between the two files, due to differences in how groupofuniquenames is defined in the 2000 schema file and how Microsoft implemented it in the 2003 schema.

Objectclass Differences Between the Two Schemas—The following shows how the objectclasses differ between the two schemas:

  • ADSchema.ldif:

    Must Contain/Required Attributes—There are no required attributes.

    MayContain/Optional Attributes

    obuniquemember

    businesscategory

    obver

  • ADdotNetschema.ldif:

    Must Contain/Required Attributes cn businesscategory obuniquemember obver description o ou

    owner seeAlso uniqueMember

A.4.1.1 Determining which Schema to Load

The file named ADschema.ldif is the Oracle Access Manager schema file for Windows 2000 and the file named ADdotnetschema.ldif is the Oracle Access Manager schema file for Windows 2003. Consider the following when deciding which schema to load in your environment:

ADdotnetschema.ldif—Install Oracle Access Manager with the .NETSchema (Windows 2003 Schema) when you have the Active Directory 2003 schema loaded whether you are running Windows 2000 or Windows 2003.

For example, some companies are preparing for an upgrade to Windows 2003 and have loaded the Windows 2003 schema in their existing Windows 2000 domain.If this is the case, you should use the ADdotnetschema.ldif file when installing Oracle Access Manager.

ADschema.ldif—Load the Windows 2000 schema if you have the Windows 2000 Schema.


Note:

If you don't load the schema files manually, the installer decides which schema file to use based on the answer you provide when asked whether you are installing on Windows 2003 or not. If you indicate that you are installing on Windows 2003, the installer uses the ADdotnetschema.ldif.


Determining the Schema Type—The easiest way to find out whether the environment has a Windows 2000 schema versus the Windows 2003 schema is to use the schema snapin and look for the new string syntax in the 2003 schema. For example:

  • In the 2000 schema the string type used the Unicode format of attributesyntax 2.5.5.12.

  • In the 2003 schema it changed to the new syntax of IA5 attributesyntax 2.5.5.5., omysyntax: 22.

A.4.2 All Configurations

The following is intended as an overview for all Oracle Access Manager installations with Active Directory.Oracle recommends that you accept automatic schema updates during Identity Server and Access System installation and setup procedures to save time and eliminate errors. You can always make changes later. However, for manual schema updates you must use one or more of the following files during the setup process depending on your environment:

  • For Windows 2003 and dynamically-linked auxiliary classes, you need only the file:

    \install_dir\identity|access\oblix\data\common\ADDotNetSchema.ldif

     ldifde -i credentials -c "<domain-dn>" "your domain" -f ADDotNetSchema.ldif
    
  • For Windows 2003 and statically-linked auxiliary classes, you need both of the files:

    \install_dir\identity|access\oblix\data\common\ADDotNetSchema.ldif \install_dir\identity|access\oblix\data\common\ADAuxSchema.ldif

  • For Windows 2000, you need only:

    \install_dir\identity|access\oblix\data\common\ADSchema.ldif

It's a good idea to add the properties of the administrative user to members of: Main Administrators Schema Administrators Group Policy Administrators Enterprise Administrators Domain Administrators Users, AdministratorsThe following guidelines apply to all Oracle Access Manager configurations with Active Directory.

Guidelines: Installing Oracle Access Manager with Active Directory

  1. During Oracle Access Manager installation and setup, be sure to specify the version of Active Directory you are using, as well as responding appropriately to any related questions you are asked.

  2. During Oracle Access Manager installation and setup, use the same configuration DN for the Identity Server and for the Policy Manager and Access Server.


    Note:

    The login name for a multi domain forest is the display name from Access Server DB profile.


  3. After installation and setup, you may create or change your authentication scheme or schemes for Active Directory as described in the Oracle Access Manager Identity and Common Administration Guide.

  4. After installation and setup, you can expand a large dynamic group on Active Directory by adding the following to the globalparams.xml on the Identity Server:

        <SimpleList>
        <NameValPair ParamName="maxForRangedMemberRetrieval"
        Value="1500"/
        </SimpleList>
    

A.4.3 ADSI Option Considerations

The following is intended as an overview for configurations using ADSI. Using ADSI is optional.

The credentials for ADSI are used to bind to the entire forest. A forest can contain multiple Active Directory hosts. When user data and configuration data are stored on separate Active Directory hosts in separate forests, you cannot connect to these simultaneously using ADSI. For additional information, see "ADSI Cannot Be Enabled for this DB Profile (Active Directory)".

ADSI does not require specific host and port numbers for different domains in the forest. ADSI connects to Active directory hosts using an LDAP URL like this one:

     LDAP://domain.oracle.com/ou=oblix,dc=domain,dc=oblix,dc=com

When user data and configuration data are stored on separate Active Directory hosts in the same forest, you can connect to these using ADSI. The data will be searched and modified in respective Active Directory servers in the forest using the domain-naming context.

During installation you will be asked if configuration data will be stored in the user data directory. When user data and configuration data are stored on separate Active Directory hosts in the same forest and you are using ADSI for the user tree, be sure to indicate that configuration data will be stored in the user data directory. If you indicate that user data and configuration data are stored separately, you will not be allowed to connect to the configuration data directory server using ADSI and cannot create the DB profile for the configuration data by selecting ADSI from the Identity System Console page. Although you can connect to the configuration data directory server using LDAP.

  • When using ADSI for the entire forest, the credentials of the Master Administrator should be that of an Enterprise Administrator with administrative privileges over the entire forest.

    The same user tree credentials should be valid for the entire forest. If you decide to configure ADSI for the user tree and LDAP for the configuration/policy tree, you can change parameters in the globalparams file and define the appropriate profiles after setup is complete as described in the Oracle Access Manager Identity and Common Administration Guide.

  • When Oracle Access Manager data and components are in the same domain, you must run the Identity Server in the context of a privileged administrative user who has change-password permissions after the Identity System is installed and set up.

  • When storing user data on a separate Active Directory server from configuration and policy data in a separate forest, ADSI may be used for connecting to one or the other but not both.

    • During Oracle Access Manager Installation—Select Yes when asked if configuration data is stored with user data, select ADSI for the user data directory server (you won't be asked about ADSI for configuration data).

    • During Oracle Access Manager Setup—The directory type for the DB profiles will be indicated as follows:

      User DB Profile—Microsoft Active Directory and ASDI Configuration DB Profile—Microsoft Directory only (no ADSI)

  • With Oracle Access Manager components in one domain and data in another, you may use either ADSI or LDAP between Oracle Access Manager components and Active Directory.

During installation and setup, Oracle Access Manager automatically updates certain parameters in the adsi_params.xml file on the Identity Server and the adsi_params.lst file on the Policy Manager. The path to these files is:

\IdentityServer_install_dir\identity\oblix\config\adsi_params.xml \AccessServer_install_dir\access\oblix\config\adsi_params.xml

Included in the files is a useImplicitBind value for the user bind DN. Table A-2 provides a summary of possible bind parameters.

Table A-2 Summary of Possible Bind Parameters

useImplicitBind Value Definition Description

0

Use the implicit credentials of the current process for the bind.

Single Active Directory Forest

The default for the Identity Server in the adsi_params.xml file.

1

Use explicit credentials with the DN of the user for the bind.

Two Active Directory Forests

Ensure that useImplicitBind value is set to 1 in the adsi_params.xml and .lst files.

2

Use userPrincipalName for the bind.

Two Active Directory Forests

  • The default for the Policy Manager in the adsi_params.lst file.

  • The preferred value when Oracle Access Manager components are in a different domain than Oracle Access Manager data.

  • The UPN should be specified in the adsiUPN parameter in the adsi_params.xml file.


If you are using ADSI with:

  • useImplicitBind=1—You do not need to have your service login credentials set by the Identity Server if the value of useImplicitBind is 1. When Oracle Access Manager components reside in one forest and data in another, set useDNSPrefixedLDAPPaths=true.

  • implicitBind=0—You do need to set the permissions of the IIS Anonymous user to a domain user if you are using implicitBind=0. The defaults are implicitBind=0, useDNSPrefixedLDAPPaths=false.

    In this case, ADSI uses the context of the process to bind to the Active Directory server. By default the anonymous user (IWAM*) does not have rights on the directory server.

  • useDNSPrefixedLDAPPath—You can prefix the domain name to LDAP strings using the useDNSPrefixedLDAPPath parameter in the adsi_params.xml and adsi_params.lst files. The default value is false.

Guidelines: Setting up ADSI

  1. Before you install Oracle Access Manager, you need to set up Active Directory as described in the Microsoft documentation and "Setting Up Your Environment".

  2. During Identity Server installation, enable ADSI as described in Chapter 4, "Installing the Identity Server" and "Installing the Identity System".

  3. Before Identity System setup, complete steps in "Setting Up ADSI (Optional)".

  4. During Identity System setup, specify ADSI as described in Chapter 6, "Setting Up the Identity System" and "Setting Up the Identity System".

  5. During Policy Manager installation and set up, specify ADSI as described in Chapter 7, "Installing the Policy Manager" and "Installing and Setting Up the Access System".

  6. During Access Server installation, enable ADSI as described in Chapter 8, "Installing the Access Server" and complete any additional steps in "Setting Up ADSI on the Access Server (Optional)".

    If you have Oracle Access Manager components in one forest and Oracle Access Manager data in another forest, as shown in Figure 18, before you set up the Identity System and Access System complete the next task.

  7. After installation and setup, you should confirm the following parameters and values are set as shown here in the Oracle Access Manager adsi_params files. For example:

    \IdentityServer_install_dir\identity\oblix\config\adsi_params.xml \AccessServer_install_dir\access\oblix\config\adsi_params.xml

         NameValPair ParamName="useDNSPrefixedLDAPPaths
         Value="true"
    

    \IdentityServer_install_dir\identity\oblix\config\adsi_params.xml

         NameValPair ParamName="adsiCredential"         
         Value="cn=Administrator,cn=users,dc=goodwill,dc=oblix,dc=com"
    

For more information about the adsi_params files and parameters, see the Oracle Access Manager Identity and Common Administration Guide.

A.4.4 LDAP Open Bind Considerations

The following is intended as an overview. LDAP open bind is the default (presumed) communication method between Oracle Access Manager and the directory server. If you are using an LDAP open bind between Oracle Access Manager components and Active Directory, you may complete some additional steps during Oracle Access Manager installation and set up.

Guidelines: Setting up an LDAP open bind

  1. Before you install Oracle Access Manager, you need to set up Active Directory as described in the Microsoft documentation and "Setting Up Your Environment" on page 395.

  2. During Identity System installation and setup, be sure to indicate that there is no SSL connection between Oracle Access Manager and Active Directory.

  3. After Access Server installation, you are prompted to specify failover information and timeouts for LDAP and the port number.

A.4.5 LDAP Over SSL Considerations

The following is intended as an overview. If you are using LDAP over SSL between Oracle Access Manager components and Active Directory, you will complete additional steps during Oracle Access Manager installation and set up.

Guidelines: Setting up SSL

  1. Before you install Oracle Access Manager, ensure that you have a certificate on the computer, as described in "Setting Up Your Environment".

  2. After installation and setup, you may reconfigure communication with the directory server, as described in the Oracle Access Manager Identity and Common Administration Guide.

    If you have ADSI enabled and you reconfigure communication with the directory server, you must also edit the adsi_params.xml and adsi_params.lst files to reset the encryption parameter to false.

A.5 Installing Oracle Access Manager with Active Directory

With the earlier considerations in mind, you are ready to set up your Active Directory and install Oracle Access Manager. Following discussions explain all procedures and the order in which they must be completed.

Task overview: Installing Oracle Access Manager with Active Directory includes

  1. "Setting Up Your Environment"

  2. "Installing the Identity System"

  3. "Setting Up the Identity System"

  4. "Validating Your Identity System Setup"

  5. "Installing and Setting Up the Access System"

Each of the items in the task overview can include multiple procedures. When this is the case, additional task overviews will be provided to outline the order in which procedures must be completed.

A.5.1 Setting Up Your Environment

The topics here outline how to set up your Active Directory before installing Oracle Access Manager components.

Task overview: Setting up your environment includes

  1. "Setting Up Domain Controllers"

  2. "Installing the Certificate Server"

  3. "Retrieving the Certificate"

A.5.1.1 Setting Up Domain Controllers

Before you install Oracle Access Manager components, you must set up the domain controller.


WARNING:

If you intend to enable dynamically-linked auxiliary classes, you must raise both the domain and the forest to a Windows 2003 Server level, as described in the Microsoft documentation.


To prepare the domain controllers

  1. Set up and configure a domain controller for each computer in the Active Directory forest, using the instructions from Microsoft.

  2. Specify the desired method for all auxiliary classes, either dynamically-linked or statically-linked auxiliary classes, using instructions from Microsoft.

A.5.1.2 Installing the Certificate Server

When you use LDAP over SSL, you must install the Microsoft CA Certificate Server and retrieve a certificate.


Note:

If you are using LDAP (the default) or ADSI, skip this discussion.


You can install the certificate server on any computer in the Active Directory forest. However, Oracle recommends that you install it on the root domain of the Active Directory forest (for example, Root_domain). When enabled, all domain controllers will automatically request a certificate and support LDAP using SSL port 636.

To set up the Microsoft CA certificate server on other domain controllers

  1. Set up a policy to enable other domain controllers to automatically request certificates, using the instructions from Microsoft.

  2. Set up and configure the Microsoft CA certificate server, using your Microsoft documentation.

A.5.1.3 Retrieving the Certificate

After the certificate server is setup, you must retrieve the Microsoft CA certificate from the computer where the certificate server is installed and save it on the computer where you will install the Oracle Access Manager component. For example, on the Identity Server, Root_domain.


WARNING:

A certificate is required on each computer on which SSL is enabled.


Task overview: Retrieving and setting up a certificate inclues

  1. "To retrieve a certificate for the intended Identity Server"

  2. "To set up the certificate"

To retrieve a certificate for the intended Identity Server

  1. On the computer where you will install the Identity Server, navigate to the computer where the Microsoft CA certificate server is installed. For example:

    http://Root_domain/certsrv/

  2. Select Retrieve the CA certificate or certificate revocation list.

  3. Select Base64 encoded.

  4. Double-click the Download CA certificate link.

  5. Select Save this file on the computer where you will install the Identity Server.

  6. Enter a directory and file name.

  7. Record the full path to this file so you will have it when you install the Identity Server. For example:

    F:\OracleAccessManager\certnew.cer

You are ready to install the Identity System. See also, "To set up the certificate".

To set up the certificate

  1. Navigate to the certificate server. For example:

    http://Root_domain/certsrv/

  2. Download the certificate chain to a file and save the certificate.

    When you import the file and store it on the local computer, as described next, IE imports the CA to the personal certificate store of the user who is currently logged in by default.

  3. Import the file to a trusted root CA store on the local computer. For example,:

    Select Internet Explorer, Tools, Internet options Select Content, Certificates, Trusted Root Certificate, CertName, Import, Next Click Browse, Filename, then click Next Trusted Root Certification Authorities, Local Computer

A.5.2 Installing the Identity System

After the preliminary set up of Active Directory, you need to install the Identity Server and WebPass, the two main components of the Identity System.

Task overview: Installing the Identity System with Active Directory includes

  1. "Installing the Identity System"

  2. "Setting Up ADSI (Optional)"

A.5.2.1 Installing the Identity System

During installation and setup, you will be asked to respond to the same questions as those who install Oracle Access Manager with other directory servers. In addition, you will be asked to specify options for ADSI and dynamically-linked auxiliary classes.

To install the Identity Server

  1. Review "Installation and Setup Considerations for Active Directory" and "Data Storage Requirements".

  2. Complete "Setting Up Your Environment", as needed.

  3. Follow the instructions in Chapter 4, "Installing the Identity Server", and include specifications and preferences for your Active Directory environment.

    The bind DN you specify can be any user as long as there are sufficient privileges to modifiy/read the attributes and access the schema, including changing password permissions if using LDAP/SSL. With ADSI, the Identity Server service credentials need to be appropriate.

  4. To expand large dynamic groups on Active Directory, if desired, add the following to the globalparams.xml file, then restart the Identity Server:

    \IdentityServer_install_dir\identity\oblix\apps\common\bin\globalparams.xml

         <SimpleList >
         <NameValPair ParamName="maxForRangedMemberRetrieval" Value="1500"/>
         </SimpleList>
    

To complete Identity System installation

  1. Follow the instructions under Chapter 5, "Installing WebPass".

  2. Complete the appropriate task, depending upon your environment:

A.5.2.2 Setting Up ADSI (Optional)

If you want to use optional ADSI, you need to complete the steps here:

  • Immediately after Identity System installation (Identity Server and WebPass)

  • Before setting up the Identity System

By default, ADSI uses an implicit bind. This corresponds to the Windows 2000 Server and Windows Server 2003 service logon credentials. For more information, see, "ADSI Option Considerations" and the Oracle Access Manager Identity and Common Administration Guide.

To set up ADSI, before you set up the Identity System

  1. Choose the proper bind mechanism for your environment in the \IdentityServer_install_dir\identity\oblix\config\adsi_params.xml. For example:

    • ADSI with a Single Forest

      <NameValPair ParamName="useImplicitBind"
                      Value="0"/>
      
      
    • ADSI when Oracle Access Manager and Data are in Different Forests

      <NameValPair ParamName="useImplicitBind"
                      Value="1"/>
      <NameValPair ParamName="useDNSPrefixedLDAPPaths"
                      Value="true">
      
  2. When useImplicitBind=0—Set the service logon credentials for the Identity Server to an administrative user in the domain with the same privileges as the user you designated as the root bind DN during Identity Server installation.

  3. Set up the Identity System as described under "Setting Up the Identity System" next.

A.5.3 Setting Up the Identity System

After you install the Identity Server and WebPass components, you are ready to set up the Identity System. Discussions here explain what to do before and during Identity System set up to ensure success. Several situations are covered:

A.5.3.1 Enabling Active Directory Attributes

To enable specific Active Directory attributes, you need to complete the procedure here. For example, if you want to use the userPrincipalName as a login attribute and you want this attribute to be available during Identity System setup, complete these activities before Identity System setup.


Note:

If you do not want to enable specific Active Directory attributes, skip this task and go directly to "Setting Up the Identity System".


To enable Active Directory attributes

  1. Locate the ad_exlude_attrs.xml and exclude_attrs-ad.xml files. For example:

    \IdentityServer_install_dir\identity\oblix\data.ldap\common\ad_exlude_attrs.xml

    \IdentityServer_install_dir\identity\oblix\data.ldap\common\exclude_attrs-ad.xml

  2. Edit the files to make specific Active Directory attributes available within Identity System user profiles. For example:

    <ValNameList ListName="userPrincipalName">
    <NameValPair ParameterName="appliesto" Value="None" />
    

To modify your schema for statically-linked auxiliary classes

  1. Modify your schema to attach the oblixOrgPerson and oblixPersonPwdPlicy objects to your user object class and oblixGroup and oblixAdvancedGroup to your Group object class.

  2. Perform a schema reload within the MMC Schema Manager Application after making the changes indicated and allow approximately fifteen minutes for the schema changes to be replicated to all domain controllers.

A.5.3.2 Enabling Change-Password Permissions

When Oracle Access Manager data and components are in the same forest, you must run the Identity Server in the context of a privileged administrative user who has change-password permissions.


Note:

With LDAP over SSL, you do not need to set service credentials for the Identity Server.


A.5.3.3 Setting Up the Identity System

After completing the earlier tasks, you are ready to set up the Identity System for the Active Directory forest, using the Root_domain.

To set up the Identity System for an Active Directory forest

  1. Navigate to the Identity System set up page:

    http://hostname:port/identity/oblix

  2. Click Identity System Console then click Setup to activate the process.

  3. Follow the instructions in Chapter 6, "Setting Up the Identity System".

    • Enable ADSI, if appropriate.

    • Check the Dynamic Auxiliary Object Class box, if appropriate.

  4. When setup is complete, you can perform the tasks outlined here:

A.5.4 Validating Your Identity System Setup

It is a good idea to validate that your Identity System is set up and properly operating with Active Directory before you being installing the Access System.

To validate your Identity System setup

  1. Navigate to the Identity System login page.

    http://hostname:port/identity/oblix

  2. Verify that all domain names appear in the drop-down list on the login page.

  3. Log in.

  4. Navigate to the Configure Directory Options page and confirm that your disjoint searchbase is listed.

    From the Identity System Console select System Admin, System Configuration, Directory Options


    Note:

    If your disjoint searchbase is not listed, you can add it now. For more information, see the Oracle Access Manager Identity and Common Administration Guide.


    After validating that your Identity System is working properly, you can install and set up the Access System.

A.5.5 Installing and Setting Up the Access System

Refer to the following topics as you install the Access System with your Active Directory forest.

A.5.5.1 Preparing for Access System Installation

Be sure to verify that these steps have been completed before you attempt to install the Access System.

To prepare for the Access System installation and setup

  1. Review "Installation and Setup Considerations for Active Directory".

  2. Install the Identity System, as discussed in "Installing the Identity System".

  3. Set up the Identity System, as discussed in "Setting Up the Identity System".

  4. Validate your Identity System, as discussed in "Validating Your Identity System Setup".


    WARNING:

    To prepare the Policy Manager host for ADSI when the computer is not a domain controller and resides in the same forest with other Oracle Access Manager data, ensure that useImplicitBind=1 or 2 and useDNSPrefixedLDAPPaths=true.


A.5.5.2 Installing and Setting Up the Access System

Use the steps here as a guide when you install and set up the Access System in this environment.

To install and set up the Policy Manager

  1. Confirm that you have a certificate on each computer, if needed, for ADSI or LDAP over SSL before you begin Oracle Access Manager installation.

    In the next step, use the same directory server details that you used for the Identity Server installation only if your configuration data, user data, and Oracle Access Manager policy data will reside on the same directory server. Also, ensure that the distinguished name specified as the bind DN has full permissions for the user and configuration branches of the directory information tree (DIT).

  2. Install the Policy Manager, as described in "Installing the Policy Manager".

    • Select Active Directory using ADSI, if appropriate.

    • Select dynamically-linked auxiliary classes, if appropriate.

  3. Set up the Policy Manager as described in "Setting Up the Policy Manager" and consider the following:

    • With ADSI, select Enable ADSI and enter the userPrincipleName as the bind DN (for example, user@company.com), then complete set up.

    • With LDAP open bind, see the Oracle Access Manager Access Administration Guide to complete Policy Manager set up.


      WARNING:

      You complete the following steps only when Oracle Access Manager server components reside in one forest and data in another.


  4. Verify that the useDNSPrefixedLDAPPaths value in the \PolicyManager_install_dir\access\oblix\config\adsi_params.lst fie is set to true. For example:

         <NameValPair
         ParamName="useDNSPrefixedLDAPPaths"
                 Value="true" /> 
    
  5. Verify the forceExplicitBindUsingDN and set its value to true in the \PolicyManager_install_dir\access\oblix\apps\common\bin\globalparams.lst file. For example:

         forceExplicitBindUsingDN:true 
    
  6. Restart the Identity Server and WebPass Web server.

To install and set up the Access Server and WebGate

  1. Confirm that you have a certificate on each computer, if needed, for ADSI or LDAP over SSL before you begin Oracle Access Manager installation.

  2. Install the Access Server, as described in "Installing the Access Server" on page 187 and consider the following items:

    • Select Active Directory using ADSI, if appropriate, enter the adsiCredential and adsiPassword when prompted, then complete "Setting Up ADSI on the Access Server (Optional)" on page 404 before restarting the Access Server.

      adsiCredential and adsiPassword are required to generate an encrypted password that can be used when explicitly binding to Active Directory using ADSI. Because Oracle Access Manager does not include an encryption tool, you must enter values for adsiCredential and adsiPassword when asked.

      Select dynamic auxiliary classes, if appropriate.


      Note:

      You will be asked where the user data, configuration data, and policy data are stored and for configuration details for the directory server.


      You need to complete step 3 when you have Active Directory 2000, because it does not support concurrent bind requests coming from different Oracle Access Manager threads on the same LDAP connection. For more information, see "Active Directory Tips and Troubleshooting".

  3. Active Directory 2000—On the Access Server, open the globalparams.lst file and add a new flag called exclusiveAuthnConnection set to true to force Oracle Access Manager threads to use separate LDAP connections for bind requests being sent to the directory server.

  4. WebGate—Install and configure the WebGate, as described in Chapter 9, "Installing the WebGate".

    See the Oracle Access Manager Identity and Common Administration Guide for more information about authentication and authorization with Active Directory and configuring Oracle Access Manager for specific Active Directory features.

A.5.5.3 Setting Up ADSI on the Access Server (Optional)

If you choose to use ADSI, which is optional, you must set up ADSI on the Access Server:

  • After installing the Access Server

  • Before restarting the Access Server

To set up ADSI on the Access Server

  1. Log in to the domain as an administrative user.

  2. Set the service logon credentials for the Access Server to an administrative user in the domain.

    This user must have the same privileges as the user that you provide in the Root DN during Policy Manager and Access Server installations.

  3. Choose the proper bind mechanism in the adsi_params.lst file. For example, in a two forest configuration:

    \AccessServer_install_dir\access\oblix\config\adsi_params.xml

         useImplicitBind Value="1"
    

    By default, the Access Server useImplicitBind is set to 0 for a single-forest configuration. ADSI uses an implicit bind. This corresponds to Windows 2000 Server, or Windows Server 2003 service logon credentials. See the Oracle Access Manager Identity and Common Administration Guide for more information on ADSI bind mechanics.

    You complete step 4 and step 5 as needed for your environment.

  4. When you have Oracle Access Manager components installed outside the Active Directory forest, you need to verify the useDNSPrefixedLDAPPaths parameter value in the adsi_params.lst is set to true. For example:

         useDNSPrefixedLDAPPaths Value="true"
    
  5. When you have Oracle Access Manager components installed in one forest and data in another, set the forceExplicitBindUsingDN parameter value to true in the globalparams.lst file. For example:

    \AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.lst

         forceExplicitBindUsingDN Value="true" 
    
  6. See the Oracle Access Manager Identity and Common Administration Guide for more information about authentication and authorization with Active Directory and configuring Oracle Access Manager for Active Directory features.

A.6 Active Directory Tips and Troubleshooting

For information, see "Active Directory Issues".