Sample Deployment Scenarios

This topic contains the following deployment scenarios as examples:

Scenario 1: Single LDAP Directory

Figure 1 illustrates a deployment scenario that uses LDAP.

Figure 1: Authentication Against a Single Instance of an LDAP Directory

The configuration file resides on the application server, as do the Hyperion application binaries. You should configure for external authentication as described in Configuration for External Authentication. The application server can be on UNIX, a Windows NT 4.0 server, or a Windows 2000 server. The directory server can be on UNIX, a Windows NT 4.0 server, or a Windows 2000 server.

You can use a secure SSL connection as an option.

The directory server and the application server can be combined into one server. In such a scenario, the application binaries and the directory server binaries reside on the same server.

The single LDAP directory scenario has the following requirements:

A sample corporate directory schema follows:

Scenario 2: Single Microsoft Active Directory

Figure 2 illustrates a deployment scenario that uses Microsoft Active Directory.

Figure 2: Authentication Against a Single Instance of Microsoft Active Directory

The configuration file resides in the application server, as do the Hyperion application binaries. You should configure for external authentication as described in Configuration for External Authentication. The application server can be on UNIX, a Windows NT 4.0 server, or a Windows 2000 server. The directory server must be on a Windows 2000 server, because Microsoft Active Directory is a Windows 2000 implementation.

You can use a secure SSL connection as an option.

The directory server and the application server can be combined into one server. In this scenario the application binaries and the directory server binaries reside on the same server.

The single Microsoft Active Directory scenario has the following requirements:

A sample corporate directory schema follows:

Scenario 3: UNIX Application and Single NTLM Domain

Figure 3 illustrates a deployment scenario in which a UNIX-based application accesses information from a Windows NT LAN Manager domain controller. This implementation depends also on the Hyperion Remote Authentication Module that is configured and running on a Windows NT or Windows 2000 machine. The Remote Authentication Module can be installed using the Analytic Services installation software. The Remote Authentication Module is needed because the external authentication mechanism depends on the NTLM support library file (css-2_5_x.dll) for NTLM authentication, and dlls are not supported on UNIX.

Figure 3: Authentication from a UNIX-Based Application Server Against a Single Instance of NTLM

Note: The Hyperion Remote Authentication Module enables communication between NTLM and a UNIX-based application. Install the Hyperion Remote Authentication Module from the Analytic Services installation software.

The configuration file resides on the application server, as do the Hyperion application binaries. The NTLM support library file (css-2_5_x.dll) is also required for NTLM connectivity. You should configure for external authentication as described in Configuration for External Authentication. The NTLM Primary Domain Controller can be on a Windows NT 4.0 server or on a Windows 2000 server. The Hyperion Remote Authentication Module should be on Windows NT 4.0 server or on a Windows 2000 server. Combining the Remote Authentication Module with the NTLM Primary Domain Controller is not recommended. The Remote Authentication Module machine needs to be in the same domain as the NTLM Primary Domain Controller.

Scenario 4: Windows Application and Single NTLM Domain

Figure 4 illustrates a deployment scenario in which a Windows-based application accesses information from a Windows NT LAN Manager domain controller.

Figure 4: Authentication from a Windows-Based Application Server Against a Single Instance of NTLM

The configuration file resides on the application server, as do the Hyperion application binaries. The NTLM support library file (css-2_5_x.dll) is also required for NTLM connectivity. You should configure for external authentication as described in Configuration for External Authentication. The NTLM Primary Domain Controller can be on a Windows NT 4.0 server or on a Windows 2000 server.

Scenario 5: UNIX Application Against LDAP, Microsoft Active Directory, and NTLM

Figure 5 illustrates a deployment scenario in which a UNIX-based application accesses information from multiple directory stores. The Hyperion Remote Authentication Module is required for access to the Windows NT LAN Manager domain, as in Scenario 3. Configuration of the search order becomes important in this scenario.

Figure 5: Authentication from a UNIX-Based Application Server Against an LDAP Directory, a Microsoft Active Directory, and NTLM

Note: The Hyperion Remote Authentication Module enables communication between NTLM and a UNIX-based application. Install the Remote Authentication Module from the Analytic Services installation software.

The configuration file resides on the application server, as do the Hyperion application binaries. The NTLM support library file (css-2_5_x.dll) is also required for NTLM connectivity. You should configure for external authentication as described in Configuration for External Authentication. The NTLM Primary Domain Controller server can be on a Windows NT 4.0 Server or on a Windows 2000 server. The Hyperion Remote Authentication Module machine needs to be in the same domain as the NTLM Primary Domain Controller.

For LDAP-compatible directories, you can use a secure SSL connection as an option.

The configuration of the search order property in the .xml configuration file determines the order in which each directory store receives requests for information from the application. For example, the first instance of a requested user found while going through the search order is the instance that is used to retrieve and return information about the user to the application. Therefore, although there are three directories that can host user information, it is recommended that user information not be duplicated across the directories. Duplication can lead to authentication of the incorrect user object.

For information about configuring the search order, see Provider Search Order.

Scenario 6: Windows Application Against LDAP, Microsoft Active Directory, and NTLM

Figure 6 illustrates a deployment scenario in which a Windows-based application accesses information from multiple directory stores.

Figure 6: Authentication from a Windows-Based Application Server Against an LDAP Directory, a Microsoft Active Directory, and NTLM

The configuration file resides on the application server, as do the Hyperion application binaries. The NTLM support library file (css-2_5_x.dll) is also required for NTLM connectivity. You should configure for external authentication as described in Configuration for External Authentication. The NTLM Primary Domain Controller can be on a Windows NT 4.0 server or on a Windows 2000 server.

For LDAP-compatible directories, you can use a secure SSL connection as an option.

The configuration of the search order property in the .xml configuration file determines the order in which each directory store receives requests for information from the application. For example, the first instance of a requested user found while going through the search order is the instance that is used by the external authentication mechanism to retrieve and return information about the user to the application. Therefore, although there are three directories that can host user information, it is recommended that user information not be duplicated across the directories. Duplication can lead to authentication of the incorrect user object.

For information about configuring the search order, see Provider Search Order.

Scenario 7: Multiple Microsoft Active Directory Instances

When multiple Microsoft Active Directory instances hold user authentication information, you must create a single instance of Active Directory that hosts all the user information. Enabling a single instance to be used for external authentication is left to the individual installation. One way to centralize the user information is to enable replication between the instances to the master directory server, as shown in Figure 7.

Figure 7: Authentication with Multiple Microsoft Active Directory Instances

The configuration file resides on the application server, as do the Hyperion application binaries. You should configure for external authentication as described in Configuration for External Authentication.

You can use a secure SSL connection as an option.

Scenario 8: Multiple LDAP Directory Instances

When multiple LDAP directory instances hold user authentication information, you must create a single instance of LDAP that hosts all the user information. Enabling a single instance to be used for external authentication is left to the individual installation. One way to centralize the user information is to enable replication between the instances to the master directory server, as shown in Figure 8.

Figure 8: Authentication with Multiple LDAP Directory Instances

The configuration file resides on the application server, as do the Hyperion application binaries. You should configure for external authentication as described in Configuration for External Authentication.

Scenario 9: Multiple NTLM Domains With Trust Relationships

When there are multiple Windows NT LAN Manager domains which hold user authentication information, one solution is to establish trust relationships between the domains, as shown in Figure 9.

Figure 9: Authentication with Trusted NTLM Domains

The configuration file resides on the application server, as do the Hyperion application binaries. The NTLM support library file (css-2_5_x.dll) is also required for NTLM connectivity. You should configure for external authentication as described in Configuration for External Authentication. The NTLM Primary Domain Controllers can be on Windows NT 4.0 servers or on Windows 2000 servers.

Scenario 10: Multiple NTLM Domains Connected With Hyperion Remote Authentication Module

When there are multiple Windows NT LAN Manager domains which hold user authentication information, an additional solution is to link the domains using the Hyperion Remote Authentication Module. As compared to the previous scenario, this scenario eliminates the necessity of establishing trust relationships between the domains.

Scenario 10: Authentication with Untrusted NTLM Domains and Hyperion Remote Authentication Module

The Hyperion Remote Authentication Module gives users of Hyperion applications on Windows the ability to log in using multiple domains, without the need for the administrator to create trust relationships between the domains. In the figure above, Windows users may optionally log in using domain "D2" in addition to the more commonly used domain "D1," because the Hyperion Remote Authentication Module is running, giving access to domain "D2." Note that D1 does not trust D2.

The configuration file resides on the application server, as do the Hyperion application binaries. The NTLM support library file (.dll) file is also required, for the NTLM connectivity. The configuration for external authentication should be done as described in the rest of this document. The NTLM Primary Domain Controllers can be on Windows NT 4.0 servers or Windows 2000 servers.

The security platform can communicate over a secure medium such as Secure Sockets Layer (SSL) with the Hyperion Remote Authentication Module. If you need to use SSL, select the SSL option when installing the Hyperion Remote Authentication Module. For complete installation instructions, download and read the installation and setup instructions provided with the Hyperion Remote Authentication Module on the Hyperion Download Center.

©2004 Hyperion Solutions Corporation. All Rights Reserved.
http://www.hyperion.com