Applies To:

Show Versions Show Versions

Manual Chapter: FirePass® Controller version 6.0 Administrator Guide: 2. Managing Users and Configuring Groups
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


2

Managing Users and Configuring Groups


Introducing master groups and resource groups

The FirePass controller uses groups to authenticate users and enable access to resources, applications, and files. Using multiple groups, you can configure different authentication schemes and define different access rules to fit different sets of users. FirePass controller supports two types of groups: master groups, and resource groups.

Understanding master groups

A master group is a collection of users. It contains authentication settings, overall security configuration settings for groups of users, network access filtering policies, user experience (appearance and sequence of the user's home page), and, if you are maintaining users on the FirePass controller, user accounts. Using master groups, you can define sets of users, and to enforce different authentication requirements and security settings for different groups. Each user who connects to the FirePass controller is associated with one master group, and the master group provides the authentication that defines what the user can access.

You can also configure different user experience settings for users in different master groups. For example, you can divide users into two groups: employees who are authenticated against your Active Directory server and can access almost all resources on your intranet, and partners who are authenticated against a RADIUS server and can access only a few resources.

Understanding resource groups

A resource group is a collection of resources, access control lists, and protection criteria, which includes your company intranet servers, applications, and network shares. Using resource groups, you can define sets of resources and control access to these resources discretely.

Each resource in a resource group is represented using a special configuration construct called a favorite. A favorite has all of the information needed for the client computer to connect to an resource.You can define several kinds of favorites:

  • Intranet server favorites
    • Network Access connections
    • App Tunnel connections
  • Favorites for various applications
    • Terminal Servers connections
    • Web applications connections
    • Legacy Hosts connections
  • Network share favorites for Windows files access

When a user attempts to log on to the FirePass controller, if the user is authorized to access a resource, the corresponding favorite appears as a link on the user's browser-based home page. The user can click the link to access the resource.

Understanding how master groups and resource groups work together

A master group is associated with one or more resource groups. Once the master group authenticates the user, the user is allowed to access the resources configured for that master group. You can associate a resource group with one or more master groups or with individual users. Using resource groups, you can ensure that only the users who meet the authentication criteria and security settings requirements configured for the master group have access to the resource group. This way, you can restrict access to certain resources based on which master group a user belongs to.

Fundamentally, master groups concern authentication of users who want access, and resource groups concern the functionality and locations users can access. Figure 2.1 , following, illustrates the relationship between master groups, resource groups, and favorites categories.

Figure 2.1 Association between users, master groups, resource groups, and favorites categories

Understanding user account management options

When determining the user-management structure of master groups, you have a choice between managing users externally or internally.

  • Manage users externally on your corporate servers
    This is the recommended method. Using this method, you keep your user's information on an external server. The FirePass controller retrieves the user's group information from the external server at logon time. The FirePass controller supports the following methods for externally managing users:
  • Manage users internally on the FirePass controller
    Using this method, you add users to the internal FirePass controller database. You populate internal master groups with users and user information manually, using signup-templates, or by user-import functions. For more information, see Managing users in the FirePass controller data store .
Note

If you want users to be able to define their own personal webtop favorites or preferences, then you must manage users internally on the FirePass controller.

Understanding the best practice for managing users

F5 Networks highly recommends managing users externally using your own network group structure. First, the user-administration task is much simpler. Second, managing users externally results in increased FirePass controller performance because the controller does not have to create as many files on the system. This is especially important with sites with large numbers of users and failover configured, since in such cases synchronizing the user database can be the bottleneck of performance. Finally, although the FirePass controller has some capability for automating the synchronization of users (using the master group features signup templates and the LDAP/Active Directory synchronize options), there are no such issues with externally managed users.

Configuring authentication for users

When determining the authentication method for users in master groups, you have a choice between external and internal authentication.

  • External authentication
    Authenticates users with information retrieved from an external source. You can elect to authenticate users from an external server whether you manage the users internally on the FirePass controller, or externally on your network server.
  • Internal authentication
    Authenticates users with information from local user accounts. You cannot configure internal authentication for externally managed users.

The FirePass controller authenticates a user based on the authentication method configured for that user's master group. The FirePass controller supports the following authentication methods:

  • LDAP server query
  • RADIUS server query
  • Windows domain server query
  • Windows Active Directory server query
  • Specified client certificate Organization (O) field, Organization Unit (OU) field, or string match against Distinguished Name (DN)
  • HTTP form-based communication
  • RSA SecurID® technology
  • HTTP basic authentication

Creating internal users on the FirePass controller

If you want to use the FirePass controller to manage users, you can add user accounts to master groups by using any of the following methods.

  • Manually add users
    You can add a single user at a time. This is the least efficient, yet most controlled method. If you have more than about 100 users, manually adding users can be extremely time consuming, and result in extensive administrative requirements. See Understanding user account management options .
  • Import users from an Active Directory or Windows domain server
    In some environments, the administrator might prefer to add users to the FirePass controller, but already has an Active Directory or Windows domain server structure in place. In this case, you can use your existing user base as an import source for FirePass controller master groups.
  • Import users from an LDAP server
    Similarly, in an environment that has an LDAP server structure in place, administrators can use their existing user base as an import source for FirePass controller master groups.
  • Import users from a text file
    In cases where there is no existing server structure, the internal FirePass controller database can contain the users. The advantage of using a file is that you can add many users simultaneously, simplifying the add-user process.
  • Use signup templates to automatically add users
    For setups using locally managed users, you can use signup templates to automatically add users to the external group. See Using signup templates to add user accounts .

All of these methods create user accounts in the FirePass controller internal database. For specific procedures for each of these operations, see the online help,

Managing user information in an external data store

You can use existing user accounts that you have defined on an external server in your own network environment to authenticate FirePass controller users. External user management is the recommended user-management method. The advantage of using an external data store is that you can use the same server to authenticate FirePass controller users as you use to authenticate your local network users. Using an external data store for authentication greatly reduces the administrative effort needed to maintain user accounts on the FirePass controller, as well as on your internal network servers. In addition, using an external data store for authentication improves FirePass controller performance because user accounts are not maintained on the FirePass controller.

Tip


If you already have an authentication mechanism in place (for example, you are using the Active Directory service), you can use that mechanism to manage users of the FirePass controller. Using external user authentication reduces administration time, and is the simplest client-authentication method.

For example, if your network uses the Active Directory service, you can configure the FirePass controller to map to that structure. In this case, the FirePass controller queries the directory to get user information, and uses the results to associate each user to a master group as they log on. All FirePass controller users must be assigned, or mapped, to a master group.

To configure master groups for external users

  1. In the navigation pane, click Users, expand Groups, and click Master Groups.
    The Master Groups screen opens.
  2. Click the Create new group button.
    The Group Management screen opens.
  3. In New group name, specify a name for the group.
  4. From the Users in group list, select External.
  5. From the Authentication method list, select the authentication method you want to use.
    You cannot select Internal database or Initial signup on LDAP with Subsequence Strong Internal Password as the authentication method for master groups of external users.
  6. Click the Create button.
    The master group configuration screen opens with the General tab selected.
  7. To use dynamic group mapping in master groups, check Allow users to be assigned to this master group using dynamic master group mapping.
    If you do not enable this option, the FirePass controller gives the user access only to resource groups that are statically assigned to the master group and individually assigned to the user. To access this option, you must check the option Determine the user's master group dynamically using the master group mapping table on the Users : Groups : Dynamic Group Mapping screen.
  8. To use dynamic group mapping in resource groups, check Allow resource groups to be assigned to this master group using dynamic resource group mapping.
    If you do not check this option, the FirePass controller gives the user access only to resource groups that are statically assigned to the user. To access this option, you must check the option Determine the user's resource group dynamically using the resource group mapping table on the Users : Groups : Dynamic Group Mapping screen.
  9. Click the Resource Groups tab, and select the resource groups you want this master group to access.
    You can select one or more resource groups and click Add to make them accessible to the master group's users.
  10. Finally, click the User Experience tab to customize the look and feel of the screen for users in this master group.

Tip


You can create new master groups that use settings from existing master groups by selecting the group from the Copy settings from list when you create a new group.

Managing users in the FirePass controller data store

If you prefer, you can create users in the FirePass controller data store. The process involves first creating the master groups, and then adding users. You can add users manually, by importing them from existing external sources, or by configuring sign-up templates.

Managing users internally is not the recommended method. However, there are several circumstances in which you might want to use this method.

  • Administrators who have no existing user management and authentication source in place might want to use the FirePass controller to manage users.
  • An administrator might want a single location that lists which users have access to which resources.
    This is an easy way to determine who has individual access to various devices.
  • Some administrators might want to create an administrators-only group that exists only on the FirePass controller.
    This might be effective when the external authentication source is not available.
  • Those administrators who want users to create their own favorites or change personal preferences, must maintain users locally.

To configure master groups for local users, follow the same steps as needed for configuring a master group with external users, as described in the procedure To configure master groups for external users .

Note

The FirePass controller has a default master group called Default. You can use this master group without creating any other master groups, or you can create master groups to use instead of, or in addition to, the default group.

Setting up master groups and users

For each master group, you can separately manage users and set up authentication methods, resources, and other features. This is the recommended process for setting up groups, user accounts, authentication, and certificates on the FirePass controller.

Configuring a master group

After creating a master group, your next step is to configure the group. You use the Master Groups screen for these tasks. The Master Groups screen lists all the master groups, including the default master group. To access the screen, in the navigation pane, click Users, expand Groups, and click Master Groups.

The Master Groups screen contains several tabs that provide specific configuration options. For more information about options on each tab, see the online help for the Master Groups screen.

  • General
    Presents options that govern how to assign users and resources to the master group.
  • Authentication
    Presents options for the authentication method the group requires.
  • Resource Groups
    Presents options for assigning resource groups to master groups.
  • Signup Templates
    Presents options for automatically adding users to external groups
  • User Experience
    Presents options that govern the appearance of the user's FirePass controller webtop.

Tip


On many configuration screens, you can switch to a different master group by selecting a group from the Group list box at the upper left. This is an easy way to change the master group you are configuring, without returning to the Master Groups list screen.

Navigating the Master Groups list screen

The Master Groups list screen displays all the master groups, along with some configuration information. To access the screen, in the navigation pane, click Users, expand Groups, and click Master Groups. By default, the master groups list is sorted by group name, but you can sort by authentication method by clicking the Authentication column heading. You can click a column entry to open the tabbed Master Group configuration screen or a user or group management screen.

The columns of the Master Groups list screen provide information about each master group.

  • Group Name
    Lists the name of each group. You can click a group name to open its Master Group configuration screen containing options such as how users and resources are assigned to the group.
  • Authentication
    Lists the type of authentication the group uses. You can click the authentication method to open the Master Group configuration screen containing options such as authentication-specific settings (Authentication tab).
  • Resource Groups
    Lists the number of resource groups assigned to the master group, and whether dynamic resource assignment is enabled. You can click an entry to open the Master Group configuration screen containing options for adding or removing resource groups for the associated master group.
  • Signup Template
    Shows whether signup templates are enabled (options are: N/A, No, and Yes). The N/A entry indicates master groups of externally managed users. You can click a No or Yes entry to open the Master Group configuration screen containing options such as whether to allow automatic sign-up by template and others.
  • Note: You can specify signup template as an optional parameter only for master groups of externally managed users.

  • Max concurrent sessions
    Contains the number representing the maximum number of sessions configured for that master group. The default varies depending on the number of licenses you have for the FirePass controller. You can specify a different number on the General tab by clicking the associated link, checking Limit the number of concurrent sessions for this group, and specifying the number you want. In no case can you specify a number greater than the number of licenses you have.
  • Users
    Contains an indication of whether the group's users are maintained internally (Local) or externally (External). In any group containing locally managed users, you can click the Local link to display the users.
  • Note: You cannot view the list of users from master groups with externally managed users.

  • Routing Table
    Contains an indication of which routing table governs the associated master group. You can click the link in the column to open the Select Routing Table screen to select a different table to associate with a master group. The FirePass controller routes the traffic from users in the master group according to the routes in the associated routing table.
  • Delete
    Provides links for deleting the associated master group. You cannot delete the Default master group.

You can use the Back to Users : Groups : Master Groups page link at the top of the screen to return to the Master Groups list screen. You can also return to the Master Groups list screen by clicking Master Groups in the navigation pane.

Managing master groups

Once you have set up the master groups you want, you can manipulate them in various ways so that they meet the requirements you have,

  • Use the Master Groups list screen
    You can access the Master Groups list screen by navigating to the Users : Groups : Master Groups screen. The Master Groups list screen is where you accomplish all of the tasks described in this section.
  • Create a new master group
    You can create a new master group by clicking the Create new group button at the upper right.
  • Configure a master group
    You can configure a master group by clicking the group name, or by clicking any link in the following columns: Authentication, Resource Groups, Signup Template, Max concurrent sessions, Users, or Routing Table.
  • View the group's users
    You can list the users by clicking the Local link in the Users column. You can view group members for locally maintained users only.
  • Delete a master group
    You can delete a master group by clicking the associated Delete link. When you click Delete, the FirePass controller presents a confirmation prompt in which you can move users to a different master group or to delete the group's members. You cannot delete the Default master group.
Important

If you move internal users from externally authenticated groups to internally authenticated groups, you must manually specify each user's password and any other user information requested on the Users : User Management screen.

Populating master groups with users

You can populate master groups with users in the following ways.

  • Mapping external groups to FirePass controller groups.
    You can map your external groups to the FirePass controller's master groups.
  • Importing users from external sources.
    You can import users from the following sources:
    • LDAP directory
    • Windows Domain (NTLM)
    • Text files
    • Active Directory

You can then use synchronization options to make sure the group membership stays current.

If you want different settings for sets of users, you can either manage this through use of multiple master groups (with resource groups statically assigned to each master group), or with a single master group (and enabling dynamic group mapping to map individual resource groups to users).

Note

F5 Networks recommends authenticating users externally.

Tip


If you plan to use the same authentication and settings for all users, you can simply add all users to the existing default master group and just change the authentication type.

Using signup templates to add user accounts

If you use an external server to authenticate users, you can configure a signup template to automatically add users to the group when they log in to the FirePass controller for the first time. The FirePass controller displays a form where first-time users type their user name, password, and other information.

To set up signup templates

  1. In the navigation pane, click Users, expand Groups, and click Master Groups.
    The Master group list screen opens.
  2. Click one of the existing master group names, or click Create new group to create a new master group.
  3. Click the Signup Templates tab, and check Allow Authenticated Signup by Template.
    You can also check Bypass signup by template form and enter user information later to allow the user to log on using only the user name and password. That is, the FirePass controller does not present a signup template to users, but adds users to the group. Using this option, you can specify content for the user account at any time after creation.

Tip


You can switch to a different master group by selecting the group from the Master Group list at the upper left of any Master Group configuration screen. This is an easy way to change the master group you are configuring.

If you also use group mapping, the FirePass controller retrieves the user's group information and adds the user to the corresponding internal mapped group, and then presents the signup template as needed. If a user is a member of several groups on the external server and you have set up mapping for each group, the FirePass controller adds the user to the first group it finds that matches a group specified for signup templates.

For more information about group mapping, see Understanding dynamic group mapping .

Understanding entries in the User Management list

If you manage users locally, you can use options on the User Management screen to create and delete individual users, import groups of users, activate and deactivate user accounts, export user information to a file, configure user access to resources, and move users to another group. To access the screen, in the navigation pane, click Users, and click User Management.

You can use links at the top of the list of users to sort users by logon, name, email, and group. You can specify search-by criteria and strings to find users and limit the scope and the size of the list of results.

Understanding dynamic group mapping

Using dynamic group mapping, you can associate a user with a master group and with resource groups dynamically at user logon time. This functionality allows the FirePass controller to use your user's group-based and role-based policies that you maintain on your existing corporate policy server. If you are using dynamic group mapping, you only need to change the group-based policy or roles at your corporate server. During the logon attempt, the FirePass controller retrieves the user's current group information and dynamically associates it with a master group or resource groups.

Note

We recommend that you optimize your mapping table using the fewest number of mappings to accomplish what you want. The trade-off is performance-based. Because the FirePass controller retrieves group mapping information at logon time for every user, a large number of groups and mappings might slow logon times.

Finding procedures for dynamic group mapping

The FirePass controller dynamic group mapping feature provides support for several types of mapping operations. You can find a general example as well as specific procedures for each of the group mapping methods.

For more information, see one or more of the following sections.

For information about one of the specific group mapping methods, see one or more of the following sections.

     

Understanding dynamic master group mapping

During dynamic master group mapping, the FirePass controller queries the external group mapping servers, and matches the value of the external groups with the entries in the master group mapping table. If a user matches more than one entry in the master group mapping table, the FirePass controller uses the first match it encounters. If the mapping succeeds, then the FirePass controller authenticates the user by the authentication methods configured for that master group.

Understanding how a user is authenticated

The FirePass controller goes through a series of activities when it uses master group mapping to determine to which master group a user belongs. Then the FirePass controller authenticates the user by whatever authentication method is configured for that master group. The FirePass controller steps through the master group mapping process in the following order.

  • First, the FirePass controller queries any external servers that are configured with mapping methods and attempts to match the user to a master group based on entries in the master mapping table. For example, if LDAP is the configured mapping method, the FirePass controller sends a query to the LDAP server to gather the information requested.
  • Next, the FirePass controller compares the results of the query with each entry you have specified in the master group mapping table, looking for a match. At this point, if the system has not identified a master group, the FirePass controller searches its internal database to determine the user's master group information.
  • When the FirePass controller finds a match, it associates the user with the master group and prepares for authentication. If a single user matches more than one master group, as determined by entries in the master mapping table, the FirePass controller uses the first match it encounters. You can set the order in which the FirePass controller should perform group mapping operations by specifying the mapping's priority number in the master group mapping table.
  • If the system has not yet found a match, it can search through the fallback master groups specified.

Figure 2.2 illustrates the dynamic master group mapping process. You can find sample mapping procedures in Specifying a group mapping method .

Figure 2.2 The FirePass controller master group mapping process

The Dynamic Group Mapping screen contains text that describes the process illustrated in Figure 2.2 . Dynamic Group Mapping is available under Users : Groups : Dynamic Group Mapping.

Understanding dynamic resource group mapping

During dynamic resource group mapping, the FirePass controller queries the external group mapping servers and matches the value of the external groups against the entries in the resource group mapping table. The user gets an association for each resource mapping table entry whose resource group configuration matches. When the FirePass controller finds a match, it provides the user access to the resource groups associated with the mapped entries. The FirePass controller then permits the user access to all resources in all resource groups returned by any of the configured methods, and presents the resources as favorites on the user's webtop. If dynamic resource group mapping fails, the following actions occur:

  • If the user belongs to a group whose users are maintained externally, the FirePass controller does not provide the user access to the resource.
  • If the user belongs to a group whose users are maintained in a FirePass controller resource group, the FirePass controller provides the user access to only those resource groups that are statically assigned to the master group and individually assigned to the user.

Understanding how resource groups are assigned

The FirePass controller makes resources available in the following ways:

  • From dynamically assigned resource groups
  • From resource groups that are statically assigned to the user's master group
  • From resource groups that are statically assigned to a user

When you enable dynamic resource group mapping, and the user logs on to the FirePass controller, the FirePass controller completes the following sequence of events to map a user to available resources:

  • First, the FirePass controller attempts to use dynamic resource group mapping to determine which resource groups are assigned to the user. If the system finds assigned resource groups, the FirePass controller presents to the user the resources from those groups.
  • Next, the FirePass controller attempts to determine which resource groups are statically assigned to a user's master group. If the system finds resource groups, the FirePass controller allows the user access to the resources associated with that master group.
  • The FirePass controller then attempts to determine which static resource groups are statically assigned to the user. If the system finds resource groups, the FirePass controller permits the user access to those statically assigned resources as well.
  • Finally, the FirePass controller presents to the user all resource groups received from this sequence.

Figure 2.2 illustrates the dynamic master group mapping process. You can find sample mapping procedures in Specifying a group mapping method .

Figure 2.3 The FirePass controller resource group mapping process

Configuring dynamic master group mapping: an example

You define two groups on your corporate policy server: employees and consultants. You want to authenticate the users in these two groups using different authentication servers: employees through your own authentication server, and consultants through a third-party authentication server.

On the FirePass controller, you have two master groups: Employees and Consultants. You specify an authentication scheme for the Employees master group that matches your internal network servers. You configure resource groups with resources that are appropriate for access only by company employees, and map those resource groups to the Employees master group.

Similarly, for the Consultants master group, you specify a third-party authentication scheme, and you configure resource groups with access only to resources that corporate consultants should access, that is, resources that are isolated from the corporate network or prevent access to confidential information. You configure map those resource groups to the Consultants master group.

Next, you configure mapping entries that associate your external group Employees with the FirePass controller master group employees, and Consultants with consultants.

Here is what happens for two users: Maria, an employee, and George, a consultant.

Whenever Maria tries to log on to the FirePass controller, the FirePass controller retrieves the group information from your corporate policy server, maps Maria to the FirePass controller master group Employee, and authenticates Maria against your authentication server. The FirePass controller then allows Maria to access all of the resource groups associated with the master group Employee.

When George tries to log on to the FirePass controller, the FirePass controller retrieves group information from a third-party source, maps George to the FirePass controller master group Consultant, and limits George to only those resource groups that are associated with the master group Consultant.

If, in the future, George becomes an employee, you do not have to make any changes on the FirePass controller. You just have to update group information for George on your corporate policy server, changing it from consultant to employee.

When George next tries to log on to the FirePass controller, the FirePass retrieves the group information from your corporate policy server instead of the third-party source, maps George to the FirePass controller master group Employee, and authenticates George against your authentication server. The FirePass controller then allows George to access all of the resource groups that are associated with the master group Employee.

This example shows that dynamic master group mapping allows you to dynamically control the authentication, security, and resource assignment for a user.

Configuring dynamic resource group mapping: an example

Dynamic resource mapping allows you to assign resources dynamically to a user, based on roles. At logon time, the FirePass controller retrieves role-based policies (groups) information from your corporate policy server. The FirePass controller then assigns resources to the user dynamically, based on the user's groups.

In this scenario, you have two kinds of users in your marketing division: staff and managers. Staff can access most of your marketing resources, but the confidential information on some servers is only accessible to managers.

To use dynamic resource group mapping, you define two resource groups on the FirePass controller: Staff and Managers. In Staff, you create favorites that represent the resources appropriate for those users to access. In Managers, you create favorites that represent all resources.

Next, you configure the dynamic resource group mapping table to map your staff group to the FirePass controller Staff group, and your managers group to the FirePass controller Managers group.

Here is what happens for Joe, a new staff member at your company.

When Joe starts at your company, you create user account information for him in the staff group. When Joe tries to log on to the FirePass controller, the FirePass controller retrieves the group value staff from your corporate policy server. Based on the configured dynamic resource group mapping entries, the FirePass controller maps the value staff to the FirePass controller Staff resource group.

Now, Joe can access all of the resources configured for the Staff resource group.

In this scenario, 12 months later, Joe is doing such good work that he is promoted to a managerial position. To provide Joe access to the resources that all managers see, the only thing you need to do is to change Joe's group from Staff to Managers on your corporate policy server.

The next time Joe tries to log on, the FirePass controller retrieves the group value managers from your corporate policy server. Based on the configured dynamic resource group mapping entries, the FirePass controller maps the value managers to the FirePass controller Managers resource group, and gives Joe access to all of the resources available to the Managers resource group.

This example shows that dynamic resource group mapping allows you to keep your group-based or role-based policies on your corporate policy server. You can then configure the FirePass controller to apply these policies dynamically when the user logs on. If a policy changes, you do not have to reconfigure the FirePass controller, you can just move the user to a different group on your corporate server. Because you have defined the mapping entries, the FirePass controller automatically provides access correctly, based on the user's changing role.

Using dynamic group mapping

Dynamic group mapping is accomplished by configuring associations in a mapping table. The group mapping table serves as a framework to ensure that the FirePass controller correctly authenticates external users or local users authenticated externally, and that those users get access to the appropriate resources.

The FirePass controller maintains a table of associations between external groups and users and a table of internal master groups and resource groups. The master mapping table controls the association between users and master groups, and the resource mapping table controls the association between users and resource groups.

You can configure dynamic group mapping by completing these tasks.

You can use signup templates to have the group mapping functionality automatically add new users to master groups at logon time. For more information, see Using signup templates to add user accounts .

Enabling dynamic group mapping

Dynamic master group mapping is automatically selected for master groups with external users. By default, group mapping is not selected when you create master groups with local users. You can specify group mapping when you create a group, or at any time after the group has been created. Until you enable dynamic group mapping, you can add users manually, or by importing them from an external source.

Users that you maintain locally on the FirePass controller can have both dynamically and statically assigned resource groups.

For dynamic group mapping to succeed, you must specifically enable it for each master or resource group.

To enable dynamic mapping

  1. In the navigation pane, click Users, expand Groups, and click Master Groups.
    The Master Groups screen opens.
  2. Click the group name of the group you want to use in group mapping.
    The screen changes, and you see the General screen for this master group.
  3. Select the option appropriate to the type of group you are mapping.
    • For master groups, select the option Allow users to be assigned to this master group using dynamic master group mapping.
      Selecting this option uses settings on the master group mapping table to map users to master groups.
    • For resource groups, select the option Allow resource groups to be assigned to this master group using dynamic resource group mapping.
      Selecting this option uses settings on the resource group mapping table to map users to resource groups.
  4. Click the Update button.

Specifying fallback master groups

Since most users belong to several groups in a network structure, using fallback groups can help direct the FirePass controller to identify a user as part of a specific master group. In this case, if the FirePass controller cannot identify the user as part of the first master group in the mapping, it tries the master groups listed in the fallback master group list, in the order the group appears in the list.

By default, the FirePass controller adds newly created master groups to the list of fallback master groups. You can add and remove master groups, and you can rearrange the order of master groups in the list. Specifying fallback master groups is part of configuring for dynamic group mapping.

To add a fallback master group

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Dynamic Group Mapping screen opens.
  2. Check the box following Step 3, Determine the user's master group by attempting to authenticate the user in each of the fallback master groups.
  3. In the Available master groups list, select any master groups you want to affect.
    You can use the Shift and Ctrl keys to add items to your selection.
  4. To add a master group as a fallback master group, click Add.
    The selected group or groups appear in the Fallback master groups list.
  5. In the Fallback master groups list, select any master groups you want to affect.
    You can use the Shift and Ctrl keys to add items to your selection.
  6. Perform an action. Possible actions include:
    • To prevent the FirePass controller from using the master group selected as fallback master group, click Remove.
    • To position the selected master group so that the FirePass controller uses it earlier in the dynamic group mapping process, click Move Up.
    • To position the selected master group so that the FirePass controller uses it later in the dynamic group mapping process, click Move Down.

Completing group mapping configuration

Once you enable dynamic group mapping, you can proceed to select the mapping method you plan to use (see Specifying a group mapping method ), configure the request for user information (see To configure dynamic group mapping , following), and add entries to the master group mapping table and the resource group mapping table (see the section relating to the type of mapping you are configuring). When you complete these tasks, the FirePass controller can perform dynamic group mapping.

To configure dynamic group mapping

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select the method you want, and click Add mapping method.
    The new method is added to the list. If the method is already added, it is not present in the list. For more information, see Specifying a group mapping method .
  7. Click the Request configuration tab.
    The Request configuration screen opens.
  8. From the Select method to configure request list, select the method you plan to use for group mapping, and then click Switch.
    The screen refreshes to reveal options that are relevant to the method you selected.
  9. Configure the settings that reflect your external group and network structure, and then click the Update button.
    You must configure settings so that the FirePass controller can send the request for user information to the appropriate server on your network. For more information, see Completing group mapping configuration .
  10. Click the Master mapping table tab.
    The Master mapping table screen opens.
  11. From the Mapping Method list, select the type of mapping table entry you want to create, and click Add.
    The master mapping table screen opens for the mapping method you added.
  12. Specify the mappings you want, and then click Add.
    The Master mapping table screen opens, showing the mapping you added.
    This is where you add master mapping entries. For more information, see the section that describes configuring mappings based on the method you are using. For example, if you are mapping using the LDAP (user object) method, see To add the LDAP user object mapping method .
  13. Click the Resource mapping table tab.
    The Resource mapping table screen opens.
  14. From Mapping Method, select the type of mapping table you want to create, and then click Add.
    The Resource mapping table screen opens for the mapping method you added.
  15. Specify the mappings you want, and then click Add.
    The Resource mapping table screen opens, showing the mapping you added.
    This is where you add resource mapping entries. For more information, see the section that describes mappings based on the method you are using.

Specifying a group mapping method

You can define how the FirePass controller gets authentication information from the associated server by specifying fields and choosing settings when configuring the mapping method.

The options and settings you configure depend on your external network setup. The FirePass controller supports the following types of group mapping configurations:

When you add a Windows Domain or Active Directory mapping, or any of three LDAP-based mapping, the system provides a link for configuring the mapping method. You can read more about configuring mapping methods in the procedure for each mapping type.

Note

A group's authentication method and group mapping type do not have to match, although they can and probably do.

Mapping based on Active Directory or Windows domain controllers

If your external network structure uses Active Directory or Windows domain groups, you can use the FirePass controller group mapping function to take advantage of that structure. The system provides a method for mapping groups within an Active Directory to FirePass controller master groups. Use the Active Directory method with Windows 2000 and later domain controllers. Use the Windows domain controllers method against pre-Windows 2000 servers, or when you have a mix of Windows platforms in your environment.

Within an Active Directory or Windows domain, there are usually a number of groups defined, with users belonging to one or more of these groups. You can map existing master and resource groups directly to these Active Directory or Windows domain groups. When a user attempts to log on to the FirePass controller, the domain queries your external Active Directory or Windows domain groups to determine what groups contain the user. The FirePass controller looks for matches in its dynamic group mapping framework. When it finds a match, the FirePass controller authenticates the user and allows access to the appropriate resources.

When mapping a user to one or more resource groups, the FirePass controller attempts to match all domain groups against the configured resource group mapping, and the user is assigned one or more resource groups based on any matches.

Configuring Active Directory-based mapping

If you use Active Directory for your user database, you can configure the FirePass controller to map users based on Active Directory groups.

Configuring Active Directory-based mapping involves three procedures: adding the Active Directory mapping method, mapping the Active Directory to FirePass controller master groups in the master group mapping table, and mapping the Active Directory to FirePass controller resource groups in the resource group mapping table.

To add the Active Directory mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select Active Directory, and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Active Directory item.
  7. Click the Configure link to the right of the entry in the Mapping methods table.
    The Mapping methods configuration screen opens.
  8. In Domain name, type the domain name for the Active Directory to use for mapping users.
    You must use the Fully Qualified Domain Name (FQDN) in Domain name. Domain name is a required parameter.
  9. In Kerberos server name, type the Kerberos server name or IP address.
    Kerberos server name is an optional parameter.
  10. In WINS server IP address, type the WINS server IP address.
    WINS server IP address is an optional parameter.
  11. In Domain admin name and Domain admin password, type a user name and password that has Active Directory administrative permissions.
    Domain admin name and Domain admin password are required parameters.
  12. To use a second Active Directory server, check Use a secondary AD server.
    The screen changes to reveal additional options.
  13. In Kerberos server name, type the Kerberos server name or IP address.
  14. In WINS server IP address, type the WINS server IP address.
  15. To use a third Active Directory server, check Use a tertiary AD server.
    The screen changes to reveal additional options.
  16. In Kerberos server name, type the Kerberos server name or IP address.
  17. In WINS server IP address, type the WINS server IP address.
  18. To limit Active Directory group mapping to the user's primary domain, check Only use Active Directory primary group for mapping.
  19. To configure options for synchronizing the FirePass controller database with the external Active Directory, check Synchronize FirePass user database with Active Directory.
    The screen changes to reveal additional options.
    • From the Action list, select an option:
      Deactivate FirePass account if user is not in Active Directory or
      Delete FirePass account if user is not in Active Directory
    • Check Notify by e-mail to have the system inform the user of the deactivation or deletion operation.
    • In Check interval, specify the number of minutes to wait between synchronization operations.
  20. To update user information in internal FirePass controller database records, check Update user information from Active Directory.
    • Check Map first name to update the first name.
    • Check Map last name to update the last name.
    • Check Map e-mail to update the e-mail address.
    • Check Allow user to edit personal information obtained from Active Directory to allow the user edit access to Active Directory information.
  21. Click Update to save your settings.

Continue with the following procedure.

To configure the Active Directory mapping table

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping Methods list, select Active Directory, and click Add.
    • Note: If there is no Active Directory item, click the Group mapping methods tab, and add the Active Directory mapping method first.
  3. In the box in the Active Directory Group column, specify the Active Directory group you want to map.
  4. From the list in the FirePass group column, select the group you want to map to.
  5. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the Active Directory mapping method and To configure the Active Directory mapping table , preceding.

Note

Instead of specifying each Active Directory group individually, you can have the system retrieve the external groups, but this method is recommended if you have fewer than several hundred groups.
Configuring Windows domain-based mapping

You can use Windows domain-based authentication in two ways.

  • Native NTLM
    If you provide domain administrative credentials when configuring Windows domain authentication, then the FirePass controller performs authentication using native NTLM. You can use this method to add a machine account for itself, join the domain, and create a one-way, Windows NT 4.0-style, trust relationship with the Primary Domain Controller (PDC).
  • Basic
    If you do not provide domain administrative credentials when configuring Windows domain authentication, then the FirePass controller authentication mechanism connects to the PDC's netlogon share using the user's credentials, to determine whether the user has a valid account within the domain.

If you use Windows domain for your user database, you can configure the FirePass controller to map users based on Windows domain groups.

Configuring Windows domain-based mapping involves three procedures: adding the Windows domain mapping method, mapping the Windows domain groups to FirePass controller master groups in the master group mapping table, and mapping the Windows domain groups to FirePass controller resource groups in the resource group mapping table.

To add the Windows domain mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select Windows Domain, and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Windows Domain item.
  7. Click the Configure link to the right of the entry in the Mapping methods table.
    The Mapping methods configuration screen opens.
  8. In Domain name, type the domain name for the Windows domain to use for mapping users.
    You must use the Fully Qualified Domain Name (FQDN) in Domain name. Domain name is a required parameter.
  9. In PDC server name, type the name of the Primary Domain Controller (PDC).
    PDC server name is an optional parameter.
  10. In WINS server IP address, type the WINS server IP address.
    WINS server IP address is an optional parameter.
  11. To have the FirePass controller join the Windows domain, check Join Windows domain.
    The screen changes to reveal additional options.
  12. In Domain admin name and Domain admin password, type a user name and password that has Windows domain administrative permissions.
    Domain admin name and Domain admin password are required parameters.
  13. Click Update to save your settings.

Continue with the following procedure.

To configure the Windows domain mapping table

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping Methods list, select Windows Domain, and click Add.
    • Note: If there is no Windows Domain item, click the Group mapping methods tab, and add the Windows Domain mapping method first.
  3. In the box in the Windows Domain Group column, specify the Windows domain group you want to map.
  4. From the list in the FirePass group column, select the group you want to map to.
  5. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the Windows domain mapping method and To configure the Windows domain mapping table , preceding.

Note

Instead of specifying each Windows domain group individually, you can have the system retrieve the external groups, but this method is recommended if you have fewer than several hundred groups.

Mapping based on LDAP information

If your external network structure uses LDAP to store user information, you can use the FirePass controller group mapping function to take advantage of that structure. LDAP-based group mapping automatically synchronizes changes on the LDAP server with group functionality on the FirePass controller. For example, if you move a user to a different group on the LDAP server, the FirePass controller automatically provides the user with access to the new set of resources the next time the user logs on.

If you use a signup template for new FirePass controller users, group mapping can also have the FirePass controller query the external server for each user's group membership, and automatically associate the user to the mapped master and resource groups on the FirePass controller.

You can use LDAP in several ways.

You can use one, two, or all three modes simultaneously.

Important

In the request configuration, you can specify an LDAP port and configure the FirePass controller to use SSL for the query operation. If you use LDAP authentication over SSL, be sure that the host name you specify exactly matches the host name on your LDAP server's certificate.

When you specify a query template for the request to use when searching for a user, it must be a valid LDAP query expression.

Mapping based on LDAP information from a user object

If you have LDAP configurations that use a specific attribute as the unique identifier for the user, you can configure group mapping based on that attribute. For example, if your LDAP server uses an LDAP attribute called userPrincipalName, you could specify that when you configure the request.

Configuring LDAP user object-based mapping involves three procedures: adding the LDAP user object mapping method, mapping the LDAP user object to a FirePass controller master group in the master group mapping table, and mapping the LDAP user object to a FirePass controller resource group in the resource group mapping table.

To add the LDAP user object mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select LDAP (user object), and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no LDAP (user object) item.
  7. Click the Configure link to the right of the entry in the Mapping methods table.
    The Mapping methods configuration screen opens.
  8. In the LDAP server box, specify the user distinguished name (DN). For example
    CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
  9. In the Query LDAP user object area, select the method you want the FirePass controller to use to query the external LDAP server.
    • If you select the Get user DN using template option, click Update, and type the user's entry in Template. For example,
      cn=%logon%,dc=eng,dc=net,dc=com
    • If you select the Get user DN using query option, click Update, and specify the base DN in Search Base DN. For example: CN=Users,dc=eng,dc=net,dc=com
      And specify the search string in Query template. For example:
      &(sAMAccountName=%logon%)
    • You can use %logon% in the template to have the FirePass controller insert the user's logon name into the query. For example, if you specify as the template &(objectclass=person)(cn=%logon%), and the user's name is "george", at logon time the FirePass controller sends the actual query: &(objectclass=person)(cn=george).

  10. In the Fetch group information from LDAP user object area, define the attributes to use to map the group. For example, memberOf.
    You can use multiple attributes, each one on a separate line.
  11. Click Update to save your settings.

Continue with the following procedure.

To configure the LDAP user object mapping table

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping Methods list, select LDAP (user object), and click Add.
    • Note: If there is no LDAP (user object) item, click the Group mapping methods tab, and add the LDAP mapping method first.
  3. From Attribute, select the attribute you want to map to.
  4. In the Attribute value column, specify the string for the FirePass controller to use for mapping.
    • Note: You can instead map the LDAP user attribute directly to a FirePass controller master group name by checking the Map verbatim box. In this case, the group names must match exactly. In this case, the FirePass controller removes the fields in the Attribute value and FirePass Group columns.
  5. From the list in the FirePass group column, select the group you want to map to the users returned by the filter expression.
  6. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the LDAP user object mapping method and To configure the LDAP user object mapping table , preceding.

Mapping based on LDAP information from a group object

If you have an LDAP configuration that uses a group object to organize users, you can configure group mapping based on that structure. For example, you can use the user interface to create new groups, or you can use existing groups. Your configuration mechanism must have a group object in your LDAP schema to use for mapping groups. The group should have at least two multi-valued attributes for its members.

Configuring LDAP group object-based mapping involves three procedures: adding the LDAP group object mapping method, mapping the LDAP group object to a FirePass controller master group in the master group mapping table, and mapping the LDAP group object to a FirePass controller resource group in the resource group mapping table.

To add the LDAP group object mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select LDAP (group object), and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no LDAP (group object) item.
  7. Click the Configure link to the right of the entry in the Mapping methods table.
    The Mapping methods configuration screen opens.
  8. In the LDAP server box, specify the user DN. For example,
    CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
  9. In the Fetch group information from LDAP group object area, specify the attributes in the appropriate box.
    • The Static members attribute relates to objects with multi-valued membership attributes such as the attribute that contains the list of the user's DNs, for example, groupofNames, groupofUniqueNames.
    • The Dynamic members attribute determines membership by executing an LDAP URL, for example, groupOfURLs, or an LDAP query that specifies criteria for a group's membership.
    • Note: There is no group object, as such. That is, the LDAP URL exists only in the application that is using it.
  10. Click Update to save your settings.

Continue with the following procedure.

To configure the LDAP group object Master group mapping table

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping Methods list, select LDAP (group object), and click Add.
    • Note: If there is no LDAP (group object) item, click the Group mapping methods tab, and add the LDAP mapping method first.
  3. In the LDAP group object DN column, type the group object DN you want to map from the LDAP group to the FirePass group.
  4. From FirePass group, select the group you want to map to the specified LDAP group.
  5. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the LDAP group object mapping method and To configure the LDAP group object Master group mapping table , preceding.

Mapping based on an LDAP filter

If you have discrete groups of users that you have configured with an attribute other than the user attributes and you do not use a group object implementation of LDAP, the LDAP filter option is the option to configure. You can configure the mapping of LDAP groups based on results returned by sending a query containing an LDAP filter.

Within a set of defined Windows domain groups, there are usually logical divisions. For example, you may have a group whose users consist of regular employees and consultants. The type and breadth of access allowed for each division within the group usually varies. For example, you might give regular employees access to internal human resources services, and prevent consultants from having the same access. If your LDAP structure matches this organization, you can accomplish this access division using filters. In this case, you define the filter to map to a specific master group.

Configuring LDAP filter-based mapping involves three procedures: adding the LDAP filter mapping method, mapping the LDAP filter to a FirePass controller master group in the master group mapping table, and mapping the LDAP filter to a FirePass controller resource group in the resource group mapping table.

To add the LDAP filter mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select LDAP (filter), and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no LDAP (filter) item.
  7. Click the Configure link to the right of the entry in the Mapping methods table.
    The Mapping methods configuration screen opens.
  8. In the LDAP server box, specify the fully qualified domain name (FQDN) of the LDAP server.
  9. In the LDAP port box, specify the port you want to use.
    The default is 389 for an LDAP connection, and 636 for a secure LDAP connection.
  10. In the User DN box, specify the user DN. For example
    CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
  11. Click Update to save your settings.

Continue with the following procedure.

To configure the LDAP filter Master group mapping table

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping Methods list, select LDAP (filter), and click Add.
    • Note: If there is no LDAP (filter) item, click the Group mapping methods tab, and add the LDAP mapping method first.
  3. In the box in the LDAP filter column, specify the filter you want to use to define FirePass group membership.
  4. You can use %logon% in the filter expression to have the FirePass controller insert the user's logon name into the query. For example, if you specify as the template &(objectclass=person)(cn=%logon%), and the user's name is "george", at logon time the FirePass controller sends the actual query: &(objectclass=person)(cn=george).

  5. From the list in the FirePass group column, select the group you want mapped to the users returned by the filter expression.
  6. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the LDAP filter mapping method and To configure the LDAP filter Master group mapping table , preceding.

Most Active Directory objects use the cn property as their naming attribute. Some objects, however, use a naming attribute other than cn. For example, a domain controller uses the domainDNS property for the naming attribute, and an organizational unit uses the organizationalUnit property for the naming attribute. To avoid having to use a different naming attribute for different object types, you should use the name property, which contains the relative distinguished name of the object, to search for objects by name.

For example, &(&(objectClass=user)(objectCategory=person))(|(name=Sales*)(name=Marketing*))

Mapping based on client certificates

For users with client certificates, you can use the Organization (O) or Organizational Unit (OU) attribute from the certificate's issuer or subject Distinguished Name (DN) to map the user to a FirePass master group or to one or more resource groups.

It is also possible to use a substring of the issuer or subject DN to map the user to a FirePass controller group. For example, a typical subject DN might appear as follows:

/C=US/ST=CA/L=MyCity/O=MyCompany/OU=MyDept/CN=user/emailAddress=user@company.xyz

For this case, you can specify L=MyCity to map MyCity to a particular FirePass controller master or resource group.

Configuring client certificate-based mapping involves three procedures: adding the Client Certificate mapping method, mapping a client certificate attribute to a FirePass controller master group in the master group mapping table, and mapping the client certificate attribute to a FirePass controller resource group in the resource group mapping table.

To add the client certificate mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select Client Certificate, and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Client Certificate item.

Continue with the following procedure.

To configure the client certificate Master group mapping table

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping methods list, select Client Certificate, and then click Add.
    The associated Master group mapping table opens.
    • Note: If there is no Client Certificate item, click the Group mapping methods tab, and add the client certificate mapping method first.
  3. From the list in the Attribute column, select the certificate attribute you want to use for mapping.
  4. In the box in the Value column, specify the string for the FirePass controller to map to.
    • Note: You can also map the user's client certificate attribute directly to a FirePass controller master group by checking the box in the Map verbatim column. In this case, the FirePass controller removes the Value and FirePass Group columns. For example, if the box in Map verbatim is checked, and you select Subject Organizational Unit (OU), then the FirePass controller maps all client certificates configured as OU=MyDept to the master group named MyDept.
  5. From the list in the FirePass group column, select the group you want to map to the associated users.
  6. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the client certificate mapping method and To configure the client certificate Master group mapping table , preceding.

Mapping based on RADIUS groups

You can map external RADIUS groups directly to existing master and resource groups. Then, when a user logs on to the FirePass controller, the FirePass controller queries the external RADIUS server to retrieve the list of groups to which the user belongs. The FirePass controller attempts to match the retrieved external RADIUS groups against the configured mapping.

The FirePass controller retrieves the external RADIUS group information from an attribute returned from the RADIUS user profile. This attribute contains the external RADIUS group list. The FirePass controller parses the return value to retrieve the external group information in various formats.

For step-by-step procedures on configuring RADIUS group mapping, see the online help for the Users : Groups : Dynamic Group Mapping screen.

Mapping based on landing URI

A URI is a Uniform Resource Identifier. In the FirePass controller context, URI means the fully-qualified domain name, followed by /<uri-specific_path>. For URI-based customization, URIs are defined inside of the FirePass controller. You can create customized FirePass controller user interfaces for different URIs. By configuring URI-based customization, you can present a different look and feel depending on the URI the user specifies when logging on. This is similar to mapping based on virtual hosts.

Important

You cannot simultaneously use virtual-host based dynamic group mapping and landing URI-based dynamic group mapping.

From a user standpoint, URI-based customization is maintained by a cookie. Once a user establishes a session using a URI that gets customized, then all subsequent FirePass controller sessions started in that browser use the same customization, even if the user specifies the domain name alone (for example, www.siterequest.com), or the domain name qualified by a redirect page (for example, www.siterequest.com/my.logon.php3). To end URI customization, the user must start a new browser session.

If you configure URI-based customization, you can use it as a basis for the group mapping. In URI-based mapping, you map a customized URI to a specific master group. Using URI-based mapping, you can map users to different master groups or assign them to different resource groups based on the landing URI used by the users to log on to the FirePass controller.

For example, a FirePass controller might have two landing URI's configured: outlook and CRM. To support URI-based master group mapping, the administrator creates two mappings in the Master group mapping table. To support URI-based resource group mapping, the administrator creates two mappings in the Resource group mapping table. Users who log on to www.sitrerequest.com/outlook receive access to one set of master and resource groups, which includes access to outlook. Users who log on to www.siterequest.com/crm receive another set of master and resource groups, which includes access to CRM.

Configuring landing URI-based mapping involves four procedures: adding the Landing URI mapping method, specifying the landing URI, mapping the landing URI to a FirePass controller master group, and mapping the landing URI to a FirePass controller resource group in the resource group mapping table.

To add the Landing URI mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select Landing URI, and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Landing URI item.

Continue with the following procedure.

To specify the Landing URI

Complete the previous procedure before you start this one.

  1. On the Group mapping methods screen, click the link Click to configure landing URIs.
    The Device Management : Customization screen opens with the URI-based Customization tab active.
  2. In the Create Landing URI box, type the URI you want to map.
    The URI you specify must be alphanumeric and cannot contain spaces. Type only the portion of the URI that follows the domain name in the URL. For example, to create a URI consisting of www.siterequest.com/partners, type partners in the box.
  3. Click Apply.
    The Configuring URIs screen opens.
  4. Select and specify the settings you want, and click the Update button corresponding to each configuration you make.
  5. When you have finished, click the link Back to Users : Groups : Dynamic Group Mapping page.
    The Dynamic Group Mapping screen opens with the Group mapping methods tab active.

Continue with the following procedure.

To map the URI to a FirePass controller group

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping Methods list, select Landing URI, and click Add.
    • Note: If there is no Landing URI item, click the Group mapping methods tab, and add the Landing URI mapping method first.
  3. From each list in the FirePass group column, select a group for mapping to the URI.
  4. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the Landing URI mapping method , To specify the Landing URI , preceding, and To map the URI to a FirePass controller group , preceding.

Mapping based on virtual hosts

In the FirePass controller context, a virtual host means the domain name or IP address that users specify when logging on to a web service you create on a virtual IP. When you want to organize users based on the virtual host they are requesting, you can use virtual host information to dynamically map users to a master group or resource group.

You can create customized user interfaces for different virtual servers. By configuring virtual host-based customization, you can present a different look and feel depending on the virtual host address the user specifies when logging on. This is similar to URI-based mapping.

Important

You cannot simultaneously use virtual-host based dynamic group mapping and landing URI-based dynamic group mapping.

A virtual server can be one of the following things.

  • An additional IP address that resolves to the FirePass controller, plus a user web service within the FirePass controller, configured on that IP address
  • A distinct host name, configured on your DNS to resolve to the same IP address

For virtual servers, you can define one customization for a single IP address. URI-based customization takes precedence over virtual host customization. Virtual host customization takes precedence over the default, global customization.

Configuring virtual host-based mapping involves three procedures: adding the Virtual Host mapping method, mapping the virtual host to a FirePass controller master group in the master group mapping table, and mapping the URI to a FirePass controller resource group in the resource group mapping table.

To add the Virtual Host mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select Virtual Host, and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Virtual Host item.

Continue with the following procedure.

To map the virtual host to a FirePass controller group

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping Methods list, select Virtual Host, and click Add.
    • Note: If there is no Virtual Host item, click the Group mapping methods tab, and add the Virtual Host mapping method first.
  3. From each list in the FirePass group column, select a group for mapping to the virtual host.
  4. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the Virtual Host mapping method and To map the virtual host to a FirePass controller group , preceding.

Mapping based on session variables

Creating dynamic group mapping with session variables is particularly useful to mapping based on user information. You can use the following types of the session variables for dynamic group mapping:

  • System-provided and custom session variables defined during a pre-logon sequence.
  • Session variables defined by attributes received from external Active Directory and LDAP servers during dynamic group mapping. The system converts these attributes to session variables.

Because some session variables are defined after the FirePass controller performs group mapping, you cannot use them. These include the following types of session variables:

  • Session variables defined by post-logon operations
  • Session variables defined by attributes received from external Active Directory and LDAP servers during the user-authentication process

Configuring session variable-based mapping involves three procedures: adding the Session Variable mapping method, mapping the session variable to a FirePass controller group in the master group mapping table, and mapping the session variable to a FirePass controller resource group in the resource group mapping table.

To add the Session Variable mapping method

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Group mapping sequence screen opens.
  2. Check or clear the options you want to create the mapping sequence.
  3. If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
  4. If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
  5. Click the Group mapping methods tab.
    The Group mapping methods screen opens.
  6. From the mapping methods list, select Session Variable, and click Add mapping method.
    The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Session Variable item.

Continue with the following procedure.

To map the session variable to a FirePass controller group

Complete the previous procedure before you start this one.

  1. Click the Master group mapping table tab.
    The Master group mapping table screen opens.
  2. From the Mapping Methods list, select Session Variable, and click Add.
    • Note: If there is no Session Variable item, click the Group mapping methods tab, and add the Session Variable mapping method first.
  3. In the Session variable column, define the session variable you want to map to, making sure to enclose the session variable within percent ( % ) characters.
  4. In the Value column, specify the string for the FirePass controller to use for mapping.
    • Note: You can instead map the Session Variable value directly to a FirePass controller master group name by checking the Map verbatim box. In this case, the FirePass controller removes the fields in the Value and FirePass Group columns.
  5. From each list in the FirePass group column, select a group for mapping to the session variable.
  6. Click Add to save your mappings.

Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping: To add the Session Variable mapping method and To map the session variable to a FirePass controller group , preceding.

Using global settings

You can specify global settings for certain user options. You can find global options on the Users : Global Settings screen.

  • Allow to login with e-mail address as substitute of user name
    Indicates that the system accepts an email address instead of a user name. This is useful when your existing infrastructure relies on email addresses as the primary user identifier.
  • Treat user's logon name as case-sensitive
    Indicates that the FirePass controller converts the user name to lowercase letters before sending it to the authentication server. When this option is disabled, the FirePass controller retains the case of the user name when sending it to the authentication server.
  • Display extra input field at logon for user defined session variable
    On the logon page, presents the user with a field in which to type text. This field is then converted to a session variable named %session.userdef.logon_extra_field%. You can specify a label to help the user know what to type in the field.
  • For example, you can map users to different master groups by specifying the label Type your master group name in the following field, and then mapping the session variable %session.userdef.logon_extra_field% to that master group in the master mapping table. For a procedure to guide you through this process, see the online help for the Users : Global Settings screen.

  • Specifying an additional domain password
    Indicates that the system provides a second password field on the logon screen. The FirePass controller passes the content of this field to the functions that enable access to Windows Files, Web Applications, Terminal Servers, and so on. If this option is disabled, the system presents only one password field on the logon screen.

Setting and changing mapping priority

The group mapping functionality maps users to one master group. If you have users who belong to more than one group in your network structure, the mapping functionality can map to only the first match it finds, as determined by the order of mappings in the master mapping table. Therefore, the order of mappings might impact the authentication and access the user receives.

For example, OneUser belongs to two groups: Sales and Marketing, both of which are configured for dynamic group mapping. In the master mapping table, the mapping for Marketing occupies the top slot, Priority 1, and Sales occupies Priority 2. In this case, at logon time, the FirePass controller maps OneUser to Marketing because that group's priority is higher.

Initially, the order in which you create mappings determines the order in which the FirePass controller checks for matches. That is, the FirePass controller compares users with the first mapping you create, then the second, and so on.

You can determine the order on the master mapping table, available from the Users : Groups : Dynamic Group Mapping screen. You can set priority on the Master mapping table screen to change the order of the mappings in the table.

Setting up authentication

Authentication is the process of verifying the identity of a user logging on to a network. In a typical authentication process, a system requires that users provide logon information such as user name and password. The system then checks those credentials against information maintained remotely or locally on a server or in a database.

Note

The stringent nature of the authentication mechanism you use for the FirePass controller should match your local network. That is, you should use equally high standards for the FirePass controller authentication as you do for your local network.

The FirePass controller uses master groups to determine authentication parameters, so you set up authentication when you create master groups. You can authenticate users using FirePass controller internal groups, or you can use an external server. To determine which authentication method is right for your setup, see Managing user information in an external data store or Managing users in the FirePass controller data store .

Authentication (tasks that ensure that users are who they claim to be), and authorization (tasks that enable access to resources, applications, and network shares) are two separate processes on the FirePass controller.

Choosing an authentication scheme

You specify an authentication scheme when you create your master groups. You can also change an authentication scheme from one type to another. You can select from several structures for maintaining users for authentication.

  • If you plan to use local authentication using the same scheme for all users, you can simply add all users to the FirePass controller default master group and set up the authentication you want for the default group.
  • If you plan to use external authentication using the same scheme for all users, F5 Networks recommends that you create a new master group with external user maintenance. In this case, you do not need to add users to the FirePass controller at all. Because the default master group is configured for internal users, you must create a new master group in order to maintain users externally.
  • If you want to use different authentication for different users, you must create separate master groups on the FirePass controller.

To specify the authentication method for a group

  1. In the navigation pane, click Users, expand Groups, and then click Master Groups.
    The Master Groups screen opens.
  2. Click the Create new group button.
  3. In New group name, type the name you want for the group.
    You can use up to 48 alphanumeric characters, as well as underscore ( _ ), hyphen ( - ), and period ( . ), and the first character must be alphanumeric.
  4. From Users in group, select Local to maintain users in the FirePass controller database, or External, to have the users authenticated from your external network server.
  5. From Authentication method, select the authentication method you want. For more information on the available authentication methods, see Determining the authentication method , following.
  6. Click Create after selecting any other options you want for the group .

For more information on creating master groups, see Configuring a master group .

Determining the authentication method

You can set up FirePass controller authentication using any combination of the following methods for different master groups. Each master group uses one authentication method.

Important

To use a specific authentication scheme, you must have a server at your site that supports the scheme.
  • FirePass controller's internal authentication
    Uses the internal FirePass controller authentication method for storing the logon credentials, email, group, and mail server. Internal authentication does not require any other configuration. You must assign each user a password, which the users can then change from their webtops. The FirePass controller stores a hash of user passwords. For more information on this method, see Managing users in the FirePass controller data store .
  • RADIUS server
    Uses the server at your site that supports authentication using the RADIUS protocol. If you want to use RSA SecurID over RADIUS protocol, select this option. If you want to use RSA SecurID over its native protocol, select the RSA SecurID option instead. For more information on this method, see Setting up RADIUS server authentication .
  • LDAP server
    Uses the server at your site that supports authentication using LDAP. For more information on this method, see Setting up LDAP server authentication .
  • Basic HTTP authentication to external server
    Uses external, web-based authentication servers such as Oracle® COREid®, eTrust SiteMinder®, and others to validate user logons and passwords, and to control user access to specific network resources. For more information on this method, see Setting up HTTP basic authentication to external server .
  • Initial signup on LDAP with subsequent strong password
    Authenticates first-time users against an LDAP directory, but at the first use also presents a form to require them to entry a strong password. Subsequently, the user is authenticated using the internal FirePass controller database. This method allows you to use strong passwords not supported by your LDAP directory, while providing most of the convenience of LDAP authentication. For more information on this method, see Setting up initial signup on LDAP with subsequent strong internal password .
  • Windows domain server
    Uses the Windows domain server at your site that supports NTLM authentication against a pre-Windows 2000 domain controller. For more information on this method, see Setting up Windows domain server authentication .
  • Windows Active Directory
    Uses the server at your site that supports Kerberos authentication against a Windows 2000 or later server. For more information on this method, see Setting up Active Directory authentication (Kerberos authentication) .
  • HTTP form-based
    Integrates with single sign-on systems such as Oracle COREid, and eTrust SiteMinder. For more information on this method, see Setting up HTTP form-based authentication .
  • Client certificate passwordless
    Requires no name or password at logon for users who have the installed client certificate. For more information on this method, see Setting up client-certificate-based authentication .
  • RSA SecurID
    Uses the server at your site that supports RSA's SecurID technology over its native protocol. RSA SecurID represents a two-factor authentication scheme that uses a combination of a known password and a digitally generated string to grant access to the FirePass controller. The FirePass controller is RSA-certified. If you want to use RSA SecurID over RADIUS, select RADIUS instead. For more information on this method, see Setting up RSA SecurID authentication .

Changing authentication methods

You can convert from any authentication scheme to another.

To convert the authentication method for a master group

  1. In the navigation pane, click Users, expand Groups, and then click Master Groups.
    The Master Groups screen opens.
  2. In the Authentication column, click the link associated with the master group you want to affect.
    The master-group-specific authentication screen opens.
  3. Click the Convert authentication method link.
    The convert-authentication screen opens.
  4. From the list of authentication schemes available for conversion, click the method you want to convert to. For more information on the available authentication methods, see Determining the authentication method .
  5. On the convert-confirmation screen, click the Continue button.
    The associated Authentication screen opens.
  6. Specify the settings and options you want, and then click the Save Settings button.
Important

Depending on the conversion, you might be required to configure additional settings. For example, if you convert to the internal authentication method, you must make sure to specify passwords as well as add any missing data so all of the fields are filled on the associated user information screen. For more information on converting to an authentication type, see the section associated with the specific method. For example, if you are converting to the RADIUS authentication method, see Setting up RADIUS server authentication .

Setting up internal authentication

This method uses an internal database storing FirePass controller user data: name, logon designation, password (stored as cryptographically strong hashes), email address, group name, mail server, and NFS logon/password. Initially, each user has to be assigned a password. Later on a user can change it from the webtop.

Setting up RADIUS server authentication

The FirePass controller can authenticate using a RADIUS server. On the RADIUS server, you must set up the FirePass controller as a client of the RADIUS server. Then, establish a shared secret and add it to both the RADIUS server and the FirePass controller so the RADIUS server can trust the FirePass controller.

Important

Be sure that the RADIUS server is configured to recognize the FirePass controller as a client. Use the same shared secret in both the RADIUS server configuration, and in the FirePass controller configuration.

Tip


You can specify up to three RADIUS servers for redundancy. The FirePass controller tries to authenticate using the first configured server. If there is no response, it falls back to the secondary server. If the secondary server does not respond, the FirePass controller tries with the tertiary server.

Configuring RSA SecurID using RADIUS

FirePass controller fully supports RSA extensions for RADIUS and is RSA-certified. You have one of the following options.

  • If you plan to use RSA SecurID over RADIUS, select RADIUS as the authentication method.
  • If you plan to use RSA SecurID over its native protocol, select RSA SecurID as the authentication method.

For more information, see Setting up RSA SecurID authentication .

Troubleshooting RSA SecurID on Windows using RADIUS configuration

If you are having difficulty authenticating using RSA SecurID over RADIUS, on the authentication server that is running RSA SecurID server, check to make sure these settings are correct:

  • The RADIUS service is active.
    Even if the RADIUS service has been started from the SecurID options window on the Windows SecurID server, the service may not be active. In the Windows Services Manager, make sure that the service is set to start each time the server boots, and is currently running. RSA SecurID authentication using RADIUS takes place on a different port than does native SecurID authentication.
  • The SecurID server is configured correctly for RADIUS authentication.
    While using RSA SecurID over RADIUS, the SecurID server is a client of itself. The RADIUS service functions as a standalone process, and if the SecurID server is not set up as a client of itself, it rejects the FirePass controller authentication request and does not store anything in the logs. In this case, the FirePass controller reports that authentication has failed, and with no log information, the failure is difficult to diagnose. To troubleshoot, check that:
    • You have enabled support for the RADIUS protocol for the RSA SecurID server.
    • You have configured the FirePass controller as a client of the RSA SecurID server.

Configuring Single Sign On using a RADIUS attribute

You can configure the FirePass controller to retrieve the Single Sign On (SSO) password information from an attribute returned from the RADIUS user profile. The FirePass controller parses the return value to retrieve the SSO password information in various formats.

For example you can use 25 for the Class attribute, 26 for the Vendor Specific attribute, or 11 for the Filter-ID attribute.

Note

SSO configuration is applicable for simple RADIUS as well as RSA SecurID over RADIUS.

Setting up LDAP server authentication

The FirePass controller can authenticate using any LDAP database, including a Windows Active Directory.

You can use an LDAP-protocol-based directory, including an Active Directory, to authenticate users dynamically. In this case, you do not store user information on the FirePass controller. Instead, you obtain it from the LDAP entry.

Using the Template option for LDAP authentication

If the FirePass controller logon matches the naming attribute that your LDAP directory uses as part of the bind DN, you can look for the user's entry directly by configuring the option described in the following procedure.

To specify the template option for LDAP authentication

  1. In the navigation pane, click Users, expand Groups, and then click Master Groups.
    The Master Groups screen opens.
  2. In the Authentication column, click the link representing the master group you want to configure.
    The screen changes, and you see the authentication screen for the corresponding master group.
  3. In Host, specify the FQDN or the IP address of the LDAP server.
  4. In Port, specify the port on which the LDAP server listens.
    The default values are 389, which represents LDAP, and 636, which represents secure LDAP.
  5. From the Protocol version list, select 2, if yours is an LDAPv2 configuration, or 3, if yours is an LDAPv3 configuration.
  6. In User DN Template, type the following string, substituting the appropriate value for YourCo.
    cn=%logon%,o=YourCo

During logon, the authentication mechanism substitutes the user's FirePass controller logon as part of the bind DN, and supplies the entered password as the bind password. If the bind operation succeeds, the user is validated.

Using the Query option for LDAP authentication

If the user name and password are not the same as the LDAP logon (for example, if the LDAP user ID contains characters that the FirePass controller does not support), then you cannot use the FirePass controller logon to bind to the LDAP directory. Instead, you must query to find the correct DN to use in a second attempt to bind.

Query the appropriate part of the directory tree structure (specified by the search base, or container, DN) to find a user within that branch.

Your LDAP directory might allow anonymous queries. If so, you do not need to specify an account and password. Otherwise, either specify credentials of any LDAP account that is allowed to query this part of LDAP directory, or create a new LDAP account for FirePass device.

Note

Your schema may vary considerably from the examples presented in the following list. The user object class user is different on some LDAP servers, and your structure might have more layers of names defined between the root and the leaves.

To specify certain parameters, you must have the following information, which you can get from your LDAP server administrator:

  • User DN for query: The fully qualified DN of the user with rights to run the query. We recommend specifying this value in lower case and without spaces for compatibility with some specific LDAP servers.
    The specific content of this string depends on your directory layout.
  • For example, in an Active Directory structure, a typical User DN for query would be similar to the following string: cn=administrator,cn=users,dc=eng,dc=net,dc=com

  • Password: The password associated with the DN you specified in User DN for query. You can leave this field blank if your LDAP server allows anonymous queries.
  • Search base DN (Container DN): Determine the appropriate values from your specific directory layout.
    The specific content of this string depends on your directory layout.
  • For example, in an Active Directory structure, a typical Search base DN would be similar to the following string:

    cn=users,dc=eng,dc=net,dc=com

  • Query template: For example, (&(sAMAccountName=%logon%))

After the FirePass controller runs the query. If it finds a matching user entry, it uses the returned DN value and the user-entered password to bind to the LDAP directory. If the second bind succeeds, the authentication succeeds (that is, the user is validated). If either bind fails, the authentication fails.

Setting up HTTP basic authentication to external server

Basic authentication requires a valid URL resource. This resource must respond with a challenge to a non-authenticated request. This method supports authentication over both HTTP and HTTPS protocols. Redirects are not supported.

Note

F5 Networks strongly recommends using HTTPS because basic authentication passes user credentials as clear text.

You can test the URL by logging on with valid and invalid credentials, to make sure your external authentication server issues a challenge when invalid credentials are tendered, and that it does not send a redirect.

Setting up initial signup on LDAP with subsequent strong internal password

This option authenticates new users against an LDAP directory. At logon, the FirePass controller presents a form requiring the new user to enter a strong password. Subsequently, the user is authenticated using the FirePass controller internal method.

With this method, you can use strong passwords not supported by LDAP directory, while providing most of the convenience of LDAP authentication.

To use Initial Signup on LDAP with Subsequent Strong Internal Password authentication, you also must use template-based signup for the group. To enable signup by templates, use the Users : Signup Templates screen.

A strong password is one that is difficult to detect by both humans and computer programs, which effectively protects data from unauthorized access.

On the FirePass controller, a strong password must:

  • Contain at least eight characters
  • Start with an alphabetical character
  • Contain at least one numeric character from the set 0, 1, 2, 3, 4, 5, 6, 7, 8, 9.
  • Contain at least one special character from the set ` ~ | . , : ; ? / ' " \ { } < > ! @ # $ % ^ & * ( ) + = _ -
  • Contain no more than three consecutive occurrences of the same character
  • Not contain the employee name or logon
Note

In a strong password, neither the number nor the special character may be in the last character position.

Setting up Windows domain server authentication

Within a Windows domain there are usually a number of groups defined, with users belonging to one or more of these groups. You can map existing Windows domain groups directly to existing FirePass controller master groups. When a user attempts to log on to the FirePass controller, the Windows domain groups that the user belongs to are retrieved from the domain. The FirePass controller attempts to match one of the domain groups against the FirePass controller-configured mapping, and the user is dynamically moved to the new FirePass master group based on a match. For more information on group mapping, see Understanding dynamic group mapping .

Windows domain server supports the following authentication modes:

  • Native NTLM authentication
    Uses Native Windows NT LAN Manager (NTLM) authentication if you specify domain administrative credentials when you set up Windows domain authentication on the FirePass controller. This allows FirePass controller to add a machine account for itself, join the domain, and create a trust relationship with the Primary Domain Controller (PDC). FirePass controller can then authenticate users using native NTLM services.
  • Netlogon Share
    If you do not specify domain administrative credentials when you set up Windows domain authentication on the FirePass controller, then the FirePass controller uses a more basic method for authenticating users. The FirePass controller connects to the Netlogon share on the configured PDC using the user's credentials to determine whether the user has a valid account within the domain. If binding to Netlogon succeeds, the FirePass controller authenticates the user.

Setting up Active Directory authentication (Kerberos authentication)

Computers using Windows 9x or Windows NT typically use the NTLM protocol for network authentication in Windows 2000 domains. Computers running Windows 2000 and later might use NTLM when authenticating to servers with Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains, but the more commonly used protocol is Kerberos, generally referred to as Active Directory. If you are running Windows 2000 or later servers, F5 Networks recommends that you use Active Directory authentication instead of Windows domain authentication.

For specific procedures for setting up Active Directory authentication, see Configuring Active Directory-based mapping .

Setting up HTTP form-based authentication

You can configure the FirePass controller to use external, web-based authentication servers such as Oracle COREid, eTrust SiteMinder, and others, to validate user logons and passwords and to control user access to specific network resources. The FirePass controller can detect any of the following response types from an external server:

  • A valid redirect URL in the external server's response
  • A specific, configurable substring in the external server's response
  • The presence of a specific cookie in the external server's response to the FirePass controller request for user validation

From the standpoint of the authentication server, the FirePass controller appears as a proxy browser. The FirePass controller itself is transparent to the authentication application. You do not need to make any configuration changes to the authentication server to integrate it with the FirePass controller.

Setting up client-certificate-based authentication

To use client certificates, you must have a server configured as a Certificate Authority (CA) that can generate a client root certificate and the client certificates based on the client root certificate. Or, you can purchase the client root certificate and client certificates from an external CA. For more information about installing client certificates, see Installing and configuring client root certificates .

Using client certificates

When the FirePass controller is serving as the client certificate CA, you can generate and download client certificates on the User's details screen. To access the screen, click Users, click User Management, and click the edit button associated with a specific user.

The issued client certificates are based on the subject fields of the issuing client root CA certificate. The common name (CN) is set to the logon name, and the Organization Unit (OU) might be set to the user's group name on the FirePass controller (for use with dynamic group mapping functions).

You can enable the setting to request the client certificate during logon only after installing a valid client root certificate. This instructs the FirePass controller to request the client certificate as part of the SSL session negotiation, which occurs before the client attempts to log on to the FirePass controller. It also validates and logs the client certificate, but it does not restrict access to the FirePass controller.

You can determine whether content from client certificate fields automatically populates the user name field at logon time. When you request a client certificate during logon, you use one of several options.

  • Do not use certificate field for logon username
    Select this option if you do not want any client certificate field to map to the FirePass controller logon name. When you select this option, the FirePass controller does not support client certificate passwordless auto-logon authentication, and other client certificate functions do not check to ensure that the user name matches any client certificate field. However, the FirePass controller does check the client certificate the user provides against the installed root CA certificate, and against any configured CRL checking mechanisms.
  • Use certificate common name (CN) for logon username
    Select this option if your PKI infrastructure issues client certificates that use the common name (CN) as the FirePass controller logon user name or when the certificate is generated on the FirePass controller. When the FirePass controller is configured to serve as the client root CA and issues client certificates directly, it issues certificates that use the client certificate CN as the logon name. When you select this option, the FirePass controller populates the logon name prompt with this value, and other client certificate functions check to make sure the logon name matches the CN field in the client certificate.
  • Use certificate e-mail address for logon username
    Select this option to use the email address of the user as the FirePass controller logon user name. When you select this option, the FirePass controller populates the logon prompt with this value, and other client certificate functions check to make sure the logon name matches the email address in the client certificate. the FirePass controller checks against the first user account found with the specified email address.
  • Use certificate serial number (SN) for logon username
    Select this option to use the certificate serial number (SN) as the FirePass controller logon name. When you select this option, the FirePass controller populates the logon name prompt with this value, and other client certificate functions check to make sure the logon name matches the SN field in the client certificate.
  • Use certificate subject DN field (regex extraction) for logon username
    Select this option to use a different value from the client certificate distinguished name (DN) as the FirePass controller logon name. You can then specify a Perl-style regular expression to extract the user name from the DN. The following example shows a sample DN:
    /C=US/ST=CA/L=MyCity/O=MyCompany/OU=MyDept/CN=user/emailAddress=user@company.xyz
  • You can use an expression such as |CN=(.*)/| to extract the CN for use as the logon name. When you select this option, the FirePass controller populates the logon prompt with the value extracted, and other client certificate functions check to make sure the logon name matches the extracted field from the client certificate.

  • Use certificate ext subjectAltName field (regex extraction) for logon username
    Select this option to use the X509v3 extension's Subject Alternative Name attribute. You can then specify a Perl-style regular expression to extract the subjectAlternativeName from the certificate. For example, if the certificate has the SubjectAltName extension attribute as
    X509v3 Subject Alternative Name:
    email:joeuser@siterequesta.com, email:joeuser@siterequestb.com

    to extract the second e-mail address from this attribute using a regular expression, you can use the following expression
    |email:.*, email:(.*)|

Configuring for client certificate authentication

Client certificates serve as a security mechanism that allows the FirePass controller to verify that the client computer is a valid computer. You can use client certificates in the following ways:

  • Two-factor authentication
    In the two-factor authentication system, users must have a valid client certificate installed in addition to specifying a user name and password. After installing a client root certificate and enabling the option to request client certificate during logon, the Client Certificate Two-Factor Authentication section becomes available on the Authentication tab for each master group. To access the screen, click Users, expand Groups, click Master Groups, and click the link in the Authentication column for the master group you want to configure. For information about this feature, see Configuring client-certificate two-factor authentication .
  • Extra policy layer of protection
    You can specify use of client certificates for individual access functions or individual resource protection. For example, you can limit access to the FirePass controller Network Access service only to corporate laptops with valid client certificates installed. In that case, users do not have access to the Network Access service from untrusted locations, such as public access kiosks. But you still can give them access to Web Applications, even from untrusted locations.
  • You can use client certificates to control access to resources by creating a named endpoint configuration on the Protected Configuration screen. To access the screen, click Users, expand Endpoint Security, click Protected Configurations, and then click the New Protected Configuration link. You can assign the endpoint protection you created on the Protect Resources screen. To access the screen, click Users, expand Endpoint Security, and click Protect Resources. Then click the Select link for each service (for example, all Web Applications or webtops), an individual resource group, or several favorites you want to protect, and select the protected configuration you want to use. For information about protected configurations, see Creating protected configurations , and for information about protecting resources, see Protecting resources .

  • Passwordless auto-logon
    The presentation of a valid user client certificate, where the common name (CN) matches the user logon name, enables either a zero-click or one-click automatic logon. You can configure a passwordless automatic logon mechanism on the Authentication screen. To access the screen, click Users, expand Groups, click Master Groups, and click the link in the Authentication column for the master group you want to configure. For information about this feature, see Configuring passwordless authentication .
  • Dynamic group mapping
    The existence of a valid user client certificate allows use of fields within the client certificate to enable dynamic mapping of users into particular FirePass controller master authentication groups or to particular resource groups. This allows use of extensive resource policy management based on existence and fields within a client certificate. You can configure the dynamic group mapping mechanism on the Dynamic Group Mapping screen. To access the screen, click Users, expand Endpoint Security, and click Dynamic Group Mapping. For information about dynamic group mapping, see Understanding dynamic group mapping .
  • Pre-logon sequence processing
    The existence or nonexistence of a valid user client certificate controls whether the FirePass controller performs the defined pre-logon actions, such as loading the protected workspace or denying access to the FirePass controller logon screen. You can configure a pre-logon sequence that require client certificates on the Pre-Logon Sequence screen. To access the screen, click Users, expand Endpoint Security, and click Pre-Logon Sequence. For information about pre-logon sequences and inspectors, see Creating pre-logon sequences to protect resources .
  • Resource protection
    You can use client certificates to control access to resources by assigning a previously defined and named endpoint configuration (created using the New Protected Configuration link on the Users : Endpoint Security : Protected Configurations screen) to a resource on the Protect Resources screen. To access the screen, click Users, expand Endpoint Security, and click Protect Resources, and then click the Select link for each service you want to protect. For information about protected configurations, see Creating protected configurations .

Using client certificates to authenticate users

To use client certificates, you must have a server configured as a Certificate Authority (CA) that can generate a client root certificate and the client certificates based on the client root certificate. Or, you can purchase the client root certificate and client certificates from an external CA.

Here is an overview of the tasks required for using client certificates to authenticate a user's computer:

  • Install the client root certificate on the FirePass controller. You can install a client root certificate using the Certificates screen. To access the screen, click Device Management, expand Security, and click Certificates.
  • Enable the validation of client certificates.
  • Configure client certificate validation as part of the authentication for a group.
  • Instruct users how to download and install the client certificate on their computers. You can also email the client certificates to users.
  • Install a certificate revocation list (CRL) that contains a list of client certificates for users who you want to deny access to the FirePass controller, for example, the revoked client certificates of users who have left your company.
  • The FirePass controller can then request and validate the computer's client certificate against its installed client root certificate as part of the authentication process.

Configuring passwordless authentication

If you select the Client certificate passwordless authentication method for any group, the FirePass controller requests a client certificate from the user machine. This client certificate can be one issued by your company's PKI infrastructure, one made available from a SmartCard solution, or one created and distributed to the user by the FirePass controller itself.

If the client machine has a trusted certificate, the FirePass controller follows this process when authenticating.

  • Hide the password prompt, and populate the User name box on the logon page with the client certificate field that you configured on the Certificates screen. The user cannot edit this logon user name.
  • The FirePass controller validates the certificate against the installed client root certificate. It also checks the certificate against any configured CRL methods enabled.
  • The FirePass controller validates the user name against the internal authentication database. If you specify use of sign-up by templates for the group (along with dynamic group mapping, to make sure the user is mapped to a group supporting client certificate authentication), then the FirePass controller automatically adds the user based on the client certificate.
  • Users who are validated need only click the Logon button to log on to the FirePass controller webtop (one-click logon). If you have enabled automatic logon when the client certificate is present, the FirePass controller logs the user directly on to the FirePass controller webtop (zero-click logon). In this case, the FirePass controller verifies the client certificate common name (CN) field against the logon user name.

  • If there is no client certificate on the remote machine, the FirePass controller provides the regular logon screen, and attempts to authenticate the users using the methods specified for other authorized groups.

If you have more than one client root certificate installed, you can select a client certificate issuer to restrict authentication to certificates issued by that specific client root certificate. For more information on functionality with more than one client root certificate installed, see Installing and configuring client root certificates .

Configuring client-certificate two-factor authentication

You can require the existence of a valid client certificate as a secondary authentication factor, that is, a scheme requiring two authentication methods. You can configure client certificates as part of a two-factor authentication system, in which users must have a valid client certificate installed on their computer in addition to entering their user name and password at logon time.

A server certificate verifies the server's identity to a user's computer. In addition to using server certificates, you can require client certificates that enable the FirePass controller to verify the identity of a user's computer, and to control access to specific resources, applications, and files. For more information about server certificates, see Using server certificates on the FirePass controller .

You can require valid client certificates to gain access to specific applications. For example, you might provide access to the FirePass controller Network Access service only for users who present valid client certificates. That user could access the Network Access service from the laptop, but not from other locations, such as public access kiosks, where the certificate might not be installed.

To configure two-factor authentication

  1. In the navigation pane, click Users, expand Groups, and then click Master Groups.
    The Master Groups screen opens.
  2. In the Authentication column, click the link representing the master group you want to configure.
    The screen changes, and you see the authentication screen for the corresponding master group.
  3. In the Client Certificate Two-Factor Authentication area, check the Require client certificate for user logon check box.
    The screen refreshes to reveal certificate-specific options, and a message indicating which client certificate field the FirePass controller uses to populate the logon field, depending on the option you selected on the Device Management : Security : Certificates screen.
  4. From the Required client certificate issuer list, select a client certificate that you want the client computer to present.
  5. The client certificate can be one issued by your company PKI, one made available by a SmartCard solution, or one created and distributed to the user by the FirePass controller itself.

If you have not installed a client certificate, you do not see the Request client certificate during logon check box on the Device Management : Security : Certificates screen, or the Require client certificate for user logon check box on the Users : Groups : Master Groups screen. In that case, install a client root certificate first, using the Client Root Certificate or Self-Signed Certificate option on the Device Management : Security : Certificates screen. For more information, see Installing and configuring client root certificates .

If you have more than one client root certificate installed, you can select a client certificate issuer to restrict authentication to certificates issued by that specific client root certificate. For more information on functionality with more than one client root certificate installed, see the online help for the Device Management : Security : Certificates screen.

Setting up RSA SecurID authentication

If you are using an RSA SecurID server using its native protocol (that is, not over RADIUS), you must configure the authentication server so that the FirePass controller can communicate with it.

You can enable support on the server by adding the FirePass controller as a UNIX Agent Host to the RSA server configuration.

When you configure the UNIX Agent Host, make sure to use the virtual IP address of the FirePass controller as the primary IP address. If your configuration uses failover units, configure each failover unit as a secondary node, using the actual (not virtual) IP address. You can find more information on configuring secondary nodes in the administrator's guide for your RSA SecurID server.

Next, you must configure a new RSA SecurID server on the FirePass controller. To do so, navigate to the Device Management : Configuration : RSA SecurID screen. Because the FirePass controller is a multihome appliance with multiple IP addresses, the source IP address setting that the FirePass controller uses for communicating with the RSA SecurID server is very important. It must be the same address as the IP address you specified in the network address field when you configured the FirePass controller as an agent host on the RSA SecurID server. Once configured, the Authentication screen for any master group shows the name, configuration file upload time, and source IP address it will use for communicating with the RSA SecurID server.

When you specify the source IP on the FirePass controller, if there is a NAT device in the network path between the FirePass controller and the RSA SecurID server, use as the source IP the address as translated by the NAT device. Otherwise, specify the IP address from among those configured on the FirePass controller.

Important

In all cases, the source IP address must match the SourceIP address in the IP packets received by the RSA SecurID server.

For specific procedures for each of these operations, see the online help for the Device Management : Configuration : RSA SecurID screen.

If you have already configured one or more RSA SecurID servers on the FirePass controller, you can select from the list of RSA SecurID servers on the Users : Groups : Master Groups screen, using the Authentication tab.

Working with resource groups

When you are ready to configure the resources for users to access, you use the options on the Resource Groups screens. Using theses options, you can configure favorites that link to intranet resources, web applications, network shares, application tunnels and legacy host applications.

To create a resource group

  1. In the navigation pane, click Users, expand Groups, and then click Resource Groups.
    The Resource Groups list screen opens.
  2. Click the Create new group button.
    The Group Management screen opens.
  3. In the New group name box, type the name you want for the group.
    You can specify up to 48 alphanumeric characters, as well as underscore ( _ ), hyphen ( - ), and period ( . ), and the first character must be alphanumeric.
  4. From Copy settings from, select Do not copy to configure all settings for the new resource group, or select an existing resource group to copy settings from.
    This gives you a fast way to reuse settings you have already specified.
  5. If you select a resource group to copy settings from, you can also check Assign the new resource group to the same set of master groups to associate master groups from the based-on resource group to the new resource group. This gives you a fast way to associate master groups to resource groups.

The FirePass controller provides a default resource group called Default_resource that by default has no associated master group. You can create your own resource groups to use instead, or you can modify the default group.

The Resource Groups list screen lists all the resource groups, including the default group. From this screen, you can navigate to the other screens you need for creating favorites. You can also delete any group by clicking the associated Delete link.

Creating favorites in resource groups

You can create three basic categories of favorites for resource groups: those that provide portal access, those that enable network access, and those that support application access. Figure 2.4 , illustrates resource groups and favorite association.

  • Portal Access
    Provides a web-based application that gives users access to POP or IMAP email, network shares, and proprietary corporate applications. For more information about portal access, see Introducing Portal Access .
  • Network Access
    Connects users to the network just as if they were using a traditional IPsec Virtual Private Network connection. Then users can access any applications that use IP networking between their remote computer and the corporate intranet structure, enabling full network access through an SSL-VPN tunnel. For more information about network access, see Introducing Network Access, .
  • Application Access
    Provides users access in the following ways:
    • App Tunnels, connections to a server on a corporate LAN that uses an HTTPS-based, encrypted tunnel through the FirePass controller.
    • Terminal Servers, connections to Microsoft Terminal Servers, Windows XP® desktops, Citrix MetaFrame® servers, and VNC servers.
    • Legacy Hosts, connections to legacy greenscreen systems (for example, Vt100, Vt320, TN3270, and others) on mainframes, AS/400s, and UNIX hosts).
    • For more information about application access, see Introducing Application Access .

Figure 2.4 Visual representation of favorites categories
Note

Portal access, network access, and application access all have master group settings. When you configure favorites for a resource group, you should also check the master group settings. Master group settings apply to all favorites in a category. To find a category's master group setting, from the navigation pane, click Network Access, Portal Access, or Application Access, and then click Master Group Settings. You can find more information about master group settings in the online help for the associated screen.

Associating resource groups with users

Resource groups can be static or mapped.

A resource group is considered a static resource group when it is explicitly assigned to a master group or to a internally managed user. All users in the associated master group are granted access to the statically assigned resource groups. In this case, the mapping becomes associated with the user, irrespective of the user's associated master group, so the user can move to any master group and still keep the same resource group assignment. You can assign a static resource group to a user when you create the user account, or at any time after the user account has been created.

A resource group is considered a dynamically mapped resource group when the FirePass controller grants access based on the resource mapping table. Any user who belongs to the external group is granted access to the resource groups. Users who move to a different external group are automatically granted access to any resource groups mapped to the new external group. When you add a new favorite or reconfigure an existing one, the change applies to users in all mapped groups.

When a user logs on and is successfully authenticated in a master group, the FirePass controller grants the user access to the associated master group's assigned resource groups. You can also directly assign resource groups to local users from the User : User Management screen.

To assign a resource group statically

  1. In the navigation pane, click Users and click User Management.
    The User Management list screen opens.
  2. Click the edit button associated with the user you want to have access to the resource group.
    The User's details screen opens
  3. In Available individual resource groups, along the right side of the screen, check the resource groups you want the user to access.
  4. Click the Change button.
    The groups now appear in Assigned resource groups.

To assign a resource group dynamically

  1. In the navigation pane, click Users, expand Groups, and click Master Groups.
    The Master groups list screen opens.
  2. Click one of the existing master group names.
    The master group's screen opens, with the General tab selected.
  3. In the Resource Groups column click the link associated with the master group you want to configure with resources.
    The Resource Groups configuration screen opens.
  4. From the Available list, select the resource group or groups you want to make accessible to users in the master group.
    You can use the Shift and Ctrl keys to select multiple resource groups.
  5. Click the Add button to add the resource groups to the Selected list.

See Figure 2.1 , for a visual representation of the relationship between users, master groups, resource groups, and favorites categories.

To edit a resource group association

  1. In the navigation pane, click Users, expand Groups, and click Resource Groups.
    The Resource groups list screen opens.
  2. In the Network access, Portal access, or Application access column for any resource group, click the Edit link.
    The category's favorites page opens.
  3. Configure the favorites you want.
    For more information about favorites, see Configuring resource group favorites , following.

Tip


You can switch to a different resource group by selecting a group from the Resource Group list. This is an easy way to switch from one resource group to another, without returning to the Resource groups list screen.

Configuring resource group favorites

Once you have created resource groups, the next step is to configure favorites for the resource group. Any user who belongs to a resource group automatically gets the configured favorites of that resource group. Favorites include web applications, Windows files, App Tunnels, Legacy Hosts, Terminal Servers, Portal Access, and Network Access. You configure the favorites for resource groups based on which users have the resource groups assigned to them. or their master group

Impersonating a user

You can use the Impersonate User feature to log on as if you were a user. This feature can help you troubleshoot configuration once everything is configured. You can find Impersonate User on the Users item in the navigation pane. This feature is useful for checking favorites that you create and for troubleshooting other connection issues.

Important

When you impersonate a user, the system ends your administrative session.

The impersonation process skips the step of authenticating the user. In order to skip authentication, the FirePass controller must have sufficient information about those users to treat them appropriately. Therefore, you can impersonate only those users whose information is maintained in FirePass controller data store.

When you log on using the Impersonate User feature, the system behaves as if users were authenticated, even if those users would not pass normal logon procedure. While impersonating a user, you do not have access to any network resources that require logging on.

While you are impersonating a user, the system records the actions of the impersonated user in the Sessions report, available in Reports : Sessions. Because the user did not actually log on, the system does not record an entry in the Logon report.

Note

Although you can impersonate deactivated users, you do not have access to any of the users' assigned resources.



Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)