A Deploying with Active Directory

After you complete the activities in the Oracle Access Manager Installation Guide to install and set up Oracle Access Manager with Active Directory, you can complete activities here to configure these components for daily use and maintenance.

This appendix contains the following topics:

Setting Up Directory Profiles and Searchbases
Authentication and Authorization with Active Directory
Configuring the credential_mapping Plug-In
Configuring Single Sign-On for Use with Active Directory
About Search Filters
About the Length of the SAMAccountName
Configuring for .NET Features
Troubleshooting
Microsoft Resources

For additional information and procedures, see the Oracle Access Manager Installation Guide. See also:

A.1 Setting Up Directory Profiles and Searchbases

The Active Directory forest shown in Figure A-1 includes three domains: Root_domain, Sub_domain, and Disjoint_domain. The configuration in Figure A-1 appears in the discussions that follow.

Figure A-1 Three Domains in a Single Active Directory Forest

Image of a root and a disjoint domain in an AD forest.

When you have finished installation and set up for Active Directory, as described in the Oracle Access Manager Installation Guide, you are ready to complete the following tasks.

Defining Directory Server Profiles for Remaining Domains
Setting Up Disjoint Searchbases
Configuring Group-Search Read Operations (Optional)

A.1.1 Defining Directory Server Profiles for Remaining Domains

A default directory server profile is created automatically each time you install the Identity Server and specify new directory server connection information. The directory server profile contains connection information for one or more directory servers that share the same namespace and operational requirements for read, write, search, and so on. The connection information includes a name, a domain or namespace to which it applies, a directory type, and a set of operations.

Note:

The default 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.

After installation, you can use the Identity System Console to modify the directory server profiles as outlined in the following procedure. When you finish the steps in the following procedure, you may set up the Disjoint Searchbases.

For more information, see "Managing Directory Server Profiles".

To set up additional directory server profiles

Navigate to the Identity System Console.

http://hostname:port/identity/Oblix
Navigate to the directory server profile: Identity System Console, System Admin, System Configuration, Configure Directory Options, link.
Add the profile for the Disjoint_domain, if you have one, as described in "Managing Directory Server Profiles".
Add the profile for the Sub_domain.
Rename the Default Directory Profile if the default name generated during Identity System setup is not meaningful to you.
Set up disjoint searchbases, as described next.

A.1.2 Setting Up Disjoint Searchbases

After the domains are configured, you need to add a disjoint searchbase for the Disjoint_domain and verify that there is no value in the Tab Searchbase field.

Note:

Depending on how you configured the Root_domain, you may want to add a disjoint searchbase for the Sub_Domain.

To add a disjoint searchbase for the Disjoint_domain

Navigate to the Identity System Console.

http://hostname:port/identity/oblix
Navigate to and select the Directory Server link: Identity System Console, System Admin, System Configuration, Configure Directory Options, link.
Add a disjoint searchbase for the Disjoint_domain and click Save.
Navigate to and select the Configure Tab function in the User Manager: Identity System Console, User Manager Configuration, Configure Tab.
Select a link on the Configure Tab page.
Confirm there is no value in the Tab Searchbase field.
Repeat these steps for the Sub_domain, if you have one.

A.1.2.1 About Deleting a Disjoint Searchbase

If there are searchbase policies for the disjoint searchbase, a user who has this searchbase on this node is able to create a filter with Query Builder whose base is this searchbase. It is advisable to remove all access control policies for this disjoint searchbase before deleting it.

If you remove a disjoint searchbase, you must disable all the database agents that use this searchbase.

A.1.3 Configuring Group-Search Read Operations (Optional)

Active Directory uses incremental retrieval of group members. This means that the Identity System must perform multiple reads to get the complete set of group members.

For Active Directory on Windows 2000, the maximum number of members that can be retrieved with one read is 1000. Unless you change the parameter, the Identity System uses a default value of 1000. For Active Directory on Windows .NET Server 2003 the maximum is 1500. The parameter maxForRangedMemberRetrieval located in globalparams.xml contains the maximum value that the Identity System uses.

Note:

The notation install_dir refers to the directory where you installed the named component. For example, IdentityServer_install_dir refers to the directory where you installed the Identity Server.

To configure group-search read operations on Windows 2003

Locate the globalparams.xml file in \IdentityServer_install_dir\identity\oblix\apps\common\bin\globalparams.xml.

Add the maxForRangedMemberRetrieval entry with a value of 1500.

For example:

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

Save the file.
Restart the Identity Server.

A.2 Authentication and Authorization with Active Directory

Two-forest configurations were introduced in the Oracle Access Manager Installation Guide. After installation, configuring the Access System for Active Directory can include setting up authentication and authorization in a parent-child domain.

This section contains the following topics:

Parent-Child Authentication
Parent-Child Authorization
ObMyGroups Action Attribute

A.2.1 Parent-Child Authentication

In this case, you need to use the Access System's credential mapping plug-in to authenticate users against both the parent and child domains. This plug-in obtains the user's DN.

For example, suppose you have two domains, foo.goodwill.oracle.com and goodwill.oracle.com. In the Identity System, you have two directory profiles, one for foo.goodwill.oracle.com with a display name of foo and another for goodwill.oracle.com with a display name of goodwill:

Foo.goodwill.Oracle.com:DisplayName=fooSearchbase = dc=foo,dc=goodwill,dc=Oracle,dc=comUser:Alice

Goodwill.Oracle.comDisplayName=goodwillSearchbase=dc=goodwill,dc=Oracle,dc=comUser:Bob

Also suppose you are using a Oracle Access and Identity authentication mechanism that uses the filter in the credential_mapping plug-in shown in the previous example. When the user tries to log in to the Access System, a Basic Over LDAP dialog box appears.

Image of the Basic Over LDAP login page.

The domain is the part of the login ID entered before the "\". From the domain name, the Access System can tell which searchbase to use to identify this user. When Alice logs in, she must specify a domain name of foo, and when Bob logs in he must specify a domain name of goodwill. Both users will be authenticated.

Note:

To access a resource that is protected by a Oracle Access and Identity authentication scheme for an Active Directory forest, the user needs to enter the "domainname\username" as the user name in the Authentication dialog box. This domainname should be the display name for the DB profile created for the Access Server that is used to perform authentication for this user.

A.2.2 Parent-Child Authorization

You can define separate LDAP rules for each domain. For example, if you want all users who have the title of Manager to access a resource, you need to specify two LDAP rules, one for each domain. An example of these rules:

ldap:///dc=goodwill,dc=Oracle,dc=com??sub?(&(title=Manager)(objectclass=user)

ldap:///dc=foo,dc=goodwill,dc=oracle,dc=com??sub?(&(title=Manager)(objectclass=user)

Using these rules, managers who are in both foo and goodwill can be authorized.

A.2.3 ObMyGroups Action Attribute

You can use the ObMyGroups action attribute to return in a header variable all of the groups to which a user belongs. Specifying ObMyGroups in the attribute name uses the searchbase configured for the Access System. Access Server does not impose any limit on the number of groups that are returned. The returned groups are only limited by any size limit configured for the directory.

The Access System supports only one searchbase. Therefore, if the user chooses goodwill.Oracle.com as the product searchbase, then ObMyGroups results in a search for groups under goodwill.oracle.com. In this case, the Access System cannot follow referrals, and since the Access System does not have multiple searchbase capability, groups from foo.goodwill.oracle.com cannot be returned.

You can specify ObMyGroups with an LDAP URL. In this case, the searchbase is picked up from the LDAP URL. However, you can only associate one attribute with one header variable, so if you have two domains you need at least two header variables to obtain all of the groups a user belongs to.

For example, suppose you have two domains: dc=goodwill,dc=oracle,dc=com and dc=dilbert,dc=goodwill,dc=oracle,dc=com. To obtain groups from both these searchbases you must define two separate header variables, one for each domain, as shown in Table A–1.

Table A-1 ObMyGroups with LDAP URLs for Two Domains

Type	Name	Return
headervar	HTTP_PARENT_GROUP	"obmygroups:ldap:///dc=goodwill,dc=Oracle,dc=com??sub?(group_type=role)"
headervar	HTTP_CHILD_GROUP	"obmygroups:ldap:///dc=dilbert,dc=goodwill,dc=Oracle,dc=com??sub?(group_type=role)"

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

The following procedures guide as you configure the credential_mapping authentication plug-in for Active Directory and set up SSO, if needed.

A.3 Configuring the credential_mapping Plug-In

Each policy domain requires an authentication scheme. Each authentication challenge method is supported by one or more plug-ins. For more information about plug-ins for authentication challenge methods, see the Oracle Access Manager Access Administration Guide.

The credential_mapping plug-in maps the user's user ID to a valid distinguished name (DN) in the directory. You can configure the attribute to which the user ID is mapped. The most common attribute it is mapped to is uid. However, it is possible for a customer to map the user ID to a profile attribute other than uid by changing the obMappingFilter parameter.

The obmappingbase defines the user searchbase. In a single domain, the mapping base must be explicitly defined in the obMappingBase parameter of the credential_mapping plug-in. For example,

ou=company,dc=mydomain,dc=Oracle,dc=com).

With an Active Directory forest, the user needs to provide the domain plus the user ID during the login to validate the user credential against the specified domain. In this case, the mapping base should be set to obMappingBase="%domain%". The template for defining credential mapping for Oracle Access and Identity in an Active Directory forest should be

obmappingbase="%domain%",obmappingfilter=(&(objectclass=user) (sam accountname=%userid%))", obdomain="domain"

The domain information is maintained in the DB profiles in the Identity System Console. Be sure to create a DB profile for each domain. The login name for a multi-domain forest is the display name from the Access Server DB profile.

To configure the credential_mapping plug-in

Create a policy domain in the Policy Manager, as usual.

Note:
There is currently an upper limit of 350 policy domains when the Access System is deployed with Active Directory.
Navigate to the Authentication Management Plug-In page: Access System Console, Access System Configuration, Authentication Management, link, Plug-Ins.

where link is the name of the authentication scheme you want to alter.
Configure the credential_mapping plug-in for Active Directory.

For example:

For Form Based:

obmappingbase="%domain%",obmappingfilter=(&(objectclass=user)(samaccountname=%login%))

For Oracle Access and Identity:

obmappingbase="%domain%",obmappingfilter=(&(objectclass=user)(samaccountname=%userid%))", obdomain="domain"

Note:

To access a resource that is protected by an Oracle Access and Identity authentication scheme for an Active Directory forest, the user needs to enter the domainname\username as the user name in the Authentication dialog box. This domainname should be the display name for the DB profile created for the Access Server used to perform authentication for this user.

A.4 Configuring Single Sign-On for Use with Active Directory

You may want to configure single sign-on for the Identity or Access System, as described in the following procedure. For more information, see about protecting resources with policy domains and configuring single sign-on, see the Oracle Access Manager Access Administration Guide.

To configure single sign-on with the Identity or the Access System

Change actions in the policy domain authorization rules that need to pass the header variable ObUniqueId (rather than uid) HTTP_OBLIX_UID.

Note:
There is currently an upper limit of 350 policy domains with Active Directory. See "Troubleshooting" for details.
On the Web server, modify the value of the WhichAttrIsLogin parameter to ObUniqueID in the following files:

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

WhichAttrIsLogin:ObUniqueId

The Configure Directory Server profiles page shows the associated directory profile, which specifies a number of attributes. For example:

Machine:
Port Number:
Root DN:
Root Password:
Searchbase:
Configuration base:
Directory Server Security Mode:
Disjoint Searchbase:
ADSI enabled: Yes

Following is resulting basic login window related to the single sign-on.

If you are configuring for an Active Directory forest, the domain the user belongs to is determined by the directory profiles configured in the Identity System and used by the Access System. These directory profiles can be enabled or disabled through the Configure Directory Server Profile page accessible from the Identity System Console, Configure Directory Options function.

If a directory profile is disabled and the user enters that domain name during login through the Access System, then the user is not allowed access.
If a directory profile is enabled and user enters that name as the domain name, then the user is allowed access.

However, if a user is already authenticated and has a valid session token, after which the directory profile is disabled, then the user is allowed access based on the authorization rules, and so forth. The directory profile state (enabled/disabled) does not take affect during authorization. Only authentication honors the state of the profile.

A.5 About Search Filters

Active Directory does not invoke indexed searches when the filter contains constraints that evaluate to which contains --filters such as cn=*Smith, where the searched for value contains Smith. For indexed searches the following constraints are valid:

Equals (cn=Smith)
Begins with (cn=Smith*)

The myGroups tab on the Group Manager may take a long time to evaluate the result if the dynamic groups options is enabled and the dynamic filters specified contain the which contains search filter.

To prevent users from using the which contains search filter, restrict the available filters by modifying the catalog files. In the following directory:

Component_install_dir/identity|access/oblix/app//bin/application

where Component_install_dir is the directory where the component is installed and identity|access represents either the Identity or Access system, respectively

There are several xxxparams.xml files. In these files you can specify the type of valid filters allowed under vallist - ObEnhanceSearchList.

A.6 About the Length of the SAMAccountName

The attribute for the Security Access Manager account name (SAMAccountName) in the Active Directory schema is used for backward compatibility with versions of Windows prior to Windows 2000. If you do not need to support these older versions, you can run Active Directory in native mode.

If you need to run Active Directory in mixed mode, Active Directory limits the number of characters that can be specified as the value for the SAMAccountName. By default, Oracle Access Manager accommodates mixed mode and limits the length of SAMAccountName strings to 20 characters.If you are running Active Directory in native mode, you should edit the value of the samAccountNameLength parameter in the globalparams.xml file. This file is located in the following directory:

Component_install_dir/apps/common/bin/globalparams.xml

Where Component_install_dir is the name of the directory where the Oracle Access Manager component is installed. You would edit the value of the following entry in this file:

<SimpleList>
<NameValPair 
    ParamName="samAccountNameLength" 
    Value="20">
</NameValPair>
</SimpleList>

For more information on globalparams.xml, see the Oracle Access Manager Customization Guide.

The user receives an error when defining a person or group with a name that exceeds the limit set for samAccountName in globalparams.xml. The default message is states that this parameter should not exceed 20 characters. The message tag is "MSamAccountNameExceeds20Error"

If you change the value of this parameter, you should also change the error message in the message catalog, globalmsg.xml.