Applies To:

Show Versions Show Versions

Archived Manual Chapter: Configuring Authentication Using AAA
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.

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.
Authorization is the process of enabling users with access to resources, applications, and network shares.
The BIG-IP® Secure Access Manager uses the concept of access policies to authenticate and authorize users on the system. For more information on access policies, refer to Chapter 5, Creating Access Profiles and Access Policies.
The stringent nature of the authentication mechanism you use for the Secure Access Manager should match your local network. That is, you should use equally high standards for the Secure Access Manager authentication as you do for your local network.
To set up authentication, log on to the Configuration utility and on the navigation pane, expand Access Control, and click AAA Servers.
RADIUS server
Uses the server at your site that supports authentication using the RADIUS protocol. For more information on this method, see Setting up RADIUS authentication and authorization.
LDAP server
Uses the server at your site that supports authentication using LDAP. For more information on this method, see Setting up LDAP authentication and authorization.
Microsoft 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 Windows Active Directory authentication and authorization.
Client certificate passwordless
Requires no name or password at logon for users who have the installed client certificate. For more information on this method, refer to Chapter 9, Using Client Certificate Authentication.
RSA SecurID over RADIUS
Uses the RADIUS protocol for authentication. To use RSA SecurID over RADIUS, you must select RADIUS as the authentication method. For more information on this method, refer to Configuring RSA SecurID using RADIUS.
The Secure Access Manager can authenticate users using a RADIUS server. The following tasks provide information on how to set up your RADIUS server. You can also leverage user information, in the form of attributes, to allow users access to various network resources.
Important: Be sure that the RADIUS server is configured to recognize the Secure Access Manager as a client. Use the same shared secret in both the RADIUS server configuration, and in the Secure Access Manager configuration.
1.
On the navigation pane, expand Access Control, and click AAA Servers.
The AAA Server List screen opens.
2.
Click the Create button.
A General Properties screen opens.
3.
4.
Enter the information in the required fields (marked with a vertical blue line next to the fields) and click Finish.
The new RADIUS server is now added to the AAA Server List.
Tip: You must use the Retries setting if you use the Timeout setting. If these settings are set, the Secure Access Manager attempts to reach the AAA server within the specified timeframe in seconds. If the server does not respond, the Secure Access Manager retries the authentication attempt, depending on how many retries you specify.
Secure Access Manager supports the challenge-response for RADIUS protocol. The challenge-response works in the following order:
Secure Access Manager uses the clients user name and password to authenticate against the external RADIUS server on behalf of the client.
When Secure Access Manager receives the RADIUS challenge from the external server, Secure Access Manager passes the challenge request to the client.
After the client submits the new information, Secure Access Manager passes the response to the external RADIUS server.
 
Secure Access Manager runs the next appropriate access policy action item based on the external RADIUS servers return code (RADIUS-Accept or RADIUS-Reject).
1.
On the navigation pane, expand Access Control, and click Access Profiles.
The Access Profiles screen opens.
3.
On the menu bar, click Access Policy.
The Access Policy screen opens.
4.
Next to the Visual Policy Editor, click the link Edit Access Policy for Profile "<name of policy>" to start the visual policy editor.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Click the small plus sign where you want to add the new access policy action item.
A properties screen opens.
6.
Under Authentication, select RADIUS and click Add item.
The RADIUS object appears in the visual policy editor.
7.
8.
Click Activate Access Policy to save your configuration.
The AAA server is added to the access policy, and is now a part of the overall authentication process.
As mentioned earlier, you can authorize your users with user information provided by the RADIUS server in the form of attributes. These attributes, converted into session variables, can be used to create rules. For more information on session variables and how to use them to create your rules, refer to Appendix C, Session Variables.
$attr_name is a value that represents the users attributes received during RADIUS authentication. Each attribute is converted to separate session variables.
1.
On the navigation pane, expand Overview, and click Reports.
The Reports screen opens.
2.
Click an active session ID.
The Properties screen opens.
The Secure Access Manager provides two default rules for the RADIUS access policy action. You use these rules to organize your users into the following two categories:
Authenticated Users: These users were authenticated successfully and are able to access their webtop.
 
Users fails Authentication: These users failed authentication and are directed to the logon denied page.
You can add your own custom rules using the session variables. For example, you can create your own custom rules when you want different users assigned to different network resources. For more information on how to add custom access policy rules, refer to Chapter 5, Creating Access Profiles and Access Policies.
RADIUS authentication is an important part of the access policy. To ensure that your users are authenticated, you must add the RADIUS server as an action item to the access policy.
Figure 8.1 shows an example of an access policy with all the elements associated to authenticate and authorize your users. Notice that the RADIUS object was added to the access policy as part of the authentication process, as a result, providing two default rules.
You may run into problems with RADIUS authentication in some instances. Follow these tips to try to resolve any issues you may encounter. Additionally, you can view specific error messages concerning authentication in the /var/log/firepass file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click Access Control.
Check to see if the Secure Access Manager is configured as a client on the RADIUS server.
You may have encountered a general network connection problem.
Authentication failed due to RADIUS access reject
Check to see if the shared secret on the RADIUS is valid.
Check to see if the user credentials are entered correctly.
To set up RSA SecurID over RADIUS, follow the same steps as you have done to set up a RADIUS access policy action, as described in Setting up RADIUS authentication and authorization access policy action item. Secure Access Manager supports the following RSA Secure ID feature checklist over RADIUS protocol.
If you are having difficulty authenticating using RSA SecurID over RADIUS on the authentication server that is running RSA SecurID server, you can view specific error messages concerning authentication in the /var/log/firepass file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click Access Control.
Even if the RADIUS server has been started from the SecurID options window on the Windows SecurID server, the server may not be active.
In the Windows Services Manager, make sure that the server is set to start each time the server boots, and is currently running. RSA SecurID authentication using RADIUS takes place on a different port than the native SecurID authentication.
The SecurID is configured incorrectly 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 Secure Access Manager authentication request and does not store anything in the logs.
Check to see if the RSA SecurID is configured properly.
To facilitate communication between the Secure Access Manager and the RSA SecurID, an Agent Host record must be added to the RSA Authentication Manager database.
The Agent Host record identifies the Secure Access Manager within its database and contains information about communication and encryption.
Hostname
IP Addresses for all network interfaces
RADIUS Secret (When using RADIUS Authentication Protocol)
When adding the Agent Host Record, you should configure the Secure Access Manager as a communication server. This setting is used by the RSA Authentication Manager to determine how communication with the Secure Access Manager will occur.
You can use an LDAP-protocol-based directory, including an Active Directory, to authenticate users. In this case, you do not store user information on the Secure Access Manager. Instead, you obtain it from the LDAP entry.
1.
On the navigation pane, expand Access Control, and click AAA Servers.
The AAA servers screen opens
2.
Click the plus sign next to AAA Server to add a new server, or simply click the Create button.
A General Properties screen opens.
3.
4.
Enter the information in the required fields (marked with a vertical blue line next to the fields), and click Finish.
The new LDAP server is added to the AAA Server List.
Note: If your LDAP directory allows anonymous query, you do not need to specify an admin account or password in the required fields. Either specify credentials of any LDAP account that allows querying this part of the LDAP directory, or create a new LDAP account for Secure Access Manager.
1.
On the navigation pane, expand Access Control, and click Access Profiles.
The Access Profiles screen opens.
3.
On the menu bar, click Access Policy.
The Access Policy screen opens.
4.
Next to the Visual Policy Editor, click the link Edit Access Policy for Profile "<name of policy>" to start the visual policy editor.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Click the small plus sign where you want to add the new access policy action item.
A properties screen opens.
6.
Under Authentication, select LDAP, and click Add item.
The LDAP object appears.
8.
Click Activate Access Policy to save your configuration.
The LDAP server is added to the access policy, and is now part of the overall authentication process.
To use LDAP authentication, you must specify the authentication type as Auth from the visual policy editor. Additionally, you need specific information from your LDAP server administrator.
1.
On the navigation pane, expand Access Control, and click Access Profiles.
The Access Profiles screen opens.
3.
On the menu bar, click Access Policy.
The Access Policy screen opens.
4.
Next to the Visual Policy Editor, click the link Edit Access Policy for Profile "<name of policy>" to start the visual policy editor.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Click the LDAP access policy action item.
The Properties screen opens.
6.
For the Type setting, select Auth from the list.
7.
For the Server setting, select the name of your LDAP server.
8.
Specify information for the SearchFilter and Search DN settings.
The Secure Access Manager queries the LDAP server using SearchDN and SearchFilter. 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 bind succeeds, the authentication succeeds, that is, the user is validated. If the bind fails, the authentication fails. For example, in an LDAP structure, a typical Search base DN would be similar to the following string:
dc=sales, dc=mycompany, dc=com
In an LDAP structure, a typical Search filter would be similar to the following string: SAMAccountName=%{session.logon.last.username}.
9.
Specify information for the UserDN setting.
This step is required only if you do not use the SearchDN setting with the SearchFilter setting.
The Secure Access Manager attempts to bind with the LDAP server using the supplied DN and user-entered password. If the bind succeeds, that is, authentication, the user is validated. If the bind fails, the authentication fails.
This is a 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 LDAP structure, a typical UserDN for query would be similar to the following string: cn=%{session.logon.last.username}, cn=users, dc=lab, dc=fp.
10.
Specify the Max Logon Attempt Allowed setting.
This gives the users an opportunity to re-enter their user credentials if their first attempt to log on fails. If you set this value to be greater than 1, a logon page reappears for the user after a log on failure. If the value is set to 1, no log on retry is allowed. The available range is 1-5, with 3 set as the default.
Additionally, Secure Access Manager supports using session variables in SearchFilter, SearchDN and UserDN fields. For example, if you want to use the users CN from the users SSL certificate as input in of these fields, you can use the session variable session.ssl.cert.last.cn in place of session.logon.last.username. Refer to Appendix C, Session Variables for more information.
This queries the appropriate part of the directory tree structure (specified by the search base, or container, DN) to find a user within that directory.
To use LDAP query, you must specify the authentication type as Query and then use the appropriate LDAP server.
1.
On the navigation pane, expand Access Control, and click Access Profiles.
The Access Profiles screen opens.
3.
On the menu bar, click Access Policy.
The Access Policy screen opens.
4.
Next to the Visual Policy Editor, click the link Edit Access Policy for Profile "<name of policy>" to start the visual policy editor.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Click the LDAP access policy action item.
The Properties screen opens.
6.
For the Type setting, select Auth from the list.
7.
For the Server setting, select the name of your LDAP server.
8.
Specify information for the SearchDN and Search Filter settings.
The Secure Access Manager queries the LDAP server using SearchDN and SearchFilter settings. 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 bind succeeds, the authentication succeeds, that is, the user is validated. If the bind fails, the authentication fails. For example, in an LDAP structure, a typical Search base DN would be similar to the following string:
dc=sales, dc=mycompany, dc=com.
In an LDAP structure, a typical Search Filter would be similar to the following string: SAMAccountName=%{session.logon.last.username}.
You can authorize your users with user information provided by the LDAP server in the form of attributes. For each attribute, the system creates a session variable automatically. For more information on session variables, refer to Appendix C, Session Variables.
Session Variable for LDAP Authentication and Query
session.ldap.last.authresult
session.ldap.last.queryresult
$attr_name is a value that represents the users attributes received during LDAP authentication/query. Each attribute is converted to separate session variables.
1.
On the navigation pane, expand Overview, and click Reports.
The Reports screen opens.
2.
Click an active Session ID.
The Properties screen opens.
The Secure Access Manager provides two default rules for the LDAP authentication access policy action.You use these rules to organize your users into the following two categories:
Authenticated Users: These users were authenticated successfully and are able to access their webtop.
Users fails Authentication: These users failed authentication and are directed to the logon denied page.
You can add your own custom rules using the session variables, as previously described. For instance, you can create your own custom rule to assign different network resources to users. For more information on how to add custom access policy rules, refer to Chapter 5, Creating Access Profiles and Access Policies.
Although there is an existing default rule for LDAP query called LDAP auth has passed, this default rule works only for LDAP authentication. You need to make modifications to this default rule for it to work properly with LDAP query. You do this by renaming the rule to LDAP query has passed.
1.
On the navigation pane, click Access Control, and select Access Profiles.
The Access Profiles List screen opens.
2.
Click Edit next to the profile you want to edit.
The visual policy editor screen opens.
3.
On the visual policy editor screen, click the LDAP access policy action item.
The Properties screen of the visual policy editor opens.
5.
On the Rules screen, click the x button located on the right side to delete the existing default rule called LDAP auth has passed.
6.
Click Add Rule, and type in a name for your new LDAP query rule.
7.
For the Expression setting, click the change link.
A pop-up opens
8.
Click Add expression.
9.
For the Agent Sel setting, select LDAP query from the list.
10.
For the Condition setting, select Users Primary Group ID from the list, and type the correct value in the box.
11.
Click Add Expression, and click Save.
12.
Click Finish.
Your new LDAP query default rule is now added to your access policy, as shown in Figure 8.2.
Figure 8.3 is an example of an access policy with all the elements associated to authenticate and authorize your users with LDAP query and LDAP authentication. Notice that the objects were added to the access policy as part of the authentication process.
Upon successful authentication, the system retrieves a user group using LDAP query. Resources are assigned to users if the user group has access to the network access resources. Additionally, users are directed to the webtop ending.
In the figure following, the rule for LDAP query was changed from default rule to check for users group attribute. For an example on how to change access policy rules and create your own access policy rules, refer to Chapter 10, Advanced Topics in Access Policies.
To troubleshoot LDAP authentication or query issues, you can view specific error messages in the /var/log/firepass file. Or from the navigation pane, expand Systems, click Logs, and on the menu bar, click Access Control.
Note: Make sure that your log level is set to the appropriate level. The default log level is notice. Refer to Chapter 11, Logging and Reporting, for more formation on how to use the logging feature.
Additionally, you can look into the session reports for information on user's logon attempts. On the navigation pane, expand Overview, choose Reports, and click the active session ID to see all the session variables.
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 server or later, F5 Networks recommends that you use Active Directory authentication instead of Windows domain authentication.
1.
On the navigation pane, expand Access Control and click AAA Servers.
The AAA servers screen opens.
2.
Click the Create button.
A General Properties screen opens.
3.
Type a name for your AAA server, and from the Type list, select Active Directory.
4.
Enter the information in the required fields (marked with a vertical blue line next to the fields) and click Finish.
The new Active Directory server is added to the AAA Server list.
Note: You must configure an NTP Server. This needs to be the same NTP server that your key distribution center (KDC) uses. The reason is that the time on your Secure Access Manager and the time on your KDC need to be within 5 minutes of each other. Otherwise, authentication will fail. On the navigation pane, expand System, click General Properties, and from the Device menu, choose NTP.
Remember also that you need to configure a DNS server that is aware of your Active Directory domain. On the navigation pane, expand System, click General Properties, and on the Device menu, choose DNS.
Tip: If you do not have an NTP server, find the time on your KDC, and set the time on the Secure Access Manager to be within 5 minutes of that time using the date command. To enter a new date/time, type the command: date MMDDHHmmSSYYYY,
where:
MM is the numerical month
DD is the numerical day
HH is the numerical hour (24-hour clock)
mm is the numerical minute
YYYY is the numerical year.
So if your KDC says it is November 7, 2007 8:24a.m, you would type:
date 110708242007
Tip: Although it is not required, you can enter the admin name and password during this initial configuration, although this will only apply to AD query.
Secure Access Manager supports password management for Active Directory authentication. This works in the following order:
Secure Access Manager uses the clients user name and password to authenticate against the external Active Directory server on behalf of the client.
If the clients account on the external Active Directory server has expired, Secure Access Manager returns a new logon page back to the client, requesting the client change its password.
After the client submits the new password, Secure Access Manager attempts to change the password on the external Active Directory server.
If the password change failed, it is likely that the Active Directory server rejected it because the password did not meet the minimum requirements such as password length.
In order to complete the authentication process, you must add Active Directory to an access policy as an action item.
1.
On the navigation pane, expand Access Control and click Access Profiles.
The Access Profiles screen opens.
3.
On the menu bar, click Access Policy.
The Access Policy screen opens.
4.
Next to the Visual Policy Editor, click the link Edit Access Policy for Profile "<name of policy>" to start the visual policy editor.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
5.
Click the small plus sign shown after Fallback.
A properties screen opens.
6.
Under Authentication, select Active Directory and click Add item.
The Active Directory object appears in the visual policy editor.
7.
On the Properties tab, select the name of your Active Directory server from the AAA Server list, and click Save.
8.
Click Apply Changes to save your configuration.
The Active Directory server is now added to the access policy, and is part of the overall authentication process.
To use Active Directory authentication, you must specify the authentication type as Auth in the visual policy editor. Additionally, you need specific information from your Active Directory server administrator.
1.
On the navigation pane, expand Access Control, and click Access Profiles.
The Access Profiles screen opens.
3.
On the menu bar, click Access Policy.
The Access Policy screen opens.
4.
Next to the Visual Policy Editor, click the link Edit Access Policy for Profile"<name of policy>" to start the visual policy editor.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
6.
For the Type setting, select Auth from the list.
7.
For the Server setting, select the name of your Active Directory server.
a)
Server: allows the administrator to specify the Active Directory server configuration object to be used for authentication and query.
b)
UserPrincipalName: allows the administrator to enable user principal name (UPN) naming style supported in Secure Access Manager, for example, user@domain.
c)
Max Logon Attempt Allowed: gives the user an opportunity to re-enter his user credentials if his first attempt to log on fails. If you set this value to be greater than 1, a logon page reappears for the user after a log on failure. If the value is set to 1, no log on retry is allowed. The available range is 1-5, with 3 set as the default.
To use Active Directory query, you must specify the authentication type as Query and then use the appropriate Active Directory server.
This queries the appropriate part of the directory tree structure (specified by the search base, or container, DN) to find a user within that directory.
1.
On the navigation pane, expand Access Control, and click Access Profiles.
The Access Profiles screen opens.
3.
On the menu bar, click Access Policy.
The Access Policy screen opens.
4.
Next to the Visual Policy Editor, click the link Edit Access Policy for Profile "<name of policy>" to start the visual policy editor.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
6.
For the Type setting, select Auth from the list.
7.
For the Server setting, select the name of your Active Directory server.
a)
Server: allows the administrator to specify the Active Directory server configuration object to be used for Active Directory query or authentication.
b)
SearchFilter: allows the administrator to specify the search criteria to be used while querying Active Directory server for user's information. Session variables are supported as part of search query string.
c)
FetchGroupAttribute: allows the administrator to retrieve the user's primary group attributes. These attributes will be stored in session.ad.last.attr.group* session variable. This enables an administrator to use the users primary group information in access policy rules.
d)
UserPrincipalName: allows the administrator to enable user principal name (UPN) naming style support in Secure Access Manager, for example, user@domain.
You can authorize your users with user information provided by the Active Directory server in the form of attributes. For each attribute, the system automatically creates a session variable. For more information on session variables, refer to Appendix C, Session Variables.
session.ad.last.authresult
session.ad.last.queryresult
$attr_name is a value that represents the users attributes received from the external Active Directory server. Each attribute is converted to separate session variables.
$attr_name is a value that represents the users group attributes received from the external Active Directory server. Each attribute is converted to separate session variables.
1.
On the navigation pane, expand Overview, and click Reports.
The Reports screen opens.
2.
Click an active session ID.
The Properties screen opens.
To troubleshoot Active Directory authentication or query issues, you can view specific error messages in the /var/log/firepass file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click Access Control.
Note: Make sure that your log level is set to the appropriate level. The default log level is notice. Refer to Chapter 11, Logging and Reporting, for more information on how to use the logging feature.
Additionally, you can look into the session reports for information on user's logon attempts. On the navigation pane, expand Overview, click Reports and on the screen, click the active session ID to see all the session variables.
Figure 8.5 is an example of an access policy with all the elements associated to authenticate and authorize your users with Active Directory query and Active Directory authentication. Notice that the objects were added to the access policy as part of the authentication process.
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)