Applies To:

Show Versions Show Versions

Manual Chapter: Managing Users and Configuring Groups
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

The FirePass controller uses groups to authenticate users and enable access to resources, applications, and files. Using multiple groups, you can configure different authentication methods and define different access rules to fit different sets of users. FirePass controller supports two types of groups: master groups, and resource 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 users home screen), and, if you are maintaining users on the FirePass controller, user accounts. Using master groups, you can define sets of users, and to enforce different authentication requirements and security settings for different groups. Each user who connects to the FirePass controller is associated with one master group, and the master group provides the authentication that defines what the user can access.
You can also configure different user experience settings for users in different master groups. For example, you can divide users into two groups: employees who are authenticated against your Active Directory server and can access almost all resources on your intranet, and partners who are authenticated against a RADIUS server and can access only a few resources.
A resource group is a collection of resources, access control lists, and protection criteria, which includes your company intranet servers, applications, and network shares. Using resource groups, you can define sets of resources and control access to these resources discretely.
Each resource in a resource group is represented using a special configuration construct called a favorite. A favorite has all of the information needed for the client computer to connect to an resource.You can define several kinds of favorites:
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 users browser-based home screen. The user can click the link to access the resource.
A master group is associated with one or more resource groups. Once the master group authenticates the user, the user is allowed to access the resources configured for that master group. You can associate a resource group with one or more master groups or with individual users. Using resource groups, you can ensure that only the users who meet the authentication criteria and security settings requirements configured for the master group have access to the resource group. This way, you can restrict access to certain resources based on which master group a user belongs to.
Fundamentally, master groups deal with authentication of users who want access, while resource groups deal with the functionality and locations that users can access. Figure 2.1, following, illustrates the relationship between master groups, resource groups, and favorites categories.
When determining the user-management structure of master groups, you have a choice between managing users externally or internally.
Manage users externally on your corporate servers
This is the recommended method. Using this method, you keep your users information on an external server. The FirePass controller retrieves the users group information from the external server at logon time. The FirePass controller supports the following methods for externally managing users:
Windows® Domain server
RSA SecurID® technology
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, you must manage users internally on the FirePass controller.
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 that have large numbers of users and failover configured, since in such cases synchronizing the user database can reduce performance. Finally, although the FirePass controller has limited capability to automate user database synchronization (using the master group features signup templates and the LDAP/Active Directory synchronize options), there are no such issues with externally managed users.
When determining the authentication method for users in master groups, you have a choice between external and internal authentication.
External authentication
Authenticates users with information retrieved from an external source. You can elect to authenticate users from an external server whether you manage the users internally on the FirePass controller, or externally on your network server.
Internal authentication
Authenticates users with information from local user accounts. You cannot configure internal authentication for externally managed users.
The FirePass controller authenticates a user based on the authentication method configured for that users master group. The FirePass controller supports the following authentication methods:
Specified settings from a client certificate: Organization (O), Organization Unit (OU), or a string match against the Distinguished Name (DN).
RSA SecurID® technology
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 can result in extensive administrative requirements. See Understanding user account management options.
Import users from an Active Directory or Windows domain server
In some environments, the administrator might prefer to add users to the FirePass controller, but already has an Active Directory or Windows domain server structure in place. In this case, you can use your existing user base as an import source for FirePass controller master groups.
Import users from an LDAP server
Similarly, in an environment that has an LDAP server structure in place, administrators can use their existing user base as an import source for FirePass controller master groups.
Import users from a text file
In cases where there is no existing server structure, you can populate the internal FirePass controller database with user accounts from a text file. 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 external users to the local database. See Using signup templates to add user accounts.
All of these methods create user accounts in the FirePass controller internal database. For specific procedures for each of these operations, see the online help,
You can use existing user accounts that you have defined on an external server in your own network environment to authenticate FirePass controller users. External user management is the recommended user-management method. The advantage of using an external data store is that you can use the same server to authenticate FirePass controller users as you use to authenticate your local network users. Using an external data store for authentication greatly reduces the administrative effort needed to maintain user accounts on the FirePass controller, as well as on your internal network servers. In addition, using an external data store for authentication improves FirePass controller performance because user accounts are not maintained on the FirePass controller.
Tip: If you already have an authentication mechanism in place (for example, you are using the Active Directory service), you can use that mechanism to manage users of the FirePass controller. Using external user authentication reduces administration time, and is the simplest client-authentication method.
For example, if your network uses the Active Directory service, you can configure the FirePass controller to map to that structure. In this case, the FirePass controller queries the directory to get user information, and uses the results to associate each user with a master group as they log on.
1.
In the navigation pane, click Users, expand Groups, and click Master Groups.
The Master Groups screen opens.
2.
Click the Create new group button.
The Group Management screen opens.
3.
In New group name, specify a name for the group.
4.
From the Users in group list, select External.
5.
From the Authentication method list, select the authentication method you want to use.
You cannot select Internal database or Initial signup on LDAP with Subsequence Strong Internal Password as the authentication method for master groups of external users.
6.
Click the Create button.
The master group configuration screen opens with the General tab selected.
7.
To use dynamic group mapping in master groups, check Allow users to be assigned to this master group using dynamic master group mapping.
If you do not enable this option, the FirePass controller gives the user access to the master group only if the master group is in the list of fallback groups, and Determine the user's master group by attempting to authenticate the user in each of the fallback master groups is enabled. To access this option, you must enable the option Determine the users master group dynamically using the master group mapping table on the Dynamic Group Mapping screen.
8.
To use dynamic group mapping in resource groups, enable the option Allow resource groups to be assigned to this master group using dynamic resource group mapping.
If you do not enable this option, the FirePass controller gives the user access only to resource groups that are statically assigned to the user. To access this option, you must enable the option Determine the user's resource group dynamically using the resource group mapping table on the Dynamic Group Mapping screen.
9.
Click the Resource Groups tab, and select the resource groups you want this master group to access.
You can select one or more resource groups and click Add to make them accessible to the master groups users.
10.
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.
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 signup templates.
Managing users internally is not the recommended method. However, there are several circumstances in which you might want to use this method.
Administrators who have no existing user management and authentication source in place might want to use the FirePass controller to manage users.
An administrator might want a single location that lists which users have access to which resources.
This is an easy way to determine who has individual access to various devices.
Some administrators might want to create an administrators-only group that exists only on the FirePass controller.
This might be effective when the external authentication source is not available.
Those administrators who want users to create their own favorites or change personal preferences must maintain users locally.
To configure master groups for local users, follow the same steps as needed for configuring a master group with external users, as described in the procedure To configure master groups for external users.
Note: The FirePass controller has a default master group called Default. You can use this master group without creating any other master groups, or you can create master groups to use instead of, or in addition to, the default group.
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.
Determine the requirements you want for different sets of users.
The FirePass controller uses groups to determine authentication, resource assignment, and many other features. This is the task at which you should determine how much access each set of users has. The guidelines defined in your companys security policy might help you answer some of these questions:
What are your companys authentication requirements? That is, do you use Active Directory, RADIUS, LDAP, or something else? Will you use the companys authentication requirements or develop something else?
For more information, see Choosing an authentication method.
What are the endpoint security procedures and penalties for dealing with information leaks, unauthorized access, and security breaches? For more information, see Creating protected configurations.
Map external groups to internal FirePass controller groups.
For more information, see Setting up dynamic group mapping.
You use group mapping under either of the following circumstances:
You plan to have locally managed users, but you want to control their master group membership dynamically each time they log on to the FirePass controller. For more information, see Managing users in the FirePass controller data store.
You can configure group mapping using any of the following sources.
Windows Domain server (pre-Windows 2000 compatibility)
For more information, see Setting up Windows domain server authentication.
RADIUS server (including RSA SecurID RADIUS)
For more information, see Setting up RADIUS server authentication.
URI landing page
For more information, see Mapping based on landing URI.
Note: Mapping by URI landing page on its own does not verify users. F5 Networks recommends mapping using external groups instead.
Add user accounts directly to the FirePass controller database.
If you plan to manage users internally, you can add them manually by creating accounts individually, by importing them into the database, or by adding them automatically using the signup-by-template feature.
For more information, see Managing users in the FirePass controller data store, and Using signup templates to add user accounts.
Set up server certificates specifically for your site.
If you plan to use client certificate authentication, set up server certificates specifically for your site, and set up client certificates to validate clients.
For more information, see Managing certificates on the FirePass controller.
Install a client root certificate and certificate revocation list (CRL).
If you plan to configure the FirePass controller to validate client certificates installed on each users computer, you can use client certificates for authentication and to control access to specific resources. For more information on setting up server and client certificates, see Managing certificates on the FirePass controller.
After creating a master group, your next task is to configure the group. You use the Master Groups screen for this task. 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 the options on each tab, see the online help for the Master Groups screen.
General
Presents options that govern how to assign users and resources to the master group.
Authentication
Presents options for the authentication method the group requires.
Resource Groups
Presents options for assigning resource groups to master groups.
Signup Templates
Presents options for automatically adding users to external groups.
User Experience
Presents options that govern the appearance of the users 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.
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.
Group Name
Lists the name of each group. You can click a group name to open its Master Group configuration screen containing options such as how users and resources are assigned to the group.
Authentication
Lists the type of authentication the group uses. You can click the authentication method to open the Master Group configuration screen containing options such as authentication-specific settings (Authentication tab).
Resource Groups
Lists the number of resource groups assigned to the master group, and whether dynamic resource assignment is enabled. You can click an entry to open the Master Group configuration screen containing options for adding or removing resource groups for the associated master group.
Signup Template
Shows whether signup templates are enabled (options are: N/A, No, and Yes). The N/A entry indicates master groups of externally managed users. You can click a No or Yes entry to open the Master Group configuration screen containing options such as whether to allow automatic sign-up by template and others.
Note: You can specify signup template as an optional parameter only for master groups of externally managed users.
Max concurrent sessions
Contains the number representing the maximum number of sessions configured for that master group. The default varies depending on the number of licenses you have for the FirePass controller. You can specify a different number on the General tab by clicking the associated link, checking Limit the number of concurrent sessions for this group, and specifying the number you want. In no case can you specify a number greater than the number of licenses you have.
Users
Contains an indication of whether the groups 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.
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
To access the Master Groups list screen, click Users, expand Groups, and click Dynamic Group Mapping. The Master Groups list screen is where you accomplish all of the tasks described in this section.
Create a new master group
You can create a new master group by clicking the Create new group button at the upper right.
Configure a master group
You can configure a master group by clicking the group name, or by clicking any link in the following columns: Authentication, Resource Groups, Signup Template, Max concurrent sessions, Users, or Routing Table.
View the groups 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 groups 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 users password and any other user information requested on the User Management screen.
Mapping external groups to FirePass controller groups.
You can map your external groups to the FirePass controllers master groups.
Importing users from external sources.
You can import users from the following sources:
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).
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.
If you use an external server to authenticate users, you can configure a signup template to automatically add users to the group when they log in to the FirePass controller for the first time. The FirePass controller displays a form where first-time users type their user name, password, and other information.
1.
In the navigation pane, click Users, expand Groups, and click Master Groups.
The Master group list screen opens.
2.
Click one of the existing master group names, or click Create new group to create a new master group.
3.
Click the Signup Templates tab, and check Allow Authenticated Signup by Template.
You can also check Bypass signup by template form and enter user information later to allow the user to log on using only the user name and password. That is, the FirePass controller does not present a signup template to users, but adds users to the group. Using this option, you can specify content for the user account at any time after creation.
Tip: You can switch to a different master group by selecting the group from the Master Group list at the upper left of any Master Group configuration screen. This is an easy way to change the master group you are configuring.
If you also use group mapping, the FirePass controller retrieves the users 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.
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.
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 users 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 users current group information and dynamically associates it with a master group or resource groups.
Note: We recommend that you optimize your mapping table using the fewest number of mappings to accomplish what you want. The trade-off is performance-based. Because the FirePass controller retrieves group mapping information at logon time for every user, a large number of groups and mappings might slow logon times.
The FirePass controller dynamic group mapping feature provides support for several types of mapping operations. You can find a general example as well as specific procedures for each of the group mapping methods.
During dynamic master group mapping, the FirePass controller queries the external group mapping servers, and matches the value of the external groups with the entries in the master group mapping table. If a user matches more than one entry in the master group mapping table, the FirePass controller uses the first match it encounters. If the mapping succeeds, then the FirePass controller authenticates the user by the authentication methods configured for that master group.
The FirePass controller goes through a series of activities when it uses master group mapping to determine to which master group a user belongs. Then the FirePass controller authenticates the user by whatever authentication method is configured for that master group. The FirePass controller steps through the master group mapping process in the following order.
First, the FirePass controller queries any external servers that are configured with mapping methods and attempts to match the user to a master group based on entries in the master mapping table. For example, if LDAP is the configured mapping method, the FirePass controller sends a query to the LDAP server to gather the information requested.
Next, the FirePass controller compares the results of the query with each entry you have specified in the master group mapping table, looking for a match. At this point, if the system has not identified a master group, the FirePass controller searches its internal database to determine the users master group information.
When the FirePass controller finds a match, it associates the user with the master group and prepares for authentication. If a single user matches more than one master group, as determined by entries in the master mapping table, the FirePass controller uses the first match it encounters. You can set the order in which the FirePass controller should perform group mapping operations by specifying the mappings priority number in the master group mapping table.
Figure 2.2 illustrates the dynamic master group mapping process. You can find sample mapping procedures in Specifying a group mapping method.
The Dynamic Group Mapping screen contains text that describes the process illustrated in Figure 2.2. To access the Dynamic Group Mapping screen, in the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
During dynamic resource group mapping, the FirePass controller queries the external group mapping servers and matches the value of the external groups against the entries in the resource group mapping table. The user gets an association for each resource mapping table entry whose resource group configuration matches. When the FirePass controller finds a match, it provides the user access to the resource groups associated with the mapped entries. The FirePass controller then permits the user access to all resources in all resource groups returned by any of the configured methods, and presents the resources as favorites on the users webtop. If dynamic resource group mapping fails, the following actions occur:
If the user belongs to a group whose users are maintained externally, the FirePass controller does not provide the user access to the resource.
If the user belongs to a group whose users are maintained in a FirePass controller resource group, the FirePass controller provides the user access to only those resource groups that are statically assigned to the master group and individually assigned to the user.
When you enable dynamic resource group mapping, and the user logs on to the FirePass controller, the FirePass controller completes the following sequence of events to map a user to available resources:
First, the FirePass controller attempts to use dynamic resource group mapping to determine which resource groups are assigned to the user. If the system finds assigned resource groups, the FirePass controller presents to the user the resources from those groups.
Next, the FirePass controller attempts to determine which resource groups are statically assigned to a users master group. If the system finds resource groups, the FirePass controller allows the user access to the resources associated with that master group.
The FirePass controller then attempts to determine which static resource groups are statically assigned to the user. If the system finds resource groups, the FirePass controller permits the user access to those statically assigned resources as well.
Figure 2.2 illustrates the dynamic master group mapping process. You can find sample mapping procedures in Specifying a group mapping method.
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 method 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 method, 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.
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.
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 users 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.
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.
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 Joes group from Staff to Managers on your corporate policy server.
The next time Joe tries to log on, the FirePass controller retrieves the group value managers from your corporate policy server. Based on the configured dynamic resource group mapping entries, the FirePass controller maps the value managers to the FirePass controller Managers resource group, and gives Joe access to all of the resources available to the Managers resource group.
This example shows that dynamic resource group mapping allows you to keep your group-based or role-based policies on your corporate policy server. You can then configure the FirePass controller to apply these policies dynamically when the user logs on. If a policy changes, you do not have to reconfigure the FirePass controller, you can just move the user to a different group on your corporate server. Because you have defined the mapping entries, the FirePass controller automatically provides access correctly, based on the users changing role.
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 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.
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.
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.
For master groups, select the option Allow users to be assigned to this master group using dynamic master group mapping.
Selecting this option uses settings on the master group mapping table to map users to master groups.
For resource groups, select the option Allow resource groups to be assigned to this master group using dynamic resource group mapping.
Selecting this option uses settings on the resource group mapping table to map users to resource groups.
4.
Click the Update button.
Since most users belong to several groups in a network structure, using fallback groups can help direct the FirePass controller to identify a user as part of a specific master group. In this case, if the FirePass controller cannot identify the user as part of the first master group in the mapping, it tries the master groups listed in the fallback master group list, in the order the group appears in the list.
By default, the FirePass controller adds newly created master groups to the list of fallback master groups. You can add and remove master groups, and you can rearrange the order of master groups in the list. Specifying fallback master groups is part of configuring for dynamic group mapping.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Dynamic Group Mapping screen opens.
2.
Check the box following Step 3, Determine the user's master group by attempting to authenticate the user in each of the fallback master groups.
3.
In the Available master groups list, select any master groups you want to affect.
You can use the Shift and Ctrl keys to add items to your selection.
4.
To add a master group as a fallback master group, click Add.
The selected group or groups appear in the Fallback master groups list.
5.
In the Fallback master groups list, select any master groups you want to affect.
You can use the Shift and Ctrl keys to add items to your selection.
To prevent the FirePass controller from using the master group selected as fallback master group, click Remove.
To position the selected master group so that the FirePass controller uses it earlier in the dynamic group mapping process, click Move Up.
To position the selected master group so that the FirePass controller uses it later in the dynamic group mapping process, click Move Down.
Once you enable dynamic group mapping, you can proceed to select the mapping method you plan to use (see Specifying a group mapping method), configure the request for user information (see To configure dynamic group mapping, following), and add entries to the master group mapping table and the resource group mapping table (see the section relating to the type of mapping you are configuring). When you complete these tasks, the FirePass controller can perform dynamic group mapping.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select the method you want, and click Add mapping method.
The new method is added to the list. If the method is already added, it is not present in the list. For more information, see Specifying a group mapping method.
7.
Click the Request configuration tab.
The Request configuration screen opens.
8.
From the Select method to configure request list, select the method you plan to use for group mapping, and then click Switch.
The screen refreshes to reveal options that are relevant to the method you selected.
9.
Configure the settings that reflect your external group and network structure, and then click the Update button.
You must configure settings so that the FirePass controller can send the request for user information to the appropriate server on your network. For more information, see Completing group mapping configuration.
10.
Click the Master mapping table tab.
The Master mapping table screen opens.
11.
From the Mapping Method list, select the type of mapping table entry you want to create, and click Add.
The master mapping table screen opens for the mapping method you added.
12.
Specify the mappings you want, and then click Add.
The Master mapping table screen opens, showing the mapping you added.
This is where you add master mapping entries. For more information, see the section that describes configuring mappings based on the method you are using. For example, if you are mapping using the LDAP (user object) method, see To add the LDAP user object mapping method.
13.
Click the Resource mapping table tab.
The Resource mapping table screen opens.
14.
From Mapping Method, select the type of mapping table you want to create, and then click Add.
The Resource mapping table screen opens for the mapping method you added.
15.
Specify the mappings you want, and then click Add.
The Resource mapping table screen opens, showing the mapping you added.
This is where you add resource mapping entries. For more information, see the section that describes mappings based on the method you are using.
You can define how the FirePass controller gets authentication information from the associated server by specifying options and choosing settings when configuring the mapping method.
The options and settings you configure depend on your external network setup. The FirePass controller supports the following types of group mapping configurations:
When you add a Windows Domain or Active Directory mapping, or any of the three LDAP-based mappings, the system provides a link for configuring the mapping method. You can read more about configuring mapping methods in the procedure for each mapping type.
Note: A groups authentication method and group mapping type do not have to match, although they can and probably do.
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 the FirePass controller master groups. Use the Active Directory method with Windows 2000 and later domain controllers. Use the Windows domain controllers method against pre-Windows 2000 servers, or when you have a mix of Windows platforms in your environment.
Within an Active Directory or Windows domain, there are usually a number of groups defined, with users belonging to one or more of these groups. You can map existing master and resource groups directly to these Active Directory or Windows domain groups. When a user attempts to log on to the FirePass controller, the domain queries your external Active Directory or Windows domain groups to determine what groups contain the user. The FirePass controller looks for matches in its dynamic group mapping framework. When it finds a match, the FirePass controller authenticates the user and allows access to the appropriate resources.
When mapping a user to one or more resource groups, the FirePass controller attempts to match all domain groups against the configured resource group mapping, and the user is assigned one or more resource groups based on any matches.
If you use Active Directory for your user database, you can configure the FirePass controller to map users based on Active Directory groups.
Configuring Active Directory-based mapping involves three procedures: adding the Active Directory mapping method, mapping the Active Directory to the FirePass controller master groups in the master group mapping table, and mapping the Active Directory to the FirePass controller resource groups in the resource group mapping table.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select Active Directory, and click Add mapping method.
The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Active Directory item.
7.
Click the Configure link to the right of the entry in the Mapping methods table.
The Mapping methods configuration screen opens.
8.
In Domain name, type the domain name for the Active Directory to use for mapping users.
You must use the Fully Qualified Domain Name (FQDN) in Domain name. Domain name is a required parameter.
9.
In Kerberos server name, type the Kerberos server name or IP address.
Kerberos server name is an optional parameter.
10.
In WINS server IP address, type the WINS server IP address.
WINS server IP address is an optional parameter.
11.
In Domain admin name and Domain admin password, type a user name and password that has Active Directory administrative permissions.
Domain admin name and Domain admin password are required parameters.
12.
To use a second Active Directory server, check Use a secondary AD server.
The screen changes to reveal additional options.
13.
In Kerberos server name, type the Kerberos server name or IP address.
14.
In WINS server IP address, type the WINS server IP address.
15.
To use a third Active Directory server, check Use a tertiary AD server.
The screen changes to reveal additional options.
16.
In Kerberos server name, type the Kerberos server name or IP address.
17.
In WINS server IP address, type the WINS server IP address.
18.
To limit Active Directory group mapping to the users primary domain, check Only use Active Directory primary group for mapping.
19.
To configure options for synchronizing the FirePass controller database with the external Active Directory, check Synchronize FirePass user database with Active Directory.
The screen changes to reveal additional options.
From the Action list, select an option:
Deactivate FirePass account if user is not in Active Directory or
Delete FirePass account if user is not in Active Directory
Check Notify by e-mail to have the system inform the user of the deactivation or deletion operation.
In Check interval, specify the number of minutes to wait between synchronization operations.
20.
To update user information in internal FirePass controller database records, check Update user information from Active Directory.
Check Map first name to update the first name.
Check Map last name to update the last name.
Check Map e-mail to update the e-mail address.
Check Allow user to edit personal information obtained from Active Directory to allow the user edit access to Active Directory information.
21.
Click Update to save your settings.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping Methods list, select Active Directory, and click Add.
Note: If there is no Active Directory item, click the Group mapping methods tab, and add the Active Directory mapping method first.
5.
Click Add to save your mappings.
Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping. See To add the Active Directory mapping method, and To configure the Active Directory mapping table, preceding.
Note: Instead of specifying each Active Directory group individually, you can have the system retrieve the external groups, but this method is recommended if you have fewer than several hundred groups.
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 PDCs netlogon share using the users credentials, to determine whether the user has a valid account within the domain.
If you use Windows domain for your user database, you can configure the FirePass controller to map users based on Windows domain groups.
Configuring Windows domain-based mapping involves three procedures: adding the Windows domain mapping method, mapping the Windows domain groups to FirePass controller master groups in the master group mapping table, and mapping the Windows domain groups to FirePass controller resource groups in the resource group mapping table.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select Windows Domain, and click Add mapping method.
The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Windows Domain item.
7.
Click the Configure link to the right of the entry in the Mapping methods table.
The Mapping methods configuration screen opens.
8.
In Domain name, type the domain name for the Windows domain to use for mapping users.
You must use the Fully Qualified Domain Name (FQDN) in Domain name. Domain name is a required parameter.
9.
In PDC server name, type the name of the Primary Domain Controller (PDC).
PDC server name is an optional parameter.
10.
In WINS server IP address, type the WINS server IP address.
WINS server IP address is an optional parameter.
11.
To have the FirePass controller join the Windows domain, check Join Windows domain.
The screen changes to reveal additional options.
12.
In Domain admin name and Domain admin password, type a user name and password that has Windows domain administrative permissions.
Domain admin name and Domain admin password are required parameters.
13.
Click Update to save your settings.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping Methods list, select Windows Domain, and click Add.
Note: If there is no Windows Domain item, click the Group mapping methods tab, and add the Windows Domain mapping method first.
3.
5.
Click Add to save your mappings.
Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping. See To add the Windows domain mapping method, and To configure the Windows domain mapping table, preceding.
Note: Instead of specifying each Windows domain group individually, you can have the system retrieve the external groups, but this method is recommended if you have fewer than several hundred groups.
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 users group membership, and automatically associate the user to the mapped master and resource groups on the FirePass controller.
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.
If you have LDAP configurations that use a specific attribute as the unique identifier for the user, you can configure group mapping based on that attribute. For example, if your LDAP server uses an LDAP attribute called userPrincipalName, you could specify that when you configure the request.
Configuring LDAP user object-based mapping involves three procedures: adding the LDAP user object mapping method, mapping the LDAP user object to a FirePass controller master group in the master group mapping table, and mapping the LDAP user object to a FirePass controller resource group in the resource group mapping table.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select LDAP (user object), and click Add mapping method.
The new method is added to the table. If the table already contains a mapping method of this type, the list contains no LDAP (user object) item.
7.
Click the Configure link to the right of the entry in the Mapping methods table.
The Mapping methods configuration screen opens.
8.
In the LDAP server box, specify the user distinguished name (DN). For example:
CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
9.
In the Query LDAP user object area, select the method you want the FirePass controller to use to query the external LDAP server.
If you select the Get user DN using template option, click Update, and type the users entry in Template. For example,
cn=%logon%,dc=eng,dc=net,dc=com
If you select the Get user DN using query option, click Update, and specify the base DN in Search Base DN. For example: CN=Users,dc=eng,dc=net,dc=com
And specify the search string in Query template. For example:
&(sAMAccountName=%logon%)
You can use %logon% in the template to have the FirePass controller insert the users logon name into the query. For example, if you specify as the template &(objectclass=person)(cn=%logon%), and the users name is "george", at logon time the FirePass controller sends the actual query: &(objectclass=person)(cn=george).
10.
In the Fetch group information from LDAP user object area, define the attributes to use to map the group. For example, memberOf.
You can use multiple attributes, each one on a separate line.
11.
Click Update to save your settings.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping Methods list, select LDAP (user object), and click Add.
Note: If there is no LDAP (user object) item, click the Group mapping methods tab, and add the LDAP mapping method first.
3.
From Attribute, select the attribute you want to map to.
Note: You can instead map the LDAP user attribute directly to a FirePass controller master group name by checking the Map verbatim box. In this case, the group names must match exactly. In this case, the FirePass controller removes the settings in the Attribute value and FirePass Group columns.
5.
From the list in the FirePass group column, select the group you want to map to the users returned by the filter expression.
6.
Click Add to save your mappings.
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 Administrative console to create new groups, or you can use existing groups. Your configuration mechanism must have a group object in your LDAP schema to use for mapping groups. The group should have at least two multi-valued attributes for its members.
Configuring LDAP group object-based mapping involves three procedures: adding the LDAP group object mapping method, mapping the LDAP group object to a FirePass controller master group in the master group mapping table, and mapping the LDAP group object to a FirePass controller resource group in the resource group mapping table.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select LDAP (group object), and click Add mapping method.
The new method is added to the table. If the table already contains a mapping method of this type, the list contains no LDAP (group object) item.
7.
Click the Configure link to the right of the entry in the Mapping methods table.
The Mapping methods configuration screen opens.
8.
In the LDAP server box, specify the user DN. For example,
CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
9.
In the Fetch group information from LDAP group object area, specify the attributes in the appropriate box.
The Static members attribute relates to objects with multi-valued membership attributes such as the attribute that contains the list of the users DNs, for example, groupofNames, groupofUniqueNames.
The Dynamic members attribute determines membership by executing an LDAP URL, for example, groupOfURLs, or an LDAP query that specifies criteria for a groups membership.
Note: There is no group object, as such. That is, the LDAP URL exists only in the application that is using it.
10.
Click Update to save your settings.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping Methods list, select LDAP (group object), and click Add.
Note: If there is no LDAP (group object) item, click the Group mapping methods tab, and add the LDAP mapping method first.
3.
In the LDAP group object DN column, type the group object Distinguished Name (DN) you want to map from the LDAP group to the FirePass controller group.
4.
From FirePass group, select the group you want to map to the specified LDAP group.
5.
Click Add to save your mappings.
Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping. See To add the LDAP group object mapping method, and To configure the LDAP group object master group mapping table, preceding.
If you have discrete groups of users that you have configured with an attribute other than the user attributes and you do not use a group object implementation of LDAP, the LDAP filter option is the option to configure. You can configure the mapping of LDAP groups based on results returned by sending a query containing an LDAP filter.
Within a set of defined Windows domain groups, there are usually logical divisions. For example, you may have a group whose users consist of regular employees and consultants. The type and breadth of access allowed for each division within the group usually varies. For example, you might give regular employees access to internal human resources services, and prevent consultants from having the same access. If your LDAP structure matches this organization, you can accomplish this access division using filters. In this case, you define the filter to map to a specific master group.
Configuring LDAP filter-based mapping involves three procedures: adding the LDAP filter mapping method, mapping the LDAP filter to a FirePass controller master group in the master group mapping table, and mapping the LDAP filter to a FirePass controller resource group in the resource group mapping table.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to use dynamic resource group mapping, check that option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select LDAP (filter), and click Add mapping method.
The new method is added to the table. If the table already contains a mapping method of this type, the list contains no LDAP (filter) item.
7.
Click the Configure link to the right of the entry in the Mapping methods table.
The Mapping methods configuration screen opens.
8.
In the LDAP server box, specify the fully qualified domain name (FQDN) of the LDAP server.
9.
In the LDAP port box, specify the port you want to use.
The default is 389 for an LDAP connection, and 636 for a secure LDAP connection.
10.
In the User DN box, specify the user DN. For example
CN=Administrator,CN=Users,dc=eng,dc=net,dc=com
11.
Click Update to save your settings.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping Methods list, select LDAP (filter), and click Add.
Note: If there is no LDAP (filter) item, click the Group mapping methods tab, and add the LDAP mapping method first.
3.
In the first box in the LDAP filter column, type the filter you want to use to define FirePass controller group membership.
You can use %logon% in the filter expression to have the FirePass controller insert the users logon name into the query. For example, if you specify as the template &(objectclass=person)(cn=%logon%), and the users name is george, at logon time the FirePass controller sends the actual query: &(objectclass=person)(cn=george).
4.
From the list in the FirePass group column, select the FirePass group you want to map to the users that the filter expression returns.
5.
Click Add to save your mappings.
Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping. See To add the LDAP filter mapping method, and To configure the LDAP filter master group mapping table, preceding.
Most Active Directory objects use the cn property as their naming attribute. Some objects, however, use a naming attribute other than cn. For example, a domain controller uses the domainDNS property for the naming attribute, and an organizational unit uses the organizationalUnit property for the naming attribute. To avoid having to use a different naming attribute for different object types, you should use the name property, which contains the relative distinguished name of the object, to search for objects by name.
For example: &(&(objectClass=user)(objectCategory=person))(|(name=Sales*)(name=Marketing*))
For users with client certificates, you can use the Organization (O) or Organizational Unit (OU) attribute from the certificates issuer or subject Distinguished Name (DN) to map the user to a FirePass controller 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:
For this case, you can specify L=MyCity to map MyCity to a particular FirePass controller master or resource group.
Configuring client certificate-based mapping involves three procedures: adding the Client Certificate mapping method, mapping a client certificate attribute to a FirePass controller master group in the master group mapping table, and mapping the client certificate attribute to a FirePass controller resource group in the resource group mapping table.
For client certificates that contain multiple organization unit (OU) attributes in the subject or issuer Distinguished Name (DN), the FirePass controller uses all OU attributes for client certificate dynamic group mapping in the session. Additionally, the FirePass controller creates pre-logon session variables for every OU attribute. For example, session.ssl.cert.ou0, session.ssl.cert.ou1, and so on.
OU attributes are tested in order, from left to right, based on the order of their appearance in the certificate subject or issuer DN field, from left to right in the subject or issuer DN using normal group mapping prioritization. All matches are used to select master group or resource groups.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select Client Certificate, and click Add mapping method.
The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Client Certificate item.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping methods list, select Client Certificate, and then click Add.
The associated Master group mapping table opens.
Note: If there is no Client Certificate item, click the Group mapping methods tab, and add the client certificate mapping method first.
Note: You can also map the users client certificate attribute directly to a FirePass controller master group by checking the box in the Map verbatim column. In this case, the FirePass controller removes the Value and FirePass Group columns. For example, if the box in Map verbatim is checked, and you select Subject Organizational Unit (OU), then the FirePass controller maps all client certificates configured as OU=MyDept to the master group named MyDept.
6.
Click Add to save your mappings.
Next, configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping. See To add the client certificate mapping method, and To configure the client certificate master group mapping table, preceding.
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.
If a match is found with a FirePass controller master group, the user is dynamically moved to the corresponding FirePass controller master group. The FirePass controller then authenticates the user according to the authentication method configured for this dynamically assigned master group.
If a match is found within a FirePass controller resource group, the user is allowed access to its resources after being successfully authenticated in a FirePass controller master group.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen appears.
3.
From the Add mapping method list, select RADIUS and click the Add mapping method button.
4.
Click the Configure link to configure the RADIUS mapping method.
The RADIUS settings screen appears.
5.
In the RADIUS settings area, in the Timeout interval box, type the number of seconds.
6.
In the Retries box, type the number of retry attempts.
7.
In the optional Service Type box, specify a service type.
The FirePass controller uses the Service Type value for the RADIUS attribute Service Type (Attribute Number 6). This value is inserted as the Service Type for all requests the FirePass controller makes to the RADIUS Server. Service Type is an optional setting and the default value for Service Type is Authenticate Only.
8.
In the Primary RADIUS server area, in the Server box, type the Server IP address.
9.
In the UDP Port box, specify the UDP port.
10.
In the Change Shared Secret box, specify the shared secret.
11.
In the Group Information box, specify the attributes you want to search for, and specify whether the attributes apply to a Single Group or Multiple Groups. You can also create and test a regular expression to gather the attributes you want.
12.
If you wish, select the Use a backup RADIUS server check box and enter the associated server, port, and shared secret information to configure the backup RADIUS server.
13.
If you wish, select the Use a tertiary RADIUS server check box and enter the associated server, port, and shared secret information to configure a tertiary RADIUS server.
14.
Click Update to save your configuration.
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, which the administrator maps to a FirePass controller group. The FirePass controller then parses the return value to retrieve the external group information in various formats. Options in the Group Information section enable an administrator to specify any of the RADIUS attributes to extract the external group information.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
2.
Click the Group mapping methods tab.
The Mapping Methods screen opens.
3.
Next to RADIUS, click the Configure link to configure the RADIUS mapping method.
The RADIUS settings screen opens.
4.
To extract external group information, in the Radius attribute box, type the IETF-assigned attribute number for the RADIUS attribute. For example, type 25 for the Class attribute, 26 for the Vendor Specific attribute (Vendor code for FirePass is 12276), or 11 for the Filter-id attribute.
5.
Under Attribute contains, several options are available. Select the option that best fits your configuration:
Single group. Select this option to extract single group information from the RADIUS attribute. In this case, the FirePass controller extracts external group information from the attribute value when the attribute does not contain KEY values.
Single group. Format: KEY=VALUE1: Select this option to extract group information from one RADIUS group. In this case, the FirePass controller parses the value of selected RADIUS attribute as KEY=VALUE; and considers VALUE as the external group.
Multiple groups. Format: KEY=VALUE1;KEY=VALUE2;: Select this option to extract group information from multiple RADIUS groups that are formatted in RADIUS as Group1=eng;Group2=sales;Group3=acct, and so on.
In the Delimiter box, you can specify a delimiter other than the default semi-colon ( ; ) to separate RADIUS attribute values.
Multiple groups. Format: KEY=VALUE1;VALUE2;: Select this option to extract group information from multiple RADIUS groups that are formatted in RADIUS as Groups=eng;sales;acct, and so on.
In the Delimiter box, you can specify a delimiter other than the default semi-colon ( ; ) to separate RADIUS attribute values.
Multiple groups,use regular expression to extract groups: Select this option to extract group information from multiple RADIUS groups using the Perl-style regular expression you specify.
For example, if you have the value Group1;Group2;Group3; in attribute 11, type 11 in RADIUS attribute and type /(.*)/ as the regular expression.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
2.
Click the Group mapping methods tab.
The Mapping Methods screen opens.
3.
Next to RADIUS, click the Configure link to configure the RADIUS mapping method.
The RADIUS settings screen opens.
4.
Click the Test regular expression link.
The test screen opens.
5.
In the Regular expression box, type the string you want to test.
6.
Click the Test button.
7.
When the results are what you want, click the Finish button to return to the Group Information section.
A URI is a Uniform Resource Identifier. In the FirePass controller context, URI means the fully-qualified domain name, followed by /<uri-specific_path>. For URI-based customization, URIs are defined inside of the FirePass controller. You can create customized FirePass controller screens for different URIs. By configuring URI-based customization, you can present a different look and feel depending on the URI the user specifies when logging on. This is similar to mapping based on virtual hosts.
Important: You cannot simultaneously use virtual-host based dynamic group mapping and landing URI-based dynamic group mapping.
From a user standpoint, URI-based customization is maintained by a cookie. Once a user establishes a session using a URI that gets customized, then all subsequent FirePass controller sessions started in that browser use the same customization, even if the user specifies the domain name alone (for example, www.siterequest.com), or the domain name qualified by a redirect site (for example, www.siterequest.com/my.logon.php3). To end URI customization, the user must start a new browser session.
If you configure URI-based customization, you can use it as a basis for the group mapping. In URI-based mapping, you map a customized URI to a specific master group. Using URI-based mapping, you can map users to different master groups or assign them to different resource groups based on the landing URI used by the users to log on to the FirePass controller.
For example, a FirePass controller might have two landing URIs configured: outlook and CRM. To support URI-based master group mapping, the administrator creates two mappings in the Master group mapping table. To support URI-based resource group mapping, the administrator creates two mappings in the Resource group mapping table. Users who log on to www.sitrerequest.com/outlook receive access to one set of master and resource groups, which includes access to outlook. Users who log on to www.siterequest.com/crm receive another set of master and resource groups, which includes access to CRM.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check that option in the Resource Groups Mapping Sequence area.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the list, select Landing URI, and click Add mapping method.
The Landing URI method is added to the table. Landing URI is not an available selection in the list if this mapping method has already been added.
1.
On the Group mapping methods screen, click the link Click to configure landing URIs.
The Device Management : Customization screen opens with the URI-based Customization tab active.
2.
In the Create Landing URI box, type the URI you want to map.
The URI you specify must be alphanumeric and cannot contain spaces. Type only the portion of the URI that follows the domain name in the URL. For example, to create a URI consisting of www.siterequest.com/partners, type partners in the box.
3.
Click Apply.
The Configuring URIs screen opens.
4.
Select and specify the settings you want, and click the Update button corresponding to each configuration change that you make.
5.
When you have finished, click the link Back to Users : Groups : Dynamic Group Mapping page.
The Dynamic Group Mapping screen opens with the Group mapping methods tab active.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping Methods list, select Landing URI, and click Add.
Note: If there is no Landing URI item, click the Group mapping methods tab, and add the Landing URI mapping method first.
4.
Click Add to save your mappings.
Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping. See To add the landing URI mapping method, To specify the landing URI, preceding, and To map the URI to a FirePass controller group, preceding.
In the FirePass controller context, a virtual host means the domain name or IP address that users specify when logging on to a web service you create on a virtual IP address. When you want to organize users based on the virtual host they are requesting, you can use virtual host information to dynamically map users to a master group or resource group.
You can create customized screens for different virtual servers. By configuring virtual host-based customization, you can present a different look and feel depending on the virtual host address the user specifies when logging on. This is similar to URI-based mapping.
Important: You cannot simultaneously use virtual-host based dynamic group mapping and landing URI-based dynamic group mapping.
An additional IP address that resolves to the FirePass controller, plus a user web service within the FirePass controller, configured on that IP address
For virtual servers, you can define one customization for a single IP address. URI-based customization takes precedence over virtual host customization. Virtual host customization takes precedence over the default, global customization.
Configuring virtual host-based mapping involves three tasks: adding the Virtual Host mapping method, mapping the virtual host to a FirePass controller master group in the master group mapping table, and mapping the URI to a FirePass controller resource group in the resource group mapping table.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check that option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select Virtual Host, and click Add mapping method.
The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Virtual Host item.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping Methods list, select Virtual Host, and click Add.
Note: If there is no Virtual Host item, click the Group mapping methods tab, and add the Virtual Host mapping method first.
4.
Click Add to save your mappings.
Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping. See To add the virtual host mapping method, and To map the virtual host to a FirePass controller group, preceding.
Creating dynamic group mapping with session variables is particularly useful for mapping based on user information. You can use the following types of the session variables for dynamic group mapping:
Session variables defined by attributes received from external Active Directory and LDAP servers during dynamic group mapping. The system converts these attributes to session variables.
Because some session variables are defined after the FirePass controller performs group mapping, you cannot use them. These include the following types of session variables:
Session variables defined by attributes received from external Active Directory and LDAP servers during the user-authentication process
Configuring session variable-based mapping involves three tasks: adding the Session Variable mapping method, mapping the session variable to a FirePass controller group in the master group mapping table, and mapping the session variable to a FirePass controller resource group in the resource group mapping table.
1.
In the navigation pane, click Users, expand Groups, and click Dynamic Group Mapping.
The Group mapping sequence screen opens.
3.
If you plan to have fallback groups for mapping users, in the Step 3 area of the screen, add and order master groups to the Fallback master groups list.
4.
If you plan to have dynamic resource group mapping, check the option in the Resource Groups Mapping Sequence section.
5.
Click the Group mapping methods tab.
The Group mapping methods screen opens.
6.
From the mapping methods list, select Session Variable, and click Add mapping method.
The new method is added to the table. If the table already contains a mapping method of this type, the list contains no Session Variable item.
1.
Click the Master group mapping table tab.
The Master group mapping table screen opens.
2.
From the Mapping Methods list, select Session Variable, and click Add.
Note: If there is no Session Variable item, click the Group mapping methods tab, and add the Session Variable mapping method first.
3.
In the Session variable column, define the session variable you want to map to, making sure to enclose the session variable within percent ( % ) characters.
Note: You can instead map the Session Variable value directly to a FirePass controller master group name by checking the Map verbatim box. In this case, the FirePass controller removes the settings in the Value and FirePass Group columns.
6.
Click Add to save your mappings.
Configure resource group mapping. You configure resource group mapping on the Resource group mapping tab using the same procedures you followed to configure master group mapping. See To add the Session Variable mapping method, and To map the session variable to a FirePass controller group, preceding.
Session variables can include storage of all RADIUS attributes, so that only a single RADIUS request is made during authentication, and stored attributes are efficiently reused for group resource mapping against the same RADIUS server. To use this feature, from the FirePass Administrative Console, click Users, click Session Variables, and click Add New Session Variable.
In network environments that use multiple authentication realms, some of them require an additional domain password. Associating each realm (master group) with a particular landing URI allows selective display of an additional domain password prompt.
Logon customization provides an extra domain password option for landing URI or virtual host configurations, and a custom domain password prompt for each landing URI or virtual host.
To configure this feature on the Global Settings screen, in the navigation pane click Users and click Global Settings. Select the options for the landing URI or virtual host in the Additional Domain Password area.
From the For Landing URI or Virtual Host list, you can select the URI or virtual host to configure. The list contains all the configured landing URIs and virtual hosts, and the default URI value (which applies when no landing URI or virtual host is selected during the logon process). To appear on the list, a landing URI must first be created on the Device Management : Customization screen, with the option Virtual Host must have host based customization enabled.
Select Use extra domain password for single sign on to enable the password for the selected URI or virtual host. When this option is disabled, no other options appear in this section.
Select Cache the password between sessions to enable the password to be cached between settings. This option appears only if the option Use extra domain password for single sign on is selected.
In the Extra domain password prompt box, type the password prompt for the extra domain password. For example, type Domain Password? This option appears only if the option Use extra domain password for single sign on is selected.
Note: When an administrator upgrades the FirePass controller from a previous FirePass software version that has only global options available, the new FirePass software copies those global options into all the landing URIs and virtual hosts, including those that were deleted or disabled. After the upgrade, an administrator can enable or disable and change the prompt for each URI or virtual host individually.
For example, when a user logs on to https://vhost/uri, the FirePass controller uses the URI settings.
Tip: If the administrator does not specify an extra domain password, the logon screen displays the domain password prompt.
When a user fails to authenticate during logon through any URI or virtual host, the FirePass controller returns the user to the initial Landing URI or virtual host logon screen.
On the Master Group authentication tab, the screen displays the Verify domain password against Active Directory server option only when Extra domain password is enabled for the default URI, or another enabled landing URI or virtual host.
When a user accesses the logon screen without the domain password prompt and is mapped to a group where verification of that password is required, authentication fails. This also happens when domain password is disabled everywhere, but a group has the Verification option enabled. In this case, you can find the reason for the authentication failure in the Logon Report details.
For logon screen customization on a per URI/VHOST basis, the configuration setting is stored in the file
where $subdir is either the landing URI name or the virtual host IP address. Default URI settings are stored in the file
You can specify global settings for certain user options. You can find these global options on the Users : Global Settings screen.
Allow to login with e-mail address as substitute of user name
Indicates that the system accepts an email address instead of a user name. This is useful when your existing infrastructure relies on email addresses as the primary user identifier.
Treat users logon name as case-sensitive
This option applies to users who are configured in the local FirePass database. When the FirePass controller performs external authentication or dynamic group mapping based on external servers, the FirePass controller sends the user names to the servers in the exact case that is stored in the local user database. When the option Treat users logon name as case-sensitive is enabled, the FirePass controller sends user names to external servers in the case in which they are entered by the user on the logon screen.
This case-sensitive option has no effect on External users because the FirePass controller does not store their user names in the local database; external user names are always sent to external servers in the case entered by the user on the logon screen.
Display extra input field at logon for user defined session variable
On the logon screen, presents the user with a box in which to type text. This value is then converted to a session variable named %session.userdef.logon_extra_field%. You can specify a label to help the user know what to type in the box.
For example, you can map users to different master groups by specifying the label Type your master group name in the following box, and then mapping the session variable %session.userdef.logon_extra_field% to that master group in the master mapping table. For a procedure to guide you through this process, see the online help for the Users : Global Settings screen.
Specifying an additional domain password
Indicates that the system provides a second password prompt on the logon screen. The FirePass controller passes the content of this prompt to the functions that enable access to Windows Files, Web Applications, Terminal Servers, and so on. If this option is disabled, the system presents only one password prompt on the logon screen.
In addition to standard credential entry prompts (Username and Password), the FirePass controller logon screen can also display an additional file prompt, and a user-defined session variable prompt (also known as Domain, although the prompt is customizable). One or both of these prompts can be enabled.
In configurations using a primary authentication method for the Password setting, there is also a time-sensitive, token-based, one-time password (OTP) condition, such as RSA or RADIUS. The situation frequently arises where the one time OTP entered by the user expires by the time the user types the domain password, and the domain, if required, and then clicks the logon button. In this case, you can specify a revised order for credentials:
Use the Users : Global Settings screens password option Display password input field last on logon page to change the logon password order.
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 that 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 groups 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.
However, you can also specify the order on the master mapping table, available from the Users : Groups : Dynamic Group Mapping screen. You can set priority on the Master group mapping table screen to change the order of the mappings in the group mapping process.
For virtual host and URI-based customization, you can customize the FirePass controllers screens separately for different virtual servers and different URIs.
A URI is a Universal Resource Indicator. In this context, it means the fully-qualified domain name, followed by /<uriname>. For URI-based customization, URIs are defined inside the FirePass controller.
For virtual servers, you can define one distinct customization for a single IP address. All virtual hosts sharing that IP will also share the same customization.
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 sticky. It is maintained by a cookie. This means that once a user has established a session using URI-based customization, then all subsequent FirePass controller sessions started from within the same browser session use the URI-based customization, even if the user later enters either the domain name alone (for example, www.siterequest.com), or even the domain name qualified by the usual redirect screen (for example, www.siterequest.com/my.logon.php3).
Once the user has established a URI-based custom session, then the user must start a new browser session to switch back to the global customization (or a virtual host-based customization, if there is one). This is by design.
1.
In the navigation pane, click Device Management, and click Customization.
2.
Click the URI-Based Customization tab.
The Landing URIs screen opens.
3.
In the Create Landing URI box, type the name you want to use. This name must be alphanumeric, with no spaces. Type only the portion of the URI that follows the domain name in the URL.
For example, to create the URI www.siterequest.com/partners, type partners in the box.
4.
Click Apply.
1.
In the navigation pane, click Device Management, and click Customization.
2.
Click the URI-Based Customization tab.
The Landing URIs screen appears.
4.
Click the Enable host-based customization check box.
The customization boxes appear.
5.
Click the Update button corresponding to each change you make.
1.
Navigate to the Device Management : Configuration : Network Configuration : Web Services screen and create an HTTP web service.
2.
On the Device Management : Security : User Access Security screen, select the Allow insecure access option.
3.
Navigate to the Device Management : Customization screen, check Allow WebDAV sandbox customization, and type a WebDAV password in the text box that appears.
You access the WebDAV sandbox using HTTP at the URI /sandbox as the user webdav. For example, if you configured the FirePass controller with a HTTP web service at 192.168.0.99, you access the WebDAV sandbox at the URL http://192.168.0.99/sandbox/.
You can place any content in the sandbox directory. The FirePass controller uses specific files to override or supplement stock system behavior.
index.htm: Represents content that appears when a user requests the root URI (/). Typically the user is redirected to /my.logon.php3, to which the customized screen may provide a link.
blocked_popups_warning.htm: This screen presents a warning to a user when a popup window is blocked by the browser. The content should describe how to disable the popup blocker, or allow the popup. For example, Follow your browsers instructions to allow the popup window. To improve the user experience, we recommend that you add the following HTML code:
customfoot.inc: Represents content that serves as the common footer information that appears at the bottom of the user logon screen.
exception.inc: This screen provides a custom error message to a user when a web page is denied, or when a web portal cannot load. You can use the following variables in the exception.inc file:
%F5_MSG_TITLE% - replaces this variable with the title of the error message
%F5_MSG% - replaces this variable with the text of the error message
%F5_URL% - replaces this variable with the URL that caused the error
right.inc: Represents content that appears to the right of the user logon prompt on the logon screen.
links.inc: Represents content that appears immediately below the user logon prompt and replaces the set of default links displayed under the title Need Help.
links.pocket.inc: Represents content that is the same as the links.inc file, but appears for PocketPC clients.
lockoutmsg.inc: Represents content that is displayed to users attempting to log on while the administrator has the Lockout New User Sessions option enabled under the Device Management : Maintenance : User Session Lockout screen.
logon.denied.inc: Directs the user to the logon denied screen when he fails a pre-logon sequence check; for example, the user does not have the required antivirus software or firewall.
logon.failed.inc: Directs the user to a failed logon screen when the user enters incorrect credentials or cannot authenticate on the external server. This screen can contain a logon form that allows the user to log on again.
logout.inc: Represents content that is displayed to users upon log off or session termination.
resetpass.inc: Represents content that appears in response to a click on the Forgot Password? link when the users password is not maintained in the FirePass controller database (for example, on an external LDAP server instead). The presence of the Forgot Password? link is governed by settings in User Password Recovery under Security in the Device Management section.
The FirePass controller maps all content in the sandbox directory to a virtual folder, /sandbox, that the FirePass controller can access from all web services. Content added to the files listed above can reference other files in the sandbox directory. For example, the FirePass controller sandbox directory may store a necessary security download, that may then be referenced from other customized content. For sample implementation text that provides portal access, see Creating a portal access sample screen.
In addition to customizing portal screens, you can present unique content for multiple virtual hosts or URIs by creating corresponding folders containing the custom content you want to use. For example, to customize the password recovery screen for a previously configured landing URI company1, create the file company1/resetpass.inc in the sandbox directory. The presence of a virtual host or URI customization overrides any corresponding global sandbox customization.
Note: To customize virtual hosts, you must create subdirectories of the WebDAV directories named the same as the virtual host's IP addresses.
Customize the user logon page: You can customize the logon screen with several customization files, to provide the FirePass controller users with a richer experience. You can add content to provide instructions for logging in, links to external content, and so on.
Provide a portal page: You can make a customized portal screen using the sandbox that is directly accessible. The system can direct users to a screen containing instructions, external links, JavaScript for launching FirePass controller favorites, and so on.
Provide a default webtop: Users see the webtop screen once they log in, and you can configure this screen in the sandbox. You should reference screens in this manner, using absolute URLs. For example, you can direct users to a screen at https://firepass.company.xyz/sandbox/portal.htm. The content you place on a default webtop screen can offer instructions or an SSL VPN start link (using JavaScript), or automatically start an SSL VPN connection (again using JavaScript). For sample implementation text that provides portal access, see Creating a portal access sample screen.
You should include specific tags when you create the index.htm screen. For example, the FirePass controller detects JavaScript support in a client browser using a POST parameter called tzoffsetmin. If the index does not include this code, the open in new window button in web applications and for the network access screens does not appear.
Vhost input should be specified just once.
uRoamTestCookie should be specified as a form input parameter.
If the parameter uRoamTestCookie is missing in POST, this omission forces the webtop to act as if the client is in cookieless mode. In this mode, the webtop displays the system warnings Your browser has disabled cookies, and the session ID is visible in the browsers URL navigation bar.
You can present your users with a customized portal access screen by providing a file in the /sandbox directory. To read more about the /sandbox directory, Using sandbox files.
1.
Copy the text sample following, including the beginning and ending <html> tags, and paste it into a text editor.
2.
Save it as text-only with .html as the file extension.
3.
Replace NAME_OF_RESOURCE_GROUP with the name of a resource group you have defined.
4.
Replace FAVORITE_NAME with the text you want the user to click.
5.
Replace parameters in the box createDirectAppTunnelConnection with appropriate values.
This sample content may also be hosted on an internal intranet web server. You must then access the screen through Web Applications or set the screen with this content as your Intranet Webtop. It will then be possible to start FirePass controller favorites directly from your Intranet server. It is also possible for you to have the system dynamically insert portions of the following code into intranet screens through use of Web Applications Content Processing Scripts. For example, you could use this capability to dynamically start an App Tunnel to support a difficult intranet ActiveX control which might not normally work through Web Applications.
Use the special tags <FP_DO_NOT_TOUCH> and </FP_DO_NOT_TOUCH>, as shown in the example below, to prevent the FirePass controller Web Applications engine from re-writing the links and JavaScript between the tags. You control the processing of these tags using the option Process content of the FP_DO_NOT_TOUCH element. To view this option, navigate to the Portal Access : Web Applications : Content Processing screen, and select the Global Settings tab. Scroll to the Web Applications Global Settings area.
window.open(url+params,"_blank",dimension+",status=no,toolbar=no,menubar=no,location=no");
'name='+w_name+',resizable=0,scrollbars=0,statusbar=0,menubar=0,width=320,height=240');
var params = "rhost0="+rhost0+"&rport0="+rport0+"&lhost0="+lhost0+"&lport0="+lport0+"&cmd0="+cmd0+"&dont_warn="+dont_warn;
'name='+w_name+',resizable=0,scrollbars=0,statusbar=0,menubar=0,width=320,height=240');
'name='+w_name+',resizable=0,scrollbars=0,statusbar=0,menubar=0,width=320,height=240');
<a href='javascript:createVPNConnection("NAME_OF_RESOURCE_GROUP","FAVORITE_NAME")'>SSL VPN</a>
<a href='javascript:createAppTunnelConnection("NAME_OF_RESOURCE_GROUP","FAVORITE_NAME")'>App Tunnel</a>
<a href='javascript:createTSConnection("NAME_OF_RESOURCE_GROUP","FAVORITE_NAME",false)'>Terminal Services</a>
<a href=/vdesk/intranets/provision.php3?res_group=NAME_OF_RESOURCE_GROUP&res_name=FAVORITE_NAME>Web Applications</a>
<a href='javascript:createDirectAppTunnelConnection("telnetserver.company.xyz", 23, "127.173.191.252", 23, "telnet 127.173.191.252", 1)'>Direct App Tunnel</a>
<frame name="contents" target="main" src="/vdesk/filemanager/directory.php3?dir=%5C%5Ccompany_server%5Cpublic%5C" marginwidth=10 marginheight=10>
Using WebDAV you can customize the error screens that are displayed when a user would normally see an access denied screen through the Portal Access setup for virtual and URI-based hosts.
The file exception.inc can be added using WebDAV.
Before FirePass controller loads the exception.inc screen, it replaces the following variables with the actual strings from the FirePass controller:
The variable %F5_MSG_TITLE% is replaced with the title of the error message.
The variable %F5_MSG% is replaced with the text of the error message.
The variable %F5_URL% is replaced with the referring URL of the error message.
To create a customized error message, you upload a customized version of the file exception.inc to the FirePass controllers WebDAV sandbox. A user who is denied access to a site then sees the customized error screen when the error occurs.
You can enhance the flexibility of user authorization by implementing dynamic resource group mapping on the master group level in the FirePass controller. In addition to global dynamic master and resource group mapping, you can also configure dynamic resource mapping separately for each master group. This configuration is an additional phase that follows authentication and allows you to authorize users against multiple sources of the same type. In this way, each master group can dynamically map resources using its own combination of Active Directory, LDAP, Windows Domain, or RADIUS mapping methods.
You configure Resource Group Mapping from the Users : Groups : Dynamic Group Mapping screen, as shown in Figure 2.4.
You can enable the option Determine the users master groups dynamically using resource group mapping table in users master group to globally enable or disable resource group mapping that is configured individually in the master groups. When this option is disabled, this resource group mapping step is not performed even if it is configured in master groups.
Additionally, on the Users : Groups : Master Groups screen for a selected master group, you can enable the option Allow resource groups to be assigned using dynamic group mapping configured in this master group, as shown in Figure 2.5.
This option allows you to enable or disable resource group mapping configured in this master group. When the global option described in the previous section is disabled, this option is likewise disabled, and cannot be enabled from this screen.
You can use the Mapping methods screen on the Users : Groups : Master Groups screen, on the Mapping methods tab, to access options for adding and configuring dynamic group mapping methods for a selected master group. The same mapping methods are available for master group mapping as are available for global resource mapping. You can assign multiple mapping methods to a master group, although only one method of each type is allowed for each group. For example, you can assign only one Active Directory mapping method to a single group, but you can assign an additional mapping methods, such as Windows Domain, RADIUS, and Client Certificate methods, in addition to the Active Directory method.
After you add mapping methods, you click Configure to display the configuration screen for the selected mapping method. The options available on the configuration screen are method-specific, and consistent with most of the options available from the global group mapping configuration screen. The exceptions are options related to user database synchronization and options related to updating of user information. These options are not available from the Resource group mapping methods screen.
You can select the option Use settings from Active Directory authentication to allow the resource group and the Active Directory authentication method to share configuration settings. You can enable this option to duplicate the settings from the authentication tab, and disable editing. If you enable this option, any previous settings for this mapping method are overwritten when this option is enabled. Any subsequent updates to the Active Directory authentication configuration also updates the related group mapping method settings.
You can access the Resource Group Mapping Table screen on the Users : Groups : Master Groups screen, on the Mapping Table tab. The mapping table provides options for configuring dynamic resource group mapping for a selected master group. This screen provides the same capabilities as the global group mapping table configuration screen.
On the Resource Group Mapping Table screen, you can select and add mapping methods from a list that includes all resource groups that are configured for the selected master group on the Resource Group Mapping Methods screen for the user.
The FirePass controller creates session variables during master group-based dynamic resource group mapping. These session variables are similar to the session variables created during global group mapping based on user record attributes retrieved from Active Directory or LDAP.
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.
You specify an authentication method when you create your master groups. You can also change an authentication method from one type to another. You can select from several structures for maintaining users for authentication.
If you plan to use local authentication using the same method 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 method 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.
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.
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.
FirePass controllers 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, use this method. If you want to use RSA SecurID over its native protocol, use the RSA SecurID method instead. For more information on this method, see Setting up RADIUS server authentication.
LDAP server
Uses the server at your site that supports authentication using LDAP. For more information on this method, see Setting up LDAP server authentication.
Basic HTTP authentication to external server
Uses external, web-based authentication servers such as Oracle® COREid®, eTrust SiteMinder®, and others to validate user logons and passwords, and to control user access to specific network resources. For more information on this method, see Setting up HTTP basic authentication to external server.
Initial signup on LDAP with subsequent strong password
Authenticates first-time users against an LDAP directory, but at the first use also presents a form to require them to entry a strong password. Subsequently, the user is authenticated using the internal FirePass controller database. This method allows you to use strong passwords not supported by your LDAP directory, while providing most of the convenience of LDAP authentication. For more information on this method, see Setting up initial signup on LDAP with subsequent strong internal password.
Windows domain server
Uses the Windows domain server at your site that supports NTLM authentication against a pre-Windows 2000 domain controller. For more information on this method, see Setting up Windows domain server authentication.
Windows Active Directory
Uses the server at your site that supports Kerberos authentication against a Windows 2000 or later server. For more information on this method, see Setting up Active Directory authentication (Kerberos authentication).
HTTP form-based
Integrates with single sign-on systems such as Oracle COREid, and eTrust SiteMinder. For more information on this method, see Setting up HTTP form-based authentication.
Client certificate passwordless
Requires no name or password at logon for users who have the installed client certificate. For more information on this method, see Setting up client-certificate-based authentication.
RSA SecurID
Uses the server at your site that supports RSAs SecurID technology over its native protocol. RSA SecurID represents a two-factor authentication method 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.
The FirePass controller provides support for variables that allow for the real-time setting of a users Single Sign-On (SSO) values in a session. Pre-logon, AD, LDAP, and RADIUS group mapping or authentication variables may be used directly in the FirePass controller administrative console. For example, administrators may perform an LDAP or AD query using dynamic group mapping or authentication, which returns key attributes that can then be configured as variables that override the session's SSO (single-sign-on) user name and password.
In order to use session variables created from external directory attributes, you must configure an appropriate group mapping or authentication method. Entering variables on the screen does not automatically generate a query to external directories.
The FirePass controller determines the user name and password values configured on the User Management screen after a user logs in. These values are assigned to the %username% and %password% variables that you can use when configuring the following resources:
Additionally, you can use the SSO user name and password to log the user on automatically to Terminal Services, App Tunnel file shares, Network Access drive mappings, Web Applications, Windows file shares, and Mobile email corporate accounts. To extend the use of the SSO user name and password, enable the auto logon option in the Master Group settings for the corresponding resource type.
Important: The SSO settings on the User Management screen do not affect the Single Sign On mechanism based on cookies received from an external web server during HTTP Basic or Form-Based authentication methods.
Tip: An SSO password defined on the User Management screen overrides an SSO password configured in a RADIUS authentication method. To use the SSO password configured in a RADIUS authentication method, leave the SSO password and regular expression boxes blank on the User Management screen.
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 methods 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.
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 boxes 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.
The internal authentication method uses an internal database storing FirePass controller user data for name, logon designation, password (stored as cryptographically strong hashes), email address, group name, mail server, and NFS logon and password. Initially, you must assign each user a password. Later, a user can change his password from the webtop.
The FirePass controller can authenticate users 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.
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 are having difficulty authenticating using RSA SecurID over RADIUS, check on the authentication server that is running RSA SecurID server 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 starts, 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 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.
1.
In the navigation pane, click Users, expand Groups, and click Master Groups.
2.
Click the group name of the RADIUS group for which you want to enable SSO.
Alternatively, you can click the Create new group button to create a new group, and select RADIUS from the Authentication method list.
3.
Click the Authentication tab.
The RADIUS Authentication screen opens.
4.
Select the check box Retrieve Single Sign On Password from RADIUS attribute.
A new screen area labeled RADIUS Attribute value and format settings for SSO password appears.
5.
In the RADIUS attribute box, type the IETF-assigned attribute number for the RADIUS attribute to use to extract the SSO password information. For example, type 25 for the Class attribute, 26 for the Vendor Specific attribute, or 11 for the Filter-ID attribute.
6.
For the Attribute contains setting, select one of the following options:
SSO Password. Format: Value. The FirePass controller parses the value of the selected RADIUS attribute and uses Value as the SSO password.
SSO Password. Format: KEY=VALUE. The FirePass controller parses the value of the selected RADIUS attribute as KEY=VALUE and uses VALUE as the SSO password.
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.
If the FirePass controller logon matches the naming attribute that your LDAP directory uses as part of the bind DN, you can look for the users entry directly by configuring the option described in the following procedure.
1.
In the navigation pane, click Users, expand Groups, and then click Master Groups.
The Master Groups screen opens.
2.
In the Authentication column, click the link representing the master group you want to configure.
The screen changes, and you see the authentication screen for the corresponding master group.
3.
In Host, specify the FQDN or the IP address of the LDAP server.
If you use the LDAP authentication over SSL method, be sure that the Host name you specify exactly matches the host name on your LDAP server certificate.
4.
In Port, specify the port on which the LDAP server listens.
The default values are 389, which represents LDAP, and 636, which represents secure LDAP.
5.
From the Protocol version list, select 2, if yours is an LDAPv2 configuration, or 3, if yours is an LDAPv3 configuration.
6.
In User DN Template, type the following string, substituting the appropriate value for YourCo.
cn=%logon%,o=YourCo
During logon, the authentication mechanism substitutes the users 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.
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 controller.
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 lowercase 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 is 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 box 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 is similar to the following string:
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.
FirePass controller provides a two-factor authentication method that requires users to present a valid client certificate, which is then verified against the LDAP database using information extracted from certificate values.
This method supports customers who have client root certificate authority linked to the LDAP database from which certificates are generated based on information stored in those directories.
Note: To use this feature, a client root CA certificate must be installed on the FirePass controller, and you must configure the FirePass controller to extract fields from the client certificate to use in the two-factor authentication process.
To use two-factor authentication, you must first install a client root certificate. Then, you configure a master group with the LDAP authentication method, and then select the option Require client certificate for user logon.
Two-factor authentication is a secondary authentication and it is performed only if primary authentication (specifically, certificate validation against a selected client root CA certificate) is successful. The user record is retrieved from the LDAP database based on the configured settings, and optionally matched against data extracted from the client certificate.
Client certificate subject field used for comparison
Select one of the following choices. The data extracted from the certificate according to this setting can be used to compare against the LDAP or Active Directory attribute. It is also assigned to local variable %certfield% that can be used in defining a LDAP user Distinguished Name (DN) template or query template.
Regular expression
This option appears only when one of the last two settings (regex extraction) is selected for the previous option and defines a regular expression used to extract certificate data for comparison and to fill the %certfield% variable.
Verification method
This option defines the criteria for successful secondary authentication, that is, what is considered a successful verification of certificate data against LDAP. The following choices are available:
User DN found in LDAP
Specifies that the authentication attempt is successful when the user record is retrieved from the LDAP database using the configuration defined in the Configure LDAP settings section; no attribute check is performed.
Direct match of client certificate field to LDAP attribute
Specifies that the user record must be retrieved from LDAP, and LDAP attribute value must match extracted certificate data exactly.
Match client certificate field within LDAP attribute (substring)
Specifies that the user record must be found, and extracted certificate data must be a substring of LDAP attribute value.
Match LDAP attribute within client certificate field (substring)
Specifies that the user record must be found, and LDAP attribute value must be a substring of the extracted certificate data.
Match LDAP attribute within client certificate field (substring)
Specifies that the user record must be found, and LDAP attribute value must be a substring of extracted certificate data.
Configure LDAP Settings
This section specifies the LDAP server configuration, and the criteria used to retrieve the user record from the LDAP database.
LDAP server
Specifies the IP address or host name of the LDAP server
LDAP port
Specifies the TCP port number for connecting to the LDAP server.
Use SSL connection
Specifies whether the connection must use SSL.
Protocol version
Specifies the LDAP protocol version. The default values is 3, and the FirePass controller supports version 2 and 3.
Bind DN
Specifies the DN for binding to the LDAP server. This is usually the DN of the administrative account, or another account with LDAP read access.
Bind password
Specifies the password for the Bind DN.
Get user DN using
Specifies the method the FirePass controller uses to retrieve the user record from the LDAP database. Options are template or query. The following variables are supported:

o%user%, %username%, %s, %logon% - the user name extracted from the client certificate based on configuration options defined globally from the Device Management : Security : Certificates screen.

o%certfield% - the data extracted from the client certificate based on the Client certificate subject field used for verification option.

o%certdn% - the certificate subject DN converted from certificate format to LDAP DN format. This variable is a special case. Use this only when the certificate subject DN is identical to the user object DN in the LDAP directory. This value is specified in the User DN template box by itself, only when you use the template method. This setting is independent of the selections you make for the Client certificate subject field used for verification option.
The difference between using %certdn% and using %certfield% together with the Client certificate distinguished name (DN) value for the Client certificate subject field used for verification option is that %certdn% causes a DN format conversion (from certificate to LDAP format), where %certfield% does not.
When template method is selected the following options appear:

User DN template - this specifies template for user record DN, for example: CN=%certfield%,CN=Users,DC=domain,DC=com or CN=%logon%,OU=Sales,O=Company.
Variables in the template are replaced with their values at the time of user authentication and object, and the resulting DN is retrieved from LDAP. The FirePass controller performs the LDAP search using this variable as the base DN, and the search filter objectClass=*, which returns the object with this base DN, if it exists.
When query method is selected the following boxes appear:

Base DN - the base DN used for an LDAP search

Query template - the template for an LDAP search filter; except for %certdn%, all other variables described are supported
Otherwise, if you use an attribute check, the Client certificate subject setting used for verification must be configured, and the LDAP attribute used for verification must not be empty.
The FirePass controller extracts certificate data according to the configuration options in the first section, and places them in a temporary %certfield% variable. This field is automatically used in the user DN template or query template when the FirePass controller retrieves the user from the LDAP directory in the next step.
When you select the User DN found in LDAP verification method:
If the FirePass controller has a communication problem with the LDAP directory, an error is reported (Connect Failed, Bind Failed, or Request to LDAP server Failed) and verification fails.
If the FirePass controller does not find the user record, errors are logged (LDAP search result - User not found, Client certificate match against LDAP - Failed, Client certificate validation - Failed) and verification fails.
If the FirePass controller finds the user in the database, a message is logged (LDAP search result - User found, and Client certificate validation - Succeeded) and verification succeeds.
If no data was extracted by the FirePass controller from the certificate in the previous step, so the %certfield% value is empty, errors are logged (LDAP query results - No client cert setting and Client certificate validation - Failed) and verification fails.
If the FirePass controller has a communication problem with the LDAP directory, an error is reported (Connect Failed, Bind Failed, or Request to LDAP server Failed) and verification fails.
If the FirePass controller does not find the user record, errors are logged (Client certificate match against LDAP attribute - Failed, Client certificate validation - Failed) and verification fails.
If the FirePass controller finds the user record, the extracted certificate data is matched against LDAP attribute. If the FirePass controller matches the fields successfully, a message is logged (Client certificate setting match within LDAP attribute - Succeeded, or LDAP attribute match within certificate setting - Succeeded, or Client certificate match against LDAP attribute - Succeeded, and Client certificate validation - Succeeded), and verification succeeds. If the FirePass controller cannot match the data successfully, an error is logged (LDAP search result - User not found, Client certificate match against LDAP - Failed, Client certificate validation - Failed) and verification fails.
If the FirePass controller verifies the LDAP and certificate settings, the LDAP attributes are recorded in the session variables %session.ldap.auth.attributeX%. The FirePass controller combines multiple attributes with the same name into a single session variable, with their values concatenated as a space-separated string.
1.
In the navigation pane, click Users, expand Groups, and click Master Groups.
2.
3.
On the Master Groups screen, check the box Automatically log-in when client certificate is present.
4.
If you require a specific certificate issuer for the client certificate, select it from the Required client certificate issuer list.
5.
From the list Perform additional client check using, select LDAP.
6.
From the corresponding lists, select the client certificate subject field to use for comparison, and the verification method.
7.
If you select Direct match client certificate field to an LDAP attribute, Match contents of client certificate field within LDAP attribute (substring), or Match contents of LDAP attribute within client certificate field (substring), you must type the LDAP attribute to use for verification in the box provided.
8.
Configure the LDAP settings.
These settings include the LDAP server and port, whether to use an SSL connection, the protocol version (2 or 3), whether to follow referrals, the Bind DN and password, and whether to get the user's DN using a template or a query.
9.
Click Update to update the authentication method.
10.
Once you have configured the passwordless two-factor authentication for a user, you can get details of the configuration. Type a user name into the Username field, and click Details. The results of the two-factor authentication queries for this user name are displayed.
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.
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.
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 controller master group based on a match. For more information on group mapping, see Setting up dynamic group mapping.
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 users credentials to determine whether the user has a valid account within the domain. If binding to Netlogon succeeds, the FirePass controller authenticates the user.
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. The FirePass controller can also authenticate users with UPN names in Active Directory.
If you have nested groups in your Windows Active Directory configuration, you can use those nested groups during authentication. Nested groups are created in a Windows Active Directory domain, and allow you to raise and lower the level of domain functions within the Active Directory hierarchy.
To use nested groups in the FirePass controller, in the navigation pane, click Users, expand Groups, and click Master Groups. and assign the user to a series of nested groups. You may optionally select the options Check nested groups and User must belong to Domain group.
For more information about nested group checking during Active Directory authentication, refer to the AskF5 Technical Support web site.
You can retrieve user records from Active Directory with an arbitrary Active Directory attribute and value, using a flexible filter expression of the form:
where value can contain variables such as %username%, %logon% or %certfield%.
You use this method when a users sAMAccountName in Active Directory is not a substring of the client certificate subject DN. For example:
Client certificate subject DN: /C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=CONTRACTOR/CN=FERRY.JACOB.M.1278033593
sAMAccountName: Jacob.ferry
employeeID: 1278033593
In this case, the FirePass controller can verify the client certificate using the employeeID attribute, because it is unique, and it is a substring of the subject DN. You can use this filter expression to extract the employeeID attribute:
Use the variable (certfield or username) that is most appropriate for your configuration.
Note: To use this feature, you must install the client root CA certificate on the FirePass controller, and configure user name extraction from the client certificate. Additionally, you must configure the master group with the client certificate authentication method. And the option Perform additional client certificate check using must be set to Active Directory.
You can optionally use a search filter with Active Directory authentication to extract an attribute that you can then use in an expression. The format of the Active Directory search filter is:
where attribute can be any Active Directory attribute, such as sAMAccountName, employeeID, cn, and so on. Except for Regular expression, all text boxes and comparisons are not case-sensitive.
The value can be configured to contain one of the following variables:
%username%, %user%, %logon%, %s - substituted with the user name extracted from the client certificate according to settings on the Device Management : Security : Certificates screen. This is the user name logged on the Reports : Logons screen.
%certfield% - substituted with the value extracted from the client certificate according to the settings on this screen. The Client certificate subject box is used for comparison and (optionally) with a Regular expression.
Note: An empty filter value is the same as specifying sAMAccountName=%username%. Either attribute or value can be omitted, in which case, the defaults are sAMAccountName and %username% .
The system retrieves the users sAMAccountName attribute from the Active Directory using the configured search filter. Then the full user record is retrieved based on the retrieved sAMAccountName, and the Active Directory attribute used for verification is matched (if configured). All Active Directory attributes are then stored in session variables.
You can use the verification option User found in Active Directory, if the only verification you require is that a user record based on the search filter exists, and there is no need to do an attribute match, as is the case with an employeeID attribute. When you select this verification method, the Active Directory attribute used for verification entry box is not displayed.
You select the secondary Active Directory authentication option from the list Perform additional client certificate check using, then specify the secondary authentication option.
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:
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.
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.
When the FirePass controller is serving as the client certificate CA, you can generate and download client certificates on the Users 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 boxes 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 users 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 boxes automatically populates the user name box at logon time. When you request a client certificate during logon, you use one of several options.
Do not use certificate field for logon username
Select this option if you do not want any client certificate box 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 box. However, the FirePass controller does check the client certificate the user provides against the installed root CA certificate, and against any configured CRL checking mechanisms.
Use certificate common name (CN) for logon username
Select this option if your PKI infrastructure issues client certificates that use the common name (CN) as the FirePass controller logon user name or when the certificate is generated on the FirePass controller. When the FirePass controller is configured to serve as the client root CA and issues client certificates directly, it issues certificates that use the client certificate CN as the logon name. When you select this option, the FirePass controller populates the logon name prompt with this value, and other client certificate functions check to make sure the logon name matches the CN box in the client certificate.
Use certificate e-mail address for logon username
Select this option to use the email address of the user as the FirePass controller logon user name. When you select this option, the FirePass controller populates the logon prompt with this value, and other client certificate functions check to make sure the logon name matches the email address in the client certificate. the FirePass controller checks against the first user account found with the specified email address.
Use certificate serial number (SN) for logon username
Select this option to use the certificate serial number (SN) as the FirePass controller logon name. When you select this option, the FirePass controller populates the logon name prompt with this value, and other client certificate functions check to make sure the logon name matches the SN box in the client certificate.
Use certificate subject DN field (regex extraction) for logon username
Select this option to use a different value from the client certificate distinguished name (DN) as the FirePass controller logon name. You can then specify a Perl-style regular expression to extract the user name from the DN. The following example shows a sample DN:
/C=US/ST=CA/L=MyCity/O=MyCompany/OU=MyDept/CN=user/emailAddress=user@company.xyz
You can use an expression such as |CN=(.*)/| to extract the CN for use as the logon name. When you select this option, the FirePass controller populates the logon prompt with the value extracted, and other client certificate functions check to make sure the logon name matches the extracted box from the client certificate.
Use certificate ext subjectAltName field (regex extraction) for logon username
Select this option to use the X509v3 extensions Subject Alternative Name attribute. You can then specify a Perl-style regular expression to extract the subjectAlternativeName from the certificate. For example, if the certificate has the SubjectAltName extension attribute as
X509v3 Subject Alternative Name:
email:joeuser@siterequesta.com, email:joeuser@siterequestb.com

to extract the second e-mail address from this attribute using a regular expression, you can use the following expression
|email:.*, email:(.*)|
Client certificates serve as a security mechanism that allows the FirePass controller to verify that the client computer is a valid computer. You can use client certificates in the following ways:
Two-factor authentication
In the two-factor authentication system, users must have a valid client certificate installed in addition to specifying a user name and password. After installing a client root certificate and enabling the option to request client certificate during logon, the Client Certificate Two-Factor Authentication section becomes available on the Authentication tab for each master group. To access the screen, click Users, expand Groups, click Master Groups, and click the link in the Authentication column for the master group you want to configure. For information about this feature, see Configuring client-certificate two-factor authentication.
Extra policy layer of protection
You can specify use of client certificates for individual access functions or individual resource protection. For example, you can limit access to the FirePass controller Network Access service only to corporate laptops with valid client certificates installed. In that case, users do not have access to the Network Access service from untrusted locations, such as public access kiosks. But you still can give them access to Web Applications, even from untrusted locations.
You can use client certificates to control access to resources by creating a named endpoint configuration on the Protected Configuration screen. To access the screen, click Users, expand Endpoint Security, click Protected Configurations, and then click the New Protected Configuration link. You can assign the endpoint protection you created on the Protect Resources screen. To access the screen, click Users, expand Endpoint Security, and click Protect Resources. Then click the Select link for each service (for example, all Web Applications or webtops), an individual resource group, or several favorites you want to protect, and select the protected configuration you want to use. For information about protected configurations, see Creating protected configurations, and for information about protecting resources, see Protecting resources.
Passwordless auto-logon
The presentation of a valid user client certificate, where the common name (CN) matches the user logon name, enables either a zero-click or one-click automatic logon. You can configure a passwordless automatic logon mechanism on the Authentication screen. To access the screen, click Users, expand Groups, click Master Groups, and click the link in the Authentication column for the master group you want to configure. For information about this feature, see Configuring passwordless authentication.
Dynamic group mapping
The existence of a valid user client certificate allows use of options 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 the existence of settings 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 Setting up dynamic group mapping.
Pre-logon sequence processing
The existence or nonexistence of a valid user client certificate controls whether the FirePass controller performs the defined pre-logon actions, such as loading the protected workspace or denying access to the FirePass controller logon screen. You can configure a pre-logon sequence that require client certificates on the Pre-Logon Sequence screen. To access the screen, click Users, expand Endpoint Security, and click Pre-Logon Sequence. For information about pre-logon sequences and inspectors, see Creating pre-logon sequences to protect resources.
Resource protection
You can use client certificates to control access to resources by assigning a previously defined and named endpoint configuration (created using the New Protected Configuration link on the Users : Endpoint Security : Protected Configurations screen) to a resource on the Protect Resources screen. To access the screen, click Users, expand Endpoint Security, and click Protect Resources, and then click the Select link for each service you want to protect. For information about protected configurations, see Creating protected configurations.
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.
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.
Instruct users how to download and install the client certificate on their computers. You can also email the client certificates to users.
Install a certificate revocation list (CRL) that contains a list of client certificates for users who you want to deny access to the FirePass controller, for example, the revoked client certificates of users who have left your company.
The FirePass controller can then request and validate the computers client certificate against its installed client root certificate as part of the authentication process.
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 companys PKI infrastructure, one made available from a SmartCard solution, or one created and distributed to the user by the FirePass controller itself.
The FirePass controller hides the password prompt, and populates the User name fields on the logon screen with the client certificate setting 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) setting 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.
The FirePass controller supports Windows Mobile client certificate passwordless authentication. With this authentication type, you can configure the FirePass controller to authenticate users with only a certificate, and no requirement for a user name and password. This is the most common form of authentication for personal devices.
You can require the existence of a valid client certificate as a secondary authentication factor, that is, a method 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 servers identity to a users computer. In addition to using server certificates, you can require client certificates that enable the FirePass controller to verify the identity of a users computer, and to control access to specific resources, applications, and files. For more information about server certificates, see Using server certificates on the FirePass controller.
You can require valid client certificates to gain access to specific applications. For example, you might provide access to the FirePass controller Network Access service only for users who present valid client certificates. That user could access the Network Access service from the laptop, but not from other locations, such as public access kiosks, where the certificate might not be installed.
Note: To use this feature, you must install the client root CA certificate on the FirePass controller, and configure user name extraction from the client certificate. Additionally, you must configure the master group with the client certificate authentication method, and configure the option Perform additional client certificate check using to use Active Directory.
1.
In the navigation pane, click Users, expand Groups, and then click Master Groups.
The Master Groups screen opens.
2.
In the Authentication column, click the link representing the master group you want to configure.
The screen changes, and you see the authentication screen for the corresponding master group.
3.
In the Client Certificate Two-Factor Authentication area, check the Require client certificate for user logon check box.
The screen refreshes to reveal certificate-specific options, and a message indicating which client certificate setting the FirePass controller uses to populate the logon box, 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.
The client certificate can be one issued by your company PKI, one made available by a SmartCard solution, or one created and distributed to the user by the FirePass controller itself.
If you have not installed a client certificate, you do not see the Request client certificate during logon check box on the Device Management : Security : Certificates screen, or the Require client certificate for user logon check box on the Users : Groups : Master Groups screen. In that case, install a client root certificate first, using the Client Root Certificate or Self-Signed Certificate option on the Device Management : Security : Certificates screen. For more information, see Installing and configuring client root certificates.
If you have more than one client root certificate installed, you can select a client certificate issuer to restrict authentication to certificates issued by that specific client root certificate. For more information on functionality with more than one client root certificate installed, see the online help for the Device Management : Security : Certificates screen.
The VHOST client certificate request feature allows you to disable or enable the requesting of a client certificate for each individual web service. The global setting on the Security : Certificates screen still controls this functionality for all web services, and no web service requests a certificate when this option is disabled.
When enabled, it is possible to disable a requesting certificate for any selected web service. This is useful in environments in which only a certain group of users are logging on using client certificates, and other users are logging on without them. The group of users can be instructed to log on to a specified host name and port from which the client certificate is requested.
1.
In the navigation pane, click Device Management, expand Configuration, and click Network Configuration.
2.
Click the Web Services tab.
The Web Server Configuration screen appears.
4.
Select Request Client Certificate.
5.
Click Update.
The user is asked to submit the client certificate when connecting to this web service. However, when this option is not checked, the certificate is not requested.
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.
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 administrators 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 setting 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.
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.
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.
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.6, illustrates resource groups and favorite association.
Portal Access
Provides a web-based application that gives users access to POP or IMAP email, network shares, and proprietary corporate applications. For more information about portal access, see Introducing Portal Access.
Network Access
Connects users to the network just as if they were using a traditional IPsec Virtual Private Network connection. Then users can access any applications that use IP networking between their remote computer and the corporate intranet structure, enabling full network access through an SSL-VPN tunnel. For more information about network access, see Introducing Network Access.
Application Access
Provides users access in the following ways:
App Tunnels, connections to a server on a corporate LAN that uses an HTTPS-based, encrypted tunnel through the FirePass controller.
Terminal Servers, connections to Microsoft Terminal Servers, Windows XP® desktops, 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).
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 categorys 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.
A resource group is considered a static resource group when it is explicitly assigned to a master group or to an 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 users 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 groups assigned resource groups. You can also directly assign resource groups to local users from the User : User Management screen.
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 Users 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.
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 groups 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.
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 categorys favorites screen 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.
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
Web Application favorite
Provides remote users with secure access to Web servers on your organization intranet. For more information, see Defining favorites for Portal Access Web Applications access.
Windows Files favorite
Provides remote users with the ability to browse and view files stored on Windows servers on your LAN. For more information, see Configuring Windows files.
App Tunnels favorite
Gives a remote FirePass controller user to access a TCP/IP client/server application on your LAN. For more information, see Configuring master group settings for App Tunnels.
Legacy Host favorite
Provides remote FirePass controller users access to legacy applications on your organizations hosts. For more information, see Defining legacy host favorites.
Terminal Server favorite
Gives remote users access to computers running Terminal services, Citrix MetaFrame servers, and VNC servers. For more information, see Configuring terminal server favorites.
Network Access favorite
Provides remote FirePass controller users with SSL VPN access to applications and network resources on your LAN. For more information, see Chapter 5, Configuring Network Access.
You can use the Impersonate User feature to log on as if you were a user. This feature can help you troubleshoot configuration once everything is configured. You can find Impersonate User on the Users item in the navigation pane. This feature is useful for checking favorites that you create and for troubleshooting other connection issues.
The impersonation process skips the step of authenticating the user. In order to skip authentication, the FirePass controller must have sufficient information about those users to treat them appropriately. Therefore, you can impersonate only those users whose information is maintained in FirePass controller data store.
When you log on using the Impersonate User feature, the system behaves as if users were authenticated, even if those users can not pass the normal log on procedure. While impersonating a user, you do not have access to any network resources that require logging on.
While you are impersonating a user, the system records the actions of the impersonated user in the Sessions report, available in Reports : Sessions. Because the user did not actually log on, the system does not record an entry in the Logon report.
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)