Applies To:

Show Versions Show Versions

Manual Chapter: FirePass® Controller version 5.5 Administrator Guide: 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 authentication and define 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. For example, you might create a Partners master group for corporate partners that has access only to specific intranet and extranet resources, while the Sales master group, represented by members of the company's sales team, can connect to email, the company intranet, and specific applications.

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, 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 to individual users. This way, you can ensure that only the users who meet the authentication criteria and security settings requirements, and 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

Working with user accounts

You have a choice when determining the user-management structure of master groups:

  • 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 use internal user management.

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

You have a choice when determining the authentication method for users in master groups:

  • 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 locally or externally.
  • 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
  • VASCO® Digipass® technology (with additional license module)

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 Working with user accounts .

  • 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 internal FirePass controller database. See Using signup templates to add user accounts .

All of these methods create user accounts in FirePass controller internal groups. 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. 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


External user management is the recommended user-management method.

The FirePass controller supports external user management by using group mapping. In group mapping, you can associate your local network groups to one or more FirePass controller master groups and resource groups. Mapping external groups to FirePass controller master groups and resource groups automates the process of authenticating users and providing access to resources. When you use group mapping, when your company acquires new employees that you add to your various external groups, those new users can log on to the FirePass controller, get authenticated correctly, and receive access to the resources configured for the master group; there is no need for you to do any configuration on the FirePass controller at all.

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. From the Users in group list, select External.
  4. 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.
  5. Click the Create button.
    The master group configuration screen opens with the General tab selected.
  6. Note: When you create new groups with external users, the FirePass controller automatically selects the using dynamic group mapping option in Assign users to this group.
    You cannot change dynamic group mapping assignment options for groups with external users.

  7. While you are on the screen with the General tab options, make sure to select Enable from Dynamic resource assignment.
  8. Finally, 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.
  9. If you prefer, you manually assign resource groups to the master group by selecting Disable on the General tab. In this case, 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.

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

  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. From the Users in group list, select Local.
  4. From the Authentication method list, select the authentication method you want to use.
    You can select Internal database to authenticate users internally, or you can select any other option to authenticate users externally.
  5. Click the Create button.
    The master group configuration screen opens with the General tab selected.
  6. Finally, 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.
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 internal 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 internally 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, or Users.
  • 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.

For specific procedures for each of these operations, see the online help,

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 automatic sign-up and 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 manage users locally, you can configure a signup template to automatically add the users to the internal group when they log in to the FirePass controller for the first time. When you elect to use signup templates, the FirePass controller can display a screen for first-time users to enter 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 still adds users to the master 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.

For externally authenticated users, the FirePass controller retrieves the user's logon and account information (except for password) from the external server when it adds the user account to the internal group, so you do not need to configure signup templates for master groups with externally authenticated users.

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 the appropriate master group or resource group.

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 specific procedures for each of the following operations in the online help for the screen that supports the process.

  • How to for dynamic group mapping
  • General procedure for configuring dynamic group mapping
  • Mapping two RADIUS groups to a single FirePass controller group
  • Setting mapping priority
  • Mapping based on Active Directory groups
  • Mapping based on Windows domain groups
  • Mapping based on LDAP user object, group object, or filter information
  • Configuring the LDAP-based request
  • Mapping based on landing URI

Understanding the group mapping process

It is helpful to understand the sequence of the group mapping process on the FirePass controller. The process of dynamic group mapping takes place in the following order, when a user connects to the FirePass controller.

  • The FirePass controller queries any external servers that are configured as mapping methods and attempts to match the user to a master group based on entries in the master mapping table and the resource mapping table. The FirePass controller also gathers information from the client workstation if that information is available.
  • For example, if LDAP is configured as a mapping method, the FirePass controller sends a query to the LDAP server to gather the information requested. If client certification is required, the FirePass controller checks for a certificate on the client workstation. For more information on configuring mapping methods, see Specifying a group mapping method .

  • The FirePass controller compares the results of the query with each entry in the mapping table, looking for a match. For details on the mapping table, see Understanding entries in the User Management list .
  • At log on time, dynamic group mapping associates users with one master group and zero or more resource groups. If a user matches more than one entry in the master mapping table, the FirePass controller uses the first match it encounters. The user gets mapped to each resource group that matches the master group.
  • You can set the order in which matching operations should occur by specifying the priority number for the group in the master mapping table. To access the master mapping table screen, in the navigation pane, click Users, expand Groups, click Dynamic Group Mapping, and then click the Master mapping table tab.

  • If the mapping succeeds, then the FirePass controller authenticates the user by whatever authentication methods are configured for that group. When the FirePass controller finds a match, it provides the user access to the resource groups and favorites associated with the mapped entries. If the master group mapping fails, then this is the result:
    • If the user belongs to a group that uses dynamic group mapping, then the user is not authenticated.
    • If the user belongs to a group that contains manually added or imported users, then the user is authenticated, but is only allowed to access resource groups and favorites that are statically assigned to the master group or individually assigned to the user.

You can find sample mapping procedures in Specifying a group mapping method .

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.

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 will 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 changing roles.

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, in the Assign users to this group area, select the using dynamic group mapping option.
    • For resource groups, in the Dynamic resource assignment area, select the Enable option.
  4. Click the Update button.

If the FirePass controller cannot map fields from the source to one of its master groups as specified, or if the user does not have the associated client certificate, then this is the result:

  • If the user belongs to a master group in which the Assign users to this setting is using dynamic group mapping, then the FirePass controller does not authenticate the user.
  • If the user belongs to a group in which the Assign users to this group setting is manually or via user import, then the FirePass controller authenticates the user only to the associated master group.

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 Specifying the request configuration ), 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 Mapping methods screen opens.
  2. 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 list already contains all methods, the screen presents no list or button. For more information, see Specifying a group mapping method .
  3. Click the Request configuration tab.
    The Request configuration screen opens.
  4. 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.
  5. 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 Specifying the request configuration .
  6. Click the Master mapping table tab.
    The Master mapping table screen opens.
  7. 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.
  8. 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 configure the LDAP user object request .
  9. Click the Resource mapping table tab.
    The Resource mapping table screen opens.
  10. 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.
  11. 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.
  12. Click the User info mapping tab if you are using an LDAP query to retrieve user information.
    The User info mapping screen opens. For more information, see Configuring user information mapping updates .

Specifying a group mapping method

The FirePass controller provides several methods for mapping external groups to internal master groups. The selections you make depend on your external network setup. You can use any of these options.

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 on Windows environments in mixed mode.

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.

If you want to limit Active Directory group mapping to the user's primary domain, you can check the Only use Active Directory primary group for mapping option on the Users : Groups : Dynamic Group Mapping screen on the Request configuration tab.

You can use Windows domain-based authentication in several 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.

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.

To configure the LDAP user object request

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Mapping methods screen opens.
  2. From the mapping methods list, select LDAP (user object), and click Add mapping method.
    The new method is added to the list. If the list already contains a mapping method of this type, the list contains no LDAP (user object) item.
  3. Click the Request configuration tab.
    The Request configuration screen opens.
  4. From the Select method to configure request list, select LDAP as the method you want to use for configuring mapping, and then click Switch.
    The screen refreshes to reveal the configuration options for LDAP.
  5. In the LDAP server box, specify your user DN. For example
    CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
  6. 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 and click Update, 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 and click Update, 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 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)).

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

To configure the LDAP user object Master mapping table

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Mapping methods screen opens.
  2. Click the Master mapping table tab.
    The Master mapping table screen opens.
  3. From Mapping methods, select LDAP (user object), and then click Add.
    The associated Master mapping table opens.
  4. Note: If there is no LDAP (user object) item, click the Mapping methods tab, and add the LDAP mapping method first.
  5. From Attribute, select the attribute you want to use to map to.
  6. In the Attribute value column, specify the string for the FirePass controller to map to.
  7. Note: You can also map the LDAP user attribute directly to a FirePass controller master group name by checking the Map verbatim box. In this case, the FirePass controller removes the Attribute value and FirePass Group fields.
  8. From FirePass group, select the group you want to map to the users returned by the filter expression.
  9. Click Add to save your mappings.
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 iPlanet 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.

To configure the LDAP group object request

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Mapping methods screen opens.
  2. From the mapping methods list, select LDAP (group object), and click Add mapping method.
    The new method is added to the list. If the list already contains a mapping method of this type, the list contains no LDAP (group object) item.
  3. Click the Request configuration tab.
    The Request configuration screen opens.
  4. From the Select method to configure request list, select LDAP as the method you want to use for configuring mapping, and then click Switch.
    The associated Request configuration screen opens.
  5. In the LDAP server box, specify your user DN. For example
    CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
  6. 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 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.
  7. Click Update to save your settings.

To configure the LDAP group object Master mapping table

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Mapping methods screen opens.
  2. Click the Master mapping table tab.
    The Master mapping table screen opens.
  3. From Mapping methods, select LDAP (group object), and then click Add.
    The associated Master mapping table opens.
  4. Note: If there is no LDAP (group object) item, click the Mapping methods tab, and add the LDAP mapping method first.
  5. In the LDAP group object DN column, type the group object DN you want to map from the LDAP group to the FirePass group.
  6. From FirePass group, select the group you want to map to the specified LDAP group.
  7. Click Add to save your mappings.
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.

To configure the LDAP filter request

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Mapping methods screen opens.
  2. From the mapping methods list, select LDAP (filter), and click Add mapping method.
    The new method is added to the list. If the list already contains a mapping method of this type, the list contains no LDAP (filter) item.
  3. Click the Request configuration tab.
    The Request configuration screen opens.
  4. From the Select method to configure request list, select LDAP as the method you want to use for configuring mapping, and then click Switch.
    The associated Request configuration screen opens.
  5. In the LDAP server box, specify the fully qualified domain name (FQDN) of the LDAP server.
  6. 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.
  7. In the User DN box, specify the user DN.
    For example
    CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
  8. Click Update to save your mappings.

To configure the LDAP filter Master mapping table

  1. In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
    The Mapping methods screen opens.
  2. Click the Master mapping table tab.
    The Master mapping table screen opens.
  3. From Mapping methods, select LDAP (filter), and then click Add.

    The associated Master mapping table opens.

    Note: If there is no LDAP (filter) item, click the Mapping methods tab, and add the LDAP mapping method first.
  4. In the LDAP filter column, specify the filter you want to use to define FirePass group membership.

    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 FirePass group, select the group you want to map to the users returned by the filter expression.
  6. Click Add to save your mappings.

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.

To configure the client certificate Master mapping table

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

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 to guide you through 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 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 virtual servers and for different URIs.

A virtual server can be one of several 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 distinct 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.

From a user standpoint, URI-based customization is maintained by a cookie. Once a user establishes a session configured for URI-based customization, then all subsequent FirePass sessions started from within the same browser use the URI-based customization, even if the user later enters either the domain name alone (for example, www.siterequest.com), or the domain name qualified by the usual redirect page (that is, for example, www.siterequest.com/my.logon.php3). To return to the global customization (or a virtual host-based customization, if there is one), the user must start a new browser session.

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.

Specifying the request configuration

You can define how the FirePass controller gets authentication information from the associated server, you can use fields and settings on the Request configuration tab, available from the Users : Groups : Dynamic Group Mapping screen. The FirePass controller supports the following types of group mapping-related request configurations:

  • LDAP (user object)
  • LDAP (group object)
  • LDAP (filter)
  • Active Directory
  • RADIUS
  • Client Certificate
  • Windows Domain

You can also specify Landing URIs for mapping using options on the URI based Customization tab, available from the Device Management : Customization screen.

Configuring user information mapping updates

You can use options on the User information mapping screen to configure updates to the internal FirePass controller database records. The FirePass controller provides several options for updating user information. To access the screen, click Users, expand Groups, click Dynamic Group Mapping, and click the User info mapping tab.

  • Do not update user information
    Indicates that local user information should not be updated.
  • Update user information from LDAP
    Indicates that updates should be made, based on settings and values specified. When you select this option and click Update, the screen refreshes to reveal options for configuring mappings from LDAP attributes to first name, last name, and email. You can also allow the user to edit personal information obtained from LDAP.
  • Update user information from Active Directory
    Indicates that updates should be made, based on settings and values specified. When you select this option and click Update, the screen refreshes to reveal options for configuring mappings from Active Directory values for first name, last name, and email. You can also allow the user to edit personal information obtained from Active Directory.

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 choose 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 .
  • VASCO Digipass technology
    Uses the pre-configured, built-in VASCO DigiPass two-factor authentication server, available as an additional module to the standard FirePass controller license. For information on this method, see the online help for the Authentication screen.
  • 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 Oblix® and Netegrity 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 Oblix and Netegrity 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 matched 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 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 the online help for the Authentication screen. To access the screen, in the navigation pane, click Users, expand Groups, click Master Groups, and click the link in the Authentication column for the master group you want.

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, on page 4-11 .

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 login 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 login 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 login 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 login 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 field (regex extraction) for login 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. A sample DN appears as follows: /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.

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 login, 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 choose the protected configuration you want to use. For information about protected configurations, see Creating protected configurations, on page 3-21 , and for information about protecting resources, see Protecting resources, on page 3-24 .

  • Passwordless auto-login
    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, on page 3-10 .
  • 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, on page 3-21 .

Using client certificates to authenticate a user's computer

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, you can exclude the client certificates for 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, on page 4-11 .

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, on page 4-1 .

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 login 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 login check box on the Device Management : Security : Certificates screen, or the Require client certificate for user login 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, on page 4-11 .

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, on page 4-11 .

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.2 , 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, on page 6-1 .
  • 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, on page 5-1 .
  • 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, on page 7-1 .

Figure 2.2 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

Introducing realms

An administrative realm is a complete set of roles, master groups, and resource groups. The concept of realms extends the existing role-based administration and simplifies FirePass controller administration by providing an organizational structure for master groups and their associated resource groups.

A FirePass controller realm consists of a set of defined master and resource groups and realm administrators, with feature access delegated them by a superuser. Superusers are users who have cross-realm access to all groups and features. A superuser creates realm administrators, upgrading them from FirePass controller users, and delegating full or restricted access to FirePass controller functionality or groups. Realm administrators are users who can create their own hierarchy of access to the groups and resources inside their realm. In a typical setup, the master and resource groups of one realm are not accessible to administrators of another realm, although superusers or realm administrators can grant access across realms.

The FirePass controller provides a default realm named Full Access containing a default superuser account named admin. Full Access gives superusers complete access to realm-configuration. Everyone serving as administrator in the Full Access realm is considered a superuser. Superusers have a realm list in the menu bar of the Administrative Console that enables navigation to other realms.

Superusers can grant users administrative access to the Full Access realm. Realm administrators can grant users administrative access only to their own realm. An administrator in one realm cannot be an administrator in any other realm, including the Full Access realm.

Tip


Realms are particularly useful for managing groups with clear functional or geographic divisions and in the service-provider scenario.

Configuring the Full Access realm

The first time the first superuser logs on to a FirePass controller, the screen for Administrative Realms contains one realm, Full Access, and one account, admin. The only actions available inside the Full Access realm are adding and deleting administrators. To set feature and group access, the superuser must first create a realm.

Only a superuser can add other superusers, create or delete realms, configure default features and groups for a realm, and delete realms in the Full Access realm.

A given user can serve as administrator in only one realm. If you have administrators who need access to more than one realm, you can add them to the Full Access realm, where they will have access to all realms.

Configuring the FirePass controller for realms

When you have a complete subset of users who need access to a specific set of resources, realms can give you the higher-level grouping mechanism you need. The following tasks encompass the general process for realm configuration:

  • Add superusers.
    For step-by-step procedures for adding superusers, see the online help the Device Management : Security : Administrative Realms screen.
  • Create realms.
    For step-by-step procedures for creating realms, see the online help the Device Management : Security : Administrative Realms screen.
  • Specify realm administrators.
    For step-by-step procedures for specifying realm administrators, see the online help for the Device Management : Security : Administrative Realms screen.
  • Specify default features and groups for each realm.
    For more information, see Configuring realm-specific settings , following.
  • Add administrators within the realm.
    For more information, see Assigning administrative privileges to a user accounts .
  • Restrict a realm administrator's access.
    For more information, see Configuring realm-level group access , following, and Configuring realm-level feature access .

Configuring realm-specific settings

It is often difficult to determine which set of administrators should do specific tasks, since each network setup is unique. But generally, realm administrators do the realm-level configuration, that is, configuration restricted to the associated administrator's realm. However, depending on the setup, a realm-level administrator might not have access to administrative functions. In that case, an administrator from the Full Access realm would also do the following tasks:

  • Assign administrative privileges to a user account
  • Add a superuser
  • Create and delete a realm
  • Add and delete a realm administrator
  • Configure default features and groups for a realm
  • Specify which groups and features are accessible in a realm
  • Restrict a realm administrator's access

A realm administrator or superuser can perform these realm-based operations using the Administrative Realms screen. To access the screen, click Device Management, expand Security, and click Administrative Realms. Realm administrators or superusers can use the Edit link in the Administrators column associated with the specific realm to add and delete administrators for the realm.

Warning

All delete operations occur immediately, without a confirmation alert, so be sure you are ready to delete a realm or an administrator before you click Delete.

Configuring realm-level group access

On the Device Management : Security : Administrative Realms screen, realm administrators or superusers can use the Edit link in the Group access column associated with the specific realm to specify which groups administrators can access.

By default, the list presented represents the groups available in the administrator's Administrative Console. Administrators can restrict accessibility to specific groups by clearing the Allow access to all groups check box. After saving, administrators can use Edit again to specify which groups the realm should contain.

Modifying access at this level affects all users in a realm, including administrators. Realm administrators or superusers can specify administrator-level restrictions using the groups link in the Administrators column for the associated realm.

Note

If the groups link is not present, it means that the realm is not configured to have access to any groups.

Configuring realm-level feature access

On the Device Management : Security : Administrative Realms screen, realm administrators or superusers use the Edit link in the Feature access column associated with the specific realm to specify which navigational areas the administrators can access.

By default, the list presented represents the links in the navigation pane of the FirePass controller's Administrative Console. To control access in the realm, administrators can check the Allow access to all features check box, or check or clear the check box next to each feature. Modifying access at this level affects all users in a realm, including administrators. Realm administrators or superusers can specify administrator-level restrictions using the features link in the Administrators column for the associated realm.

Note

If the features link is not present, it means that the realm is not configured to have access to any features.

Configuring administrator-specific access

Providing they have access to the Device Management: Security : Administrative Realms screen, realm administrators and superusers can use the features or groups links associated with a realm administrator to grant or restrict access to specific groups or features.

By default, the list presented when administrators click the features link represents the navigation pane available to all users and administrators in the realm.

The features link for a specific administrator is the one you use to restrict access to administration tasks. When the realm administrator or superuser clears the Administrative Realms check box, the navigation pane in the associated administrator's Administrative Console no longer displays the Administrative Realms item.

Assigning administrative privileges to a user accounts

You can also assign administrative privileges to an existing user account to configure a user as a FirePass controller administrator.

The FirePass controller logs all activities of a user with administrative privileges in Application Logs. You can find Application Logs on the Reports : App Logs screen.

F5 Networks recommends giving administrative access to separate user accounts rather than sharing a single account, in realms with more than one administrator. That way, you can better track which administrator made a change.

Important

Because superusers have cross-realm access and because they can add other superusers, you should make sure to add only trusted sources as administrators of the Full Access realm.

Adding realm administrators

A superuser must add the first realm administrator. After that, any administrator in the realm can do this, provided they have access to the Device Management : Security : Administrative Realms screen.

By default, the new administrator has access to all features and groups in the realm. Any superuser or realm administrator can restrict access using the features and groups links next to the administrator's name. For more information, see Configuring administrator-specific access , preceding, and procedures in the online help for the Device Management : Security : Administrative Realms screen.

Deleting realm administrators

A superuser and any administrator in the realm can delete a realm administrator, provided they have access to the Device Management : Security : Administrative Realms feature.

Warning

Realm delete occurs immediately, without a confirmation alert, so be sure you are ready to delete an administrator before you click Delete.

Upgrading with administrators configured in versions previous to FirePass 5.4

Versions previous to FirePass 5.4 did not support realms. When you upgrade to versions later than 5.4, the upgrade process creates a realm called Administrators to contain each existing FirePass controller administrator. Each account in the Administrators realm retains the group and feature access assignments you configured in the previous version.

Using reports inside realms

Reports show only realm-specific statistics.




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)