|Oracle® Access Manager Identity and Common Administration Guide
Part Number B25343-01
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:
For additional information and procedures, see the Oracle Access Manager Installation Guide. See also:
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.
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".
Navigate to the Identity System Console.
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.
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.
Navigate to the Identity System Console.
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.
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.
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.
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.
<SimpleList > <NameValPair ParamName="maxForRangedMemberRetrieval" Value="1500"/> </SimpleList>
Save the file.
Restart the Identity Server.
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:
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.
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.
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:
Using these rules, managers who are in both foo and goodwill can be authorized.
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
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.
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,
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.
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 Form Based:
For Oracle Access and Identity:
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.
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.
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:
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.
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:
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:
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.
See also, "Resolving Ambiguous Names".
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:
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.
Oracle Access Manager provides support for .NET features with Windows Server 2003. See "Implementing .NET Features" for details.
For details about the following topics, see the Oracle Access Manager Integration Guide.
Integrating with the Authorization Manager
Integrating with Smart Card Authentication
Integrating with the Security Connector for ASP.NET
For information on troubleshooting, see Troubleshooting Oracle Access Manager.
Active Directory Home Page
Active Directory Programmers Page
ADSI Programmers Page