3.12 Sample Configuration for Protecting an Application Through Access Manager

This section explains how to use Access Manager to protect the Web site illustrated in the following figure. The sample application that comes by default with the Access Manager Appliance showcases the various Access Manager features. Ensure that you remove the landing portal in the production environment. Instructions for removing this portal are given on the landing page.

Figure 3-24 Digital Airlines Web Services

This section explains how to configure the Access Manager components to allow access to this first page and how to create and assign policies that protect the other pages.

The example Web pages are designed to help network administrators understand the basic concepts of Access Manager by installing and configuring a relatively simple implementation of the software. The example serves as a primer for a more comprehensive production installation of Access Manager.

3.12.1 Installation Overview and Prerequisites

This section discusses the concepts involved in installing Access Manager to protect the example Digital Airlines Web site:

After you deploy this example, you should understand the basic features of Access Manager and know how to configure the software to protect your own Web servers and applications.

Installation Architecture

The diagram below illustrates how the Digital Airlines example is integrated with Access Manager.

Figure 3-25 Digital Airlines Architecture

This document explains how to use a browser machine and two other machines for this configuration.

Table 3-1 NetIQ Access Manager Components

 

Administration Console

Identity Server

Access Gateway

Application Web Server

LDAP User Store

Browser

Machine 1

X

X

 

X

X

 

Machine 2

 

 

X

 

 

 

Machine 3

 

 

 

 

 

X

The simplified configuration described in this document is for a test environment only. It is not a recommended or supported configuration for a production environment. For example, the configuration database installed with the Administration Console should not be used as an LDAP user store in a production environment. In a production environment, you would not want to install Administration Console, Identity Server, and Web server on the same machine. This simplified configuration is designed to minimize the number of machines required for a tutorial.

After deploying the Digital Airlines example, you should understand the concepts required to deploy Access Manager in a number of other configurations. In a production environment, you need to install the necessary Access Manager components according to your specific requirements. For more information about other possible installation configurations, see the Installing Access Manager in the NetIQ Access Manager 4.1 Installation and Upgrade Guide.

Deployment Overview

Prerequisite Tasks

Before starting with the Digital Airlines example, you must perform the following tasks:

  • Enable pop-ups on a Firefox browser (3.x or above) or Internet Explorer browser (7.x or above) for managing and configuring the Access Manager components.

  • Install NetIQ Access Manager Administration Console, Identity Server, and Access Gatewayas described in the Installing Access Manager in the NetIQ Access Manager 4.1 Installation and Upgrade Guide.

  • Configure the NetIQ Access Manager Identity Server. For configuration details, see Section 3.3, Configuring an Identity Server.

    IMPORTANT:The Digital Airlines procedures explain how to add a user to the configuration store of the Administration Console. These instructions assume that you have configured the Identity Server to use this configuration store as the LDAP user store. This is not a recommended configuration for a production environment. To enable this configuration for a test environment, specify the IP address of the Administration Console for the address of the server replica.

Do not configure the Access Gateway at this time. Other tasks explain how to configure the Access Gateway to allow access to the Digital Airlines site on the Web server.

Deployment Tasks

To configure access to the Digital Airlines site, you need to complete the following tasks:

  1. Set up the Apache Web server on your Identity Server, then install the Digital Airline pages.

    For more information, see Section 3.12.2, Setting Up the Web Server.

  2. Configure the Access Gateway to protect the Web server, but allow public access to the site. See Section 3.12.3, Configuring Public Access to Digital Airlines.

  3. Configure the Access Gateway to allow access to the protected pages. See Section 3.12.4, Implementing Access Restrictions.

3.12.2 Setting Up the Web Server

Installing the Apache Web Server and PHP Components

The following instructions are for SLES 11 SP1 and SP2.

  1. Download and install the Apache 2 and PHP 5 modules:

    1. On your SLES 11 SP1 and SP2 server, click the YaST icon, provide your root password if requested, then click OK.

    2. In the YaST left navigation window, click the Software icon, then click Software Management.

      The YaST software Search screen should open.

    3. In the Search field, type Apache2, then click Search.

      All available Apache 2 software packages are listed.

    4. If they are not already selected, select the following Apache 2 check boxes:

      apache2: Specifies the Apache 2.0 Web server.

      apache2-mod_php5: Specifies the PHP5 module for Apache 2.0.

      apache2-prefork: Specifies the Apache 2 prefork multiprocessing module.

      apache2-worker: Specifies the Apache 2 worker multiprocessing module.

    5. Click Accept.

    6. Verify that the php5 package is also selected for install, then click Continue to install that package as well as the other dependent packages.

  2. Configure SUSE to start the Apache server during boot up:

    1. In the YaST left navigation window, click Network Services > HTTP Server.

    2. In the HTTP Server Wizard, enable the Start Apache2 Server When Booting option, then click Finish.

    3. Reboot the server or manually start the Apache server.

Installing Digital Airlines Components

The Digital Airlines example package contains the following components:

  • vpn.html: Specifies the GUI interface page for initiating a VPN session.

  • sales.php: Contains the sales PHP database files associated with the example.

  • payroll.html: Specifies the GUI interface page for initiating a payroll session.

  • medical.html: Specifies the GUI interface page for initiating a VPN session.

  • index.php: Contains the welcome HTML index file for establishing secure authentication.

  • sales: Specifies a subdirectory that can be configured to require basic authentication.

  • images: Contains all image files associated with the example.

In this example configuration, you use the Access Gateway to protect the Digital Airlines Web site, which is installed on your Identity Server. This section describes where your example Digital Airlines components are located and how to add them to your Identity Server.

  1. Download the Digital Airlines Sample Pages.

  2. Extract htdocs.tar.gz to a root directory of the Web server. For an Apache 2 Web server on SLES 11 SP1 and SP2, extract the files to the following directory:

    /srv/www/htdocs/

  3. Determine the DNS name and IP address of the SUSE Linux server on which your example files are installed:

    1. Log in to the YaST as the root user.

    2. Click Network Services > Host Names, then write down the IP address and hostname of your server:

      IP Address: __________________________

      Hostname: __________________________

      As required later in the installation (see Step 7), you must provide the host name and server configuration information to establish the network connection between the Web server you are protecting (the server where your Web service components are located) and the Access Gateway.

  4. Continue with Configuring Name Resolution.

Configuring Name Resolution

The Identity Server needs to resolve the DNS name of the Access Gateway, the Access Gateway needs to resolve the DNS name of the Identity Server, and the client that is accessing the Digital Airlines site needs to be able to resolve the names of both the Access Gateway and the Identity Server.

You can either set up your DNS server to resolve the DNS name of the Identity Server and the Access Gateway to the correct IP address, or you need to modify the hosts file on the various machines to perform the resolution.

Each platform has its own location for the host file.

Platform

Location

Windows

\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS

Linux

/etc/hosts

Client: The hosts file of the client machine needs to contain entries for the Identity Server and the Access Gateway.

Identity Server: The hosts file on the Identity Server needs to contain an entry for the Access Gateway.

Access Gateway: The hosts file on the Access Gateway needs to contain an entry for the Identity Server.

  • Access Gateway Appliance: Do not manually edit the hosts file on the Access Gateway Appliance. The file is overwritten every time the configuration is updated with the entries specifies on the Hosts page. To add an entry to the Hosts page, click Devices > Access Gateways > Edit > Hosts, then click New. The entries on this page are written to the hosts file when the configuration is updated.

  • Access Gateway Service: You can edit the hosts file on the Access Gateway Service. Add an entry that allows the Access Gateway Service to resolve the name of the Identity Server.

Continue with Section 3.12.3, Configuring Public Access to Digital Airlines.

3.12.3 Configuring Public Access to Digital Airlines

This section describes the procedures for configuring the Access Gateway so that a client can access the Digital Airlines site. Before continuing, make sure you have completed the prerequisite tasks described in Prerequisite Tasks and Section 3.12.2, Setting Up the Web Server.

  1. On the client machine, open a browser and log in to the Administration Console.

  2. In the Administration Console, click Devices > Access Gateways.

    The IP address or name of the Access Gateway you installed should be listed in the display window.

    An Access Gateway that has not been configured displays a yellow health status.

  3. Click Edit > Reverse Proxy / Authentication.

  4. In the Identity Server Cluster option, select the configuration you have assigned to the Identity Server.

    This sets up the trust relationship between the Access Gateway and the Identity Server that is used for authentication.

  5. In the Reverse Proxy List, click New, specify DAL as the new Reverse Proxy Name, then click OK.

  6. Enable a listening address.

    If the server has only one IP address, only one is displayed and it is automatically selected as the Listening Address. If the server has multiple addresses, you can select one or more IP addresses to enable. You must enable at least one address by selecting its check box.

  7. Configure a listening port.

    Non-Secure Port: Select 80, which is the default port for HTTP.

    Secure Port: This is the HTTPS listening port. This port is unused and cannot be configured until you enable SSL. This configuration scenario does not contain SSL configuration instructions.

  8. In the Proxy Service List, click New and specify the following information:

    Proxy Service Name: Specify any name that intuitively identifies this service on your Access Gateway server. For this example, specify Dallistener.

    Public DNS Name: The DNS name you want the public to use to access your Digital Airlines site. This DNS name must resolve to the IP address you set up as the listening address. This example uses am3bc.provo.novell.com.

    Web Server IP Address: The IP address of the Web server where your Digital Airlines files are installed.

    Host Header: Select Forward Received Host Name from the drop-down menu. The Web server and the Digital Airlines pages have not been set up to require the DNS name of the Web server in the Host Header, so it does not matter what name is placed in the Host Header.

    Your form should look similar to the following:

  9. Click OK.

  10. In the Proxy Service List, click Dallistener.

  11. Click Protected Resources, then in the Protected Resource List, click New.

  12. Type everything in Name, then click OK.

  13. In the Authentication Procedure field, select None from the drop-down menu.

    Under URL Path List, you should see /*, which includes everything on that server.

    Later on, you will be instructed to change the Authentication Procedure field to a Name/Password - Form, but for now, we want you to learn how the example works without any authentication.

  14. Click OK.

  15. In Protected Resource List, verify that the protected resource you created is enabled, then click OK.

  16. Click the Devices > Access Gateways.

  17. To apply the changes, click Update > OK.

    Until this step, nothing has been saved. The Update status pushes the configuration to the server. When the configuration update has completed successfully, the server returns the status of Current.

  18. To update the Identity Server for the trusted relationship, click Devices > Identity Servers, then click Update > OK.

  19. To test the results, complete the following.

    1. Open a browser on the client machine.

    2. Enter the URL for the proxy service. For this example, it is 

      am3bc.provo.novell.com

      Your network needs to be configured so that this published DNS name of the proxy service resolves to the IP address of the Access Gateway. The reverse proxy hides the internal address of the Web server.

      You should see the Digital Airlines page.

      If you get an error, check the time on the Access Gateway and Identity Server. Their time should be synchronized and must be within 5 minutes of each other.

  20. Close the browser.

  21. To require authentication for access to the site and to configure access to the protected pages (the VPN application and the hidden Sales System site), continue with Section 3.12.4, Implementing Access Restrictions.

    Currently, the Corporate Mail and Medical Benefits Portal buttons do not link to available pages. They exist to illustrate what you could do when you require your users to authenticate before accessing the site.

    For example, the Corporate Mail button could be configured so that the redirected request initiates a mail session to the user’s default e-mail application and injects the login credentials to provide access to the user’s protected, Web-based e-mail account.

    The Medical Benefits Portal button could be configured to set up a federated account with the company that provides medical benefits for your company.

3.12.4 Implementing Access Restrictions

After you access the Digital Airlines site as a public resource (see Section 3.12.3, Configuring Public Access to Digital Airlines), you can configure the site for authentication and authorization requirements. This section describes the following tasks:

Enabling an Authentication Procedure

After hiding the internal Web server behind the Access Gateway, you can add an authentication method to the Web site by using the following procedure:

  1. In the Administration Console, click Devices > Access Gateways > Edit.

  2. Click DAL > Dallistener > Protected Resources > everything.

  3. In the Authentication Procedure field, select Name/Password - Form.

    IMPORTANT:Make sure to select the Name/Password - Form from the drop-down menu. Secure Name/Password does not work correctly if the base URL for the Identity Server is HTTP.

  4. Click OK to return to the Protected Resources page.

  5. Click Devices > Access Gateways, then click Update > OK.

    This pushes the new configuration to the server. When the configuration process is complete, the status returns to Current.

  6. To test the results, open a browser and enter the URL of your Web site.

    The Web site should now be protected and require you to log in by using a name and password.

  7. Enter the credentials of the admin user of your Administration Console.

    The Digital Airlines site appears. If you receive an error, see Common Authentication Problems.

  8. Close all sessions of the browser.

    The Digital Airlines page has a logout graphic, but it isn’t an action. The current session is active until you log out (which isn’t possible), until the session times out (the default value is 20 minutes), or you close all sessions of the browser.

  9. Continue with Configuring a Role-Based Policy.

Common Authentication Problems

In this basic configuration there are two common configuration errors that can cause login to fail:

Error 300101015: If your Access Gateway and Identity Server do not have the same time, the assertion is invalid. Check the time of each machine.

Errors 100101043 and 100101044: The Identity Server and the Access Gateway need to be able to resolve each other’s DNS names. If you are in a lab and not using a DNS server, make sure the host files of each machine have been configured to resolve the DNS name to the IP address of the device.

The other cause for these errors, when SSL has not been enabled, is the failure to update either the Identity Server or the Access Gateway after making a change to the base URL of the Identity Server or modifying the Identity Server the Access Gateway is trusting for authentication.

For information about how to force the Access Gateway to update the metadata for the Identity Server, see Embedded Service Provider Metadata.

Configuring a Role-Based Policy

You learned how to set up and configure Access Manager to protect a basic Web service. Access Manager also uses role-based access control (RBAC) to conveniently assign a user to a particular job function or set of permissions within an enterprise, in order to control access.

Access Manager enables you to assign roles to users, based on attributes of their identity, and then associate policies with the roles. In designing your own actual production environment, you need to decide which roles you need (such as, sales, administrative, and accounting). You create Role policies that assign the roles to your users, and then you create Authorization and Identity Injection policies that use the roles to control access.

This section explains how to set up an Identity Injection policy that customizes the main page of the Digital Airlines site. When the index.php page has access to the user’s name, the main page displays the name. If the user belongs to the sales_role role, the Sales System button is displayed on the page.

To configure an Identity Injection policy that uses a role, complete the following tasks:

Adding an LDAP Attribute to Your Configuration

The LDAP attribute that is added in this section is an LDAP attribute assigned to the User class in eDirectory. This attribute is used to assign users to the sales role.

  1. In the Administration Console, click Devices > Identity Servers, then click Shared Settings > Custom Attributes.

  2. In the LDAP Attribute Names section, click New, type description in the Name field, then click OK.

    This adds the description attribute to the policy list of available LDAP attributes, and you can use this attribute to assign a role to your users.

  3. Click Close.

  4. Continue with Creating a Sales Role.

Creating a Sales Role

Use the following procedure to create a sales role for the Digital Airlines example. (For more information about Role policies, see Section 6.2, Role Policies.)

  1. In the Administration Console, click Devices > Identity Servers, then click Edit > Roles.

  2. In the Roles Policy List section, click Manage Policies.

  3. In the Policy List section, click New, then fill in the following fields:

    Name: Specify Sales_Role.

    Type: Select Identity Server: Roles.

  4. Click OK to open the policy editor.

  5. In Condition Group 1, click New > LDAP Attribute, and assign the following values:

    LDAP Attribute: Select description. (If description is not included in the LDAP Attribute list, you can add it from this page. For instructions, see Step 5.a through Step 5.c.)

    Comparison: Select String: Contains Substring.

    Mode: Select Case Insensitive.

    Value: Select Data Entry Field (from the drop-down box); specify Sales as the value.

    Result on Condition Error: Select False.

    If the description attribute is not listed in the LDAP Attribute drop-down menu, create it by following this procedure:

    1. In Condition Group 1, click New > LDAP Attribute, scroll to the bottom of the list, then click New LDAP Attribute.

    2. In the Name field, specify description, then click OK.

    3. In the LDAP Attribute field, select description from the drop-down menu.

  6. In the Actions section, click New > Activate Role, then specify sales_role in the Do Activate Role field. Your rule should look similar to the following:

    The value for Activate Role might be case sensitive. If you are going to inject this role into a policy for a Web server, and the page on the Web server is configured so that it evaluates case, make sure the value entered here matches what is expected on the Web server. The Sales System button on the Digital Airlines site requires that this value be lowercase: sales_role.

  7. Click OK to close the Rule editor, then click OK to close the Rule List.

  8. To save the Role policy, click Apply Changes, then click Close to return to the Roles Policy List.

  9. In the Roles Policy List, select Sales_Role, then click Enable.

  10. Click OK.

  11. Update the Identity Server.

    Wait for the Status to return to Current.

  12. Continue with Creating a New User with a Sales Role.

Creating a New User with a Sales Role

After you have created a user policy, only users provisioned with that policy can access the protected Web resource. This section describes how to create a user that meets the conditions to be assigned the Sales role. These instructions assume that you are using the configuration store of the Administration Console as the LDAP user store. If you are using a different server than the LDAP user store, you need to modify these instructions:

  1. In the Administration Console, click the Roles and Task icon in the top menu bar.

  2. Click Users.

  3. Click Create User, then fill in the following fields:

    Username: Specify Tom.

    First name: Specify Tom.

    Last name: Specify Tester.

    Context: Click the Object Selector icon, then click novell. The user is automatically assigned the context of novell.

    Password: Assign a password to the user.

    Retype password: Retype the assigned password.

    Your user entry should look similar to the following:

  4. Scroll to the Description field, then click the + icon.

  5. In the Add text box, type Sales (initial uppercase), then click OK to return to the Create User page.

  6. On the Create User page, click OK, then click OK to close the Create User task.

    Tom meets the requirements to be assigned the Sales role when he logs in.

  7. Continue with Creating the Identity Injection Policy for a Custom Header.

Creating the Identity Injection Policy for a Custom Header

The following policy injects the user’s roles and DN into a custom header. The index.php page reads this information and uses it to display the user’s name. If the user is assigned the sales_role, the Sales System button is displayed on the main page.

  1. In the Administration Console, click the Access Manager icon in the top menu bar.

  2. Click Devices > Access Gateways, then click Edit > DAL > Dallistener > Protected Resources > everything.

  3. Click Identity Injection > Manage Policies.

  4. In the Policy List section, click New, then fill in the following:

    Name: Specify Custom_Injection.

    Type: Select Access Gateway: Identity Injection.

  5. In the Actions section, click New > Inject into Custom Header.

  6. To inject the user’s name, fill in the following values:

    Custom Header Name: Specify X-Name.

    Value: Select Credential Profile. The LDAP Credentials: LDAP User Name is selected automatically for you.

  7. To inject the user’s roles, click New > Inject into Custom Header, then fill in the following values for the second custom header:

    Custom Header Name: Specify X-Role.

    Value: Select Roles.

    Your policy should look similar to the following:

  8. Click OK twice, then click Apply Changes.

  9. Click Close.

  10. In the Identity Injection Policy List section, select Custom_Injection, then click Enable.

  11. Click OK.

  12. Click Devices > Access Gateways, then click Update > OK.

  13. To test Tom’s access rights, complete the following steps:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. When prompted for user ID and password from Access Manager, log in with Tom’s credentials.

      The page appears with a Welcome: Tom message at the top, and the Sales System button appears in the lower right corner of the page.

    3. Click the Sales System button, and the Sales page appears.

      If the Sales System button does not appear, Tom was not assigned the sales_role:

      • Verify that the role policy is enabled for the Identity Server by clicking Policies > Policies, and confirm that the Identity Server is listed in the Used By column for the policy.

      • On the Policies page, confirm that the Access Gateway is listed in the Used By column for the Identity Injection policy.

      • Discover whether there was an error in the Role policy evaluation. Click Auditing > General Logging, then download the catalina.out (Linux) or the stdout.log (Windows) file for the Identity Server. Search for the name of the role policy and determine whether the role was successfully assigned.

      • Determine whether there was an error in Identity Injection policy evaluation. Click Auditing > General Logging, then download the catalina.out (Linux) or the stdout.log (Windows) file for the Access Gateway. Search for the name of the Identity Injection policy and determine whether its values were successfully injected.

      For more information about troubleshooting policies, see Section 26.7, Troubleshooting Access Manager Policies.

    4. Close all sessions of the browser.

  14. To test that the sales_role is required for the Sales System button to appear, complete the following steps:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in as the admin user. The page should have a Welcome: admin at the top of the page, but the Sales System button should not appear.

    3. To the URL, add /sales, and the Sales page appears.

      This illustrates that although the link is hidden, the Sales page is not protected.

    4. Close all sessions of the browser.

  15. Continue with Assigning an Authorization Policy to Protect a Resource.

Assigning an Authorization Policy to Protect a Resource

Use the following procedure to limit access to the Sales page based on the sales role:

  1. In the Administration Console, click Devices > Access Gateways, then click Edit > DAL > Dallistener > Protected Resources.

  2. In the Protected Resource List, click New, specify sales_page for the name, then click OK.

  3. For the Authentication Procedure, select Name/Password - Form.

  4. In the URL Path List, click /*, modify it to specify /sales/*, then click OK.

    Your protected resource should look similar to the following:

  5. Click Authorization > Manage Policies.

  6. Click New, then fill in the following fields:

    Name: Specify Allow_Sales.

    Type: Select Access Gateway: Authorization.

  7. Click OK.

    The Edit Policy page appears.

  8. In Condition Group 1, click New > Roles, then specify the following values:

    Comparison: Select String: Contains Substring.

    Mode: Select Case Insensitive.

    Value: Select Roles: sales_role.

    Return on Condition Error: Select False.

  9. In the Actions section, ensure that Permit is selected.

    Your rule should look similar to the following:

    This rule allows everyone assigned to the sales_role to have access.

  10. Click OK.

  11. In the Rule List, select New.

    This second rule is a general deny rule for everyone who has not been assigned the sales_role.

  12. Make sure the Priority field is set to 10 and that the Condition Group 1 has no conditions.

  13. In the Actions section, click Permit, select Deny, then select Deny Message.

  14. Click Message Text, then in the text box, type the deny message: Sorry, you must work in sales today.

    Your rule should look similar to the following.

    With no conditions in the condition group, this creates a general deny rule that matches everyone. The users who have been assigned the sales role match the first rule that is processed. Everyone else matches this general deny rule.

  15. Click OK to close the rule editor, then click OK to close the Rule List.

  16. In the Policy List window, click Apply Changes, then click Close.

  17. In the Authorization Policy List, select the Allow_Sales policy, then click Enable.

  18. Click OK.

  19. Click the Access Gateways link, then click Update > OK.

  20. Test the results:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in as the admin user.

    3. Add /sales to the URL.

      You should receive the following response window with the message derived from the Access Gateway you just configured:

      Now, only users with an assigned sales role can access the Sales page.

  21. Test the results with a user who has the sales role:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in as Tom.

    3. Click the Sales System button or add /sales to the URL.

      The Sales page is displayed.

    4. Close all sessions of the browser.

  22. Continue with Configuring an Identity Injection Policy for Basic Authentication.

Configuring an Identity Injection Policy for Basic Authentication

A common way to protect Web resources is to configure the Web server to require basic authentication for accessing a resource. The Web is configured to check for the user’s name and password in the HTTP authentication header. If you have Web resources with this type of configuration, you can enable single sign-on to these resources by creating a policy that injects the username and password into the HTTP authentication header.

This section explains how to set up the /sales directory to require basic authentication, and then how to create the Identity Injection policy.

Configuring the Web Server for Basic Authentication

It is difficult to create a configuration on the Apache Web server that provides consistent results by using LDAP SSL for basic authentication. Because this is a tutorial and is expected to be implemented in a testing environment, the following steps explain how to configure Apache to allow for a clear-text password over LDAP and how to configure basic authentication in this environment. The purpose of this section is not to explain how to configure Apache, but to explain how you can enable single sign-on for Web resources that require basic authentication.

Enabling LDAP Clear-Text Passwords

To turn off the SSL requirement on the internal LDAP user store:

  1. Log in to the Administration Console.

  2. Click the View Objects icon in the top menu bar.

  3. Click Search, then configure the following fields.

    Context: Accept the default [root] value and leave the Search sub-containers option enabled.

    Name: Accept the default wildcard value.

    Type: Select LDAP Group from the list.

  4. In the Results section, click the LDAP Group - <your server name> object, then select Modify Object.

  5. Select the LDAP Allow Clear Text Password attribute, then click Edit.

  6. Select the check box, then click OK.

  7. Click OK or Apply at the bottom of the page.

    If you do not click one of these buttons, your modifications are not saved.

  8. To return the Administration Console machine to its default view, click the Access Manager icon in the top menu bar.

  9. From a terminal window on the Administration Console machine, log in as root.

  10. Restart eDirectory with the following command:

    /etc/init.d/ndsd restart
Enabling Basic Authentication

You need to enable the Apache server to require basic authentication for the /sales directory. On SLES 11 SP1 and SP2, you need to enable two authentication modules and modify an Apache configuration file.

  1. At the Apache server machine, log in to YaST.

  2. Click Network Services > HTTP Server > Server Modules.

  3. Scroll down, then enable the ldap and authnz_ldap modules.

  4. Click Finish.

  5. In a text editor, open the /etc/apache2/httpd.conf file.

  6. Add the following section to the end of the file:

    <Directory "/srv/www/htdocs/sales">
   Options Indexes FollowSymLinks
   AllowOverride None
   order allow,deny
   allow from all
   AuthType Basic
   AuthName Internal
   AuthBasicAuthoritative off
   AuthBasicProvider ldap
   AuthzLDAPAuthoritative off
   AuthLDAPURL ldap://127.0.0.1/o=novell?uid??(objectclass=*)
   require valid-user
   AuthLDAPBindDN cn=admin,o=novell
   AuthLDAPBindPassword novell
</Directory>

    Replace the information in the AuthLDAPURL line with the information the IP address of your LDAP user store. Modify the query string to match your user store. This sample line assumes that the Web server and your LDAP user store are installed on the Administration Console, and 127.0.0.1 is its internal address.

    The AuthLDAPBindDN and AuthLDAPBindPassword contain the distinguished name of a user and that user’s password. This user needs sufficient rights to log in to the LDAP user store and to search for the users in the tree.

  7. Restart the Apache server with the following command:

     /etc/init.d/apache2 restart

  8. To test that the /sales directory now requires basic authentication:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in using the credentials for Tom.

      Even though Tom has logged in and been assigned the correct role, he is prompted to log in again to access the /sales directory. To enable single-sign on, you must create an Identity Injection policy that injects Tom’s credentials into the authentication header.

  9. Continue with Configuring the Web Server for Basic Authentication.

Creating an Identity Injection Policy for Basic Authentication

This section explains how to enable single sign-on by creating an Identity Injection policy that injects the user’s authentication credentials into a header. The Web server uses the credentials in the authentication header to satisfy its login requirements.

  1. In the Administration Console, click Devices > Access Gateways, then click Edit > DAL > Dallistener > Protected Resources.

  2. In the Protected Resource List, click sales_page.

  3. Click Identity Injection > Manage Policies > New.

  4. For the new policy, fill in the following fields:

    Name: Specify Basic_Auth for the name.

    Type: Select Access Gateway: Identity Injection for the type.

  5. Click OK.

  6. In the Actions section, click New, select Inject into Authentication Header, then select the following values:

    User Name: Select Credential Profile. The LDAP Credentials: LDAP User Name value is automatically selected for you. This credential is the cn attribute of the user.

    Password: Select Credential Profile. Click LDAP Credentials: LDAP User Name, then select LDAP Credentials > LDAP Password.

    Your policy should look similar to the following:

  7. Click OK to close the policy editing page, then click OK to close the Rule List page.

  8. In the Policy List page, click Apply Changes, then click Close.

  9. Select the Basic_Auth check box, click Enable, then click OK.

  10. Click OK to return to the Protected Resource List. Your list should look similar to the following:

  11. To save your configuration changes, click the Access Gateways link, then click Update > OK.

  12. To test the configuration:

    1. Open a new browser, then enter the URL of the Digital Airlines Web site you created.

      In this example, it is am3bc.provo.novell.com.

    2. Log in as Tom.

      The Digital Airlines site should appear with the Sales System button.

    3. Click the Sales System button. You should have access to the Sales System site, as shown below:

      For more information about Identity Injection policies, see Section 6.4, Identity Injection Policies.

    4. Close all sessions of the browser.