x

1. Select the External Directory radio button on the Authorization line. Note that this selection is not available if you selected Internal authentication.

   A list of available directories opens. This list includes the directories that are built-in to the driver and ones you added.

   

   Each directory is associated with a prefix. In the mrrealm.cfg file, the prefix is prepended to each property needed for configuring authorization using that directory. You can add directories or alternate versions of the same directory (with a new prefix) to the list of available directories. The built-in directories are:

   Directory	Prefix
   Active Directory	AD
   LDAP	LDAP
   DB2	DB2
   SQL Server	SQLS
   SQL Server 2005	SQLS2005
   Oracle	ORCL
   Informix	INFMX
   Sybase	ASE
   My SQL	MYSQL

2. Select the prefix you will use for authorization.
3. Click Save.

   The WebFOCUS Administration Console places the following properties in mrrealm.cfg when you choose Active Directory for authorization:

   AUTHORIZATION.MODE=EXTERNAL
   AUTHORIZATION.PREFIX=AD

   The WebFOCUS Administration Console places the following properties in mrrealm.cfg when you choose LDAP for authorization:

   AUTHORIZATION.MODE=EXTERNAL
   AUTHORIZATION.PREFIX=LDAP

   The WebFOCUS Administration Console places the following properties in mrrealm.cfg when you choose a relational DBMS for authorization:

   AUTHORIZATION.MODE=EXTERNAL
   AUTHORIZATION.PREFIX=prefix

   where:

   prefix

   Is ASE, DB2, INFMX, MYSQL, ORCL,SQLS, or SQLS2005.

x

There are four organizational structures inside a configurable authorization tree.

When nesting groups in Active Directory, the type of group used depends on whether or not any of the users are in a domain that is different from the domain where the MR authorization tree is located. This is often the case in large Active Directory trees and forests where users are scattered among multiple domains and the authorization tree is in one domain, typically the root domain. In this case, you must use Universal Groups for the nested groups so that they can be seen by the Global Catalog. When the users are all in the same domain as the authorization tree, you can use Global groups for the nested groups. In either case, you must use Domain Local groups as the nesting groups that have as members the nested groups. This relationship is shown in the preceding diagram.

x

Using Active Directory group entries for MR authorization data has some limitations. The pre-Windows 2000 group name itself cannot contain an equal sign (the '=' character). Certain MR privileges contain the equal sign such as the gagroups=default and dadomains=salesdom flags. When creating entries of this type you must substitute the underscore for the equal sign in the pre-Windows 2000 group name field but not in the common name (cn) attribute of the group, which requires the equal sign. When creating entries with a Visual Basic script, use the load scripts described in How to Load Sample Active Directory Data as a reference. When using Active Directory Users and Computers create the entries this way:

x

Note: If some of your users will be in a domain other than the domain where the authorization tree is being created, you must first edit the Visual Basic script described in this procedure and convert the references from Global groups to Universal groups. For more information, see Active Directory Schema.

The following steps describe how to create the authorization tree in Active Directory:

1. Move the ad_load_az_tree.vbs script found in the inst_dir\WebFOCUS\utilities\realm directory to the Active Directory server.
2. Create the authorization container that will hold the Realm Driver authorization tree by using the Active Directory Users and Computers interface. You must be an administrator to perform this step.

   

   Give the authorization container a name, for example ibimr_test and click OK.

   

3. Double-click ad_load_az_tree.vbs.
4. Enter the path to the container you just created and then click OK. Do not use spaces around the commas. For example, ou=ibimr_test,ou=apps,dc=ibadtest,dc=int.

   

5. Enter an optional prefix for your authorization entries and click OK (for example, test_). This value will be prepended to each authorization entry sAMAccountName created by the script. If you leave this field blank, no prefix will be added to the entries.

   

   A prefix makes it easier to search for your MR authorization entries. It also makes it possible to have two or more MR authorization trees in your directory at the same time because each group entry must be unique in the directory. You might want to do this so you can have a Test and Development environment point to the same directory.

   A message reminds you to load the sample data when the script finishes.

   

The following image shows you the four built-in roles added by the script.

x

Note: If some of your users will be in a domain other than the domain where the authorization tree is being created, you must first edit the Visual Basic script described in this procedure and convert the references from Global groups to Universal groups. For more information, see Active Directory Schema.

After you have created your authorization tree, load the sample data:

1. Move the ad_load_sample_data.vbs script found in the install_dir\WebFOCUS\utilities\realm directory to the Active Directory server.
2. Double-click ad_load_sample_data.vbs. You must be an administrator to run this script.
3. Enter the path to the container you created previously and then click OK.

   For example, the following screen shows the path ou=ibimr_test,ou=apps,dc=ibadtest,dc=int.

   

4. Enter the prefix value you entered previously when creating the authorization tree and click OK.

   For example, the following image shows the prefix test_.

   

   A message reminds you to link users to groups when the script finishes.

   

The following image shows a sample privilege added by the script.

Be careful when creating a dadomains or gagroups privilege in Active Directory. The Managed Reporting user interface components require that the dadomains privilege be received in the format dadomains=untitled%2crealmdm1 and gagroups=realmsampgrp%2cdefault in order to restrict developer access to only the untitled and realmdm1 domains (this is a specific example, your domain names will be different). The delimiter %2c must be used to delimit multiple domains or groups. This is a requirement of the Managed Reporting user interface components. For information about dadomains and gagroups, see the WebFOCUS Managed Reporting Administrator's Manual.

The optional Managed Reporting Domain properties Server and Application Path are also defined as privileged entries in Active Directory. For more information about optional domain properties, see Defining the Server and Application Path Properties for a Managed Reporting Domain.

Note: The pre-Windows 2000 group name field cannot contain an equal sign (the '=' character). For information about how to handle this issue, see Creating Privilege Flags That Contain an Equal Sign.

x

The following additional properties must be configured using the WebFOCUS Administration Console for Active Directory authorization. To access the Active Directory authorization properties, click the External Directories menu under the MR Security Settings section and then double-click the AD radio button. In the mrrealm.cfg file, each property begins with the prefix value you selected as your authorization prefix: x x

USER.DESCRIPTION

Defines the attribute used to retrieve the full name of the user for display purposes in Managed Reporting. Initially set to displayName for the built-in AD prefix.

x x

USER.EMAIL

Defines the attribute used to retrieve the e-mail account of the user in order to create the ReportCaster account (if configured). In Version 7.1.3 and higher installations, this is initially set to mail for the built-in AD prefix. If you are upgrading an earlier 7.1.x release, you should change this to mail or a valid attribute in your directory.

x x

USER.MEMBERSHIP

Defines the attribute used to retrieve the group, role, and privilege entries of the user in the authorization tree. Initially set to memberOf for the built-in AD prefix.

x x

GROUP.BASE

Defines the location of the authorization tree. The container specified must contain the Domains, Groups, Privileges, and Roles containers created by the load scripts. Initially set to ou=ibimr,ou=apps,dc=domain,dc=com for the built-in AD prefix.

x x

GROUP.PREFIX

Defines the string prepended to the common name when searching for authorization entries. This setting is initially left blank, which means no string is prepended. This setting is required whenever there will be more than one authorization tree in a single directory since the common names of groups in a directory must be unique. Initially set to test_ for the built-in AD prefix.

x x

GROUP.CLASS

Defines the class name used in the LDAP search for authorization entries. Initially set to group for the built-in AD prefix.

x x

GROUP.DESCRIPTION

Defines the attribute used to retrieve the description of an authorization entry for display purposes in Managed Reporting. For example, displaying the Groups available in Dashboard View Builder. Initially set to description for the built-in AD prefix.

x x

GROUP.MEMBERSHIP

Defines the attribute used to retrieve the nesting group(s) of an entry in the authorization tree. For example, the MR Domain(s) available to the MR Public Group are found by following the memberOf attribute(s) on the Public Group entry. Initially set to member Of for the built-in AD prefix.

x x

GROUP.MEMBERS

Defines the attribute used to retrieve the nested group(s) of an entry in the authorization tree. For example, the MR Group(s) with access to the MR Untitled Domain are found by following the member attribute(s) on the Untitled Domain entry. Initially set to member for the built-in AD prefix.

x x

GROUP.NAME

Defines the attribute used to locate entries in the authorization tree. Initially set to name for the built-in AD prefix.

After editing the properties, click Save to save the values or Cancel to leave them as they were before.

x

You can create your own authorization entries in batch or interactively. Use the Visual Basic Script shown in How to Load Sample Active Directory Data as an example of how to load and maintain authorization entries in batch. You can also create and maintain your authorization entries by using the Active Directory Users and Computers tool as shown in Using Active Directory Users and Computers to Create Authorization Entries. You may wish to delegate administration of the ou=ibimr_test container to a specific set of individuals.

x

You can use the Microsoft Active Directory Application Mode (ADAM) for Managed Reporting authorization, although using the ADAM ADSI Edit snap-in for the Microsoft Management Console is more tedious than using the Active Directory Users and Computers interface supported by Active Directory. For more information about using ADAM, see Technical Memo 4607: Using ADAM for Managed Reporting Authorization.

Top of page

Example: Using Active Directory Users and Computers to Create Authorization Entries

In the following example, you create the authorization entry for an MR Domain with the internal identifier salesdom and put it into an MR Group called Sales Group.

1. Create the MR Domain Sales Domain in Managed Reporting by using either Developer Studio or the Managed Reporting Domain Builder applet. After creating the domain, check its properties and verify that its HREF property is salesdom/salesdom.htm.
2. Switch to Active Directory Users and Computers and create a new group entry for the MR Domain under the ou=Domains container. Follow the naming convention used by the load scripts. Because this is an MR Domain, you must set Group scope to Domain local. See Active Directory Schema for more information about Group scope.

   

3. After you create this entry, open it and set its Description. The following text is displayed in WebFOCUS:

   

4. Next, create the MR Group Sales Group under the ou=Groups container. Set Group scope to Global or Universal (depending on your directory) because this is an MR Group entry.

   

5. After you create this entry, open it and set its Description. This is the text that will display in WebFOCUS.

   

6. Click the Member Of tab and then click the Add button. In the Select Groups dialog enter the text that identifies all of your MR Domain entries, for example: test_ibimr-dmn.

   

   Click OK to search for these entries.

7. Select the authorization entry for the Sales Domain and click OK.

   

8. If you are ready to add users to the MR Sales Group, you can click the Members tab and repeat the search/add process for those users. Otherwise, click OK to save your updated Sales Group entry.

   

Top of page

Example: Defining the Server and Application Path Properties for a Managed Reporting Domain

In the following example, you create the Active Directory entries necessary for the Sales Domain to be bound to the EDASERVE server node with an application path of app1 and app2.

Domain properties are defined similar to the way privileges are defined for a role except that the Group scope is set to Global or Universal (not Domain local).

1. Create the node=EDASERVE privilege under the ou=Privileges container. Set Group scope to Global or Universal (depending on your directory).

   

   Multiple application names (if applicable) are separated with a ‘%20’ string.

2. Create the appname=app1%20app2 privilege under the ou=Privileges container and set Group scope to Global or Universal. As explained previously for the gagroups and dadomains privileges, the pre-Windows 2000 Group name cannot contain an ‘=’ sign. We recommend replacing it with an ‘_’ .

   

3. Add the two properties to the Domain using its Members tab.

   

   Note: If you cannot find the two properties in the search dialog, ensure that you created them with Group scope of either Global or Universal.

4. Click OK to save your change.