AskF5 Knowledge Base
- Home
- Supported Products
- BIG-IP APM / VE
- Configuration Guide for BIG-IP Access Policy Manager
- Configuring Authentication Using AAA
Applies To:
Show Versions
Manual Chapter: Configuring Authentication Using AAA
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.
Accounting is the process of reporting user session information, as well as updating the external RADIUS accounting server.
The BIG-IP® Access Policy ManagerTM uses the concept of access policies to authenticate and authorize users on the system. For more information on access policies, refer to Chapter 7, Creating Access Profiles and Access Policies.
The stringent nature of the authentication mechanism you use for the Access Policy Manager should match the authentication level for your local network. That is, you should use standards for the Access Policy Manager authentication that are equally as high as you use for your local network.
To set up authentication, log on to the Configuration utility and on the navigation pane, expand Access Policy, and click AAA Servers.
There are two types of authentication that pertain to Active Directory and LDAP authentications, and they use two separate access policy items.
| Auth: This means authentication only. In this case, the Access Policy Manager just verifies users credentials against an external server. |
| Query: This means the Access Policy Manager queries the external server for additional information about the user. |
The Auth and Query methods are independent of each other, and you do not necessarily need to have them configured within the same access policy.
However, as an administrator, you must make a decision on which type of policy item you would like to add to your access policy. For instance, if you added AD Auth to your policy, you cannot change it later to AD Query unless you go into your access policy and delete the AD Auth item completely from your policy.
For more information on how to configure the Auth and Query methods for either LDAP or Active Directory, refer to Configuring LDAP access policy action item for authentication, Configuring LDAP query policy action item, Configuring Access Policy Manager to access the Active Directory for authentication, and Configuring Access Policy Manager to access the Active Directory action item for query.
Important: To use a specific authentication method, you must have at your site a server that supports the scheme.
| RADIUS server Uses the server at your site that supports authentication using the RADIUS protocol. For more information on this method, see RADIUS authentication. |
| LDAP server Uses the server at your site that supports authentication using LDAP. For more information on this method, see Setting up Access Policy Manager for 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 Access Policy Manager for Windows Active Directory authentication and authorization. |
| HTTP authentication Uses external web-based authentication servers to validate user logons and passwords, and to control user access to specific network resources. For more information on this method, see Setting up Access Policy Manager for HTTP 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. |
| RSA Native SecurID Uses the RSA Native SecurID protocol for authentication. To use RSA Native SecurID, you must have an authentication server set up, and you must select SecurID as the authentication method. For more information on this method, refer to Setting up Access Policy Manager for RSA Native SecurID for authentication and authorization. |
The Access Policy Manager provides you with three modes of operation for RADIUS. You can use a RADIUS server to authenticate your users, retrieve user session information using a RADIUS accounting server, or perform both actions within a single access policy.
RADIUS authentication allows you to authenticate and authorize your users to access their resources through a RADIUS server that you configure on the Access Policy Manager. For more information on how to set up authentication using a RADIUS server, refer to Setting up RADIUS authentication and authorization access policy action item.
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 Access Policy Manager as a client. Use the same shared secret in both the RADIUS server configuration and in the Access Policy Manager configuration.
The table, following, lists the specific RADIUS authentication attributes that the Access Policy Manager sends with RADIUS requests.
| Indicates the physical port number of the NAS which is authenticating the user. |
You can report user session information to an external RADIUS accounting server. If you select this mode only, the system assumes that you have set up another type of authentication method to authenticate and authorize your users to access their resources. For more information on how to set up RADIUS accounting, refer to To configure RADIUS accounting.
The Access Policy Manager operates as a client of the external RADIUS accounting server, and is responsible for retrieving user information. It sends accounting messages indicating when the network access is initiated or terminated, by sending the RADIUS accounting start and stop messages. However, the RADIUS accounting start message does not mean the actual network access will be successfully established. If a user logs in, but the network tunnel fails to establish, the user is not presented with a logon denied page. Instead, the user either sees an error message on the webtop and must manually log out, or is automatically logged out of a session. In either case, the accounting stop message is sent when the user is logged out and the session terminates.
| When a user logs on to the Access Policy Manager, the system sends session start information to the RADIUS accounting server. Session start information consists of the RADIUS username, the RADIUS sessionid of the users session, and a RADIUS accounting status start message, indicating that the session has started. |
| When the user terminates the session by logging off the Access Policy Manager, the system sends session end information to the RADIUS accounting server. The session end information includes the RADIUS username, the RADIUS sessionid, and the RADIUS accounting status stop message, indicating that the session has ended. Also included in this stop message is the RADIUS service duration, which represents the total time the user session was active. |
The tables 11.2 and 11.3 list specific RADIUS accounting attributes that the Access Policy Manager sends for RADIUS Accounting-Request (start message) and RADIUS Accounting-Request (stop message).
| A unique accounting ID to make it easy to match start and stop records in a log file. It is essentially a users session ID. | |
| Indicates whether the accounting-request marks the beginning of the user service (Start) or the end (Stop). | |
| Indicates how the user was authenticated, whether by RADIUS, the NAS itself, or by another remote authentication protocol. | |
| Identifies the IP address of the NAS that is requesting authentication of the user. The administrator can enter this address on the AAA RADIUS server configuration page. | |
| The physical port number of the NAS that is authenticating the user. It is always set to 0. | |
| Administrators can make resource assignments using this attribute. |
Attributes for stop messages include the following values:
| Indicates how the session was terminated. Access Policy Manage supports three values for this attribute: | |
| A unique accounting ID to make it easy to match start and stop records in a log file. It is essentially a users session ID. | |
| Indicates whether the accounting-request marks the beginning of the user service (Start) or the end (Stop). | |
| Indicates the number of octets received from the port over the course of the service provided. | |
| Indicates the number of octets sent to the port in the course of delivering the service provided. |
If the user does not log off, but simply closes the web browser window, the Access Policy Manager sends the RADIUS stop message when the users session times out.
RADIUS accounting messages are sent asynchronously. The Access Policy Manager stores the users sessions start and end information in its database, and sends them to the RADIUS accounting server.
Important: Be sure to configure your RADIUS accounting server to recognize the Access Policy Manager as a client. Refer to your external servers user manual for more information how to do perform this task.
You can perform both RADIUS authentication and accounting actions. Keep in mind that if you select this mode, the RADIUS server and the RADIUS accounting server must run on different service ports, and that the Access Policy does not send RADIUS accounting information to the RADIUS accounting server unless the user has been authorized by the RADIUS server.
Setting up Access Policy Manager for RADIUS authentication and authorization
The first task in setting up a RADIUS authentication is to configure the RADIUS server. The Access Policy Manager is a NAS (Network Access Server), that operates as a client of the server configured here.
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The New Server General Properties screen opens. |
| 2. | Type a name for your AAA server and select RADIUS from the Type list. The screen refreshes to provide additional settings specific to the RADIUS Type. |
| 3. | In the Configuration section, select the Mode type. |
| 4. | Enter the information in the required fields. You can find details for each setting in the online help. This adds the new RADIUS server to the AAA Server List. |
If you use the Timeout setting, you must use also the Retries setting. If these settings are enabled, the Access Policy Manager attempts to reach the AAA server within the specified timeframe in seconds. If the server does not respond, the Access Policy Manager retries the authentication attempt, depending on how many retries you specify.
To complete the authentication process, you must add the RADIUS Auth action to an access policy.
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | On the Access Profiles list screen, click the name of your profile. The Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 Auth and click Add item. The RADIUS Auth object popup opens in the visual policy editor. |
| 7. | On the Properties tab, select the name of your RADIUS server from the AAA Server list, and click Save. |
| 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. |
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.
The RADIUS access policy action automatically creates the session variables, as shown in Table 11.1.
| $attr_name is a value that represents the users attributes received during RADIUS authentication. Each attribute is converted to separate session variables. | |
| Displays the error message for the last logon. If session.RADIUS.last.result is set to 0, then session.RADIUS.last.errmsg may be useful for troubleshooting purposes. |
| 1. |
| 2. | Click an active session ID. The Properties screen opens. |
| 3. | Scroll down the list of session variables until you see the RADIUS session variables. |
The Access Policy Manager provides two default rules for the RADIUS authentication access policy action. You use these rules to organize your users into two categories:
| Authenticated Users: These users were authenticated successfully and are able to access their webtop. |
| Users fail 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.
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/apm file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click Access Policy.
| Check that the Access Policy 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 that the shared secret on the RADIUS is valid. Check that the user credentials are entered correctly. |
Refer to Table 11.6, following, for steps on how to ensure that a connection is successfully made between the Access Policy Manager and your authentication server, and that your authentication method is working properly.
| Check to see if your access policy is attempting to perform authentication | Refer to the message boxes in your access policy to display information on what the access policy is attempting to do. Refer to /var/log/apm to view authentication attempts by the access policy. Note: Make sure that your log level is set to the appropriate level. The default log level is notice. Refer to Chapter 17, Logging and Reporting, for more information on how to use the logging feature. |
| Access the Access Policy Manager through the command line interface and check your connectivity by pinging the RADIUS server using the host entry in the AAA Server box. Confirm that the RADIUS port in use (for example, the default, 1812) is not blocked between the Access Policy Manager and the RADIUS server. | |
| Check the RADIUS Server Configuration | Confirm that the Access Policy Manager is registered as a RADIUS client. Note: Since the Access Policy Manager makes requests from the self IP address to the RADIUS server for authentication requests, the address of the self IP address should be registered as a RADIUS client. |
| Use the tcpdump utility from the Access Policy Manager when authentication attempts are made. For example, %tcpdump-i 1.1 -s /tmp/dump. You must first determine what interface the self IP address is on. The results indicate activities between the Access Policy Manager and the authentication server. Run the authentication test. After authentication fails, stop the tcpdump, download the tcpdump records to a client system, and use an analyzer to troubleshoot. Important: If you decide to escalate the issue to Customer Support when you encounter authentication issues that you cannot otherwise resolve on your own, you must provide the output of running the tcpdump utility. |
To set up RSA SecurID over RADIUS, follow the same steps you did to set up a RADIUS access policy action, as described in Setting up RADIUS authentication and authorization access policy action item. Access Policy Manager supports the following RSA SecurID feature checklist over RADIUS protocol, as shown in the table, following.
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/apm file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click Access Policy.
Additionally, refer to the following table for possible corrective actions based on the errors received.
| 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. | |
| 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 Access Policy Manager authentication request and does not store anything in the logs. | |
| Check that the RSA SecurID is configured properly. To facilitate communication between the Access Policy Manager and the RSA SecurID, an Agent Host record must be added to the RSA Authentication Manager database. For an example on how to add an agent host, refer to Adding the Access Policy Manager as an agent host to an RSA Native SecurID authentication server. The Agent Host record identifies the Access Policy Manager within its database and contains information about communication and encryption. RADIUS secret (Click Assign/Change Encryption Key to input the secret. This RADIUS secret must match the corresponding RADIUS secret on the Access Policy Manager). When adding the Agent Host record, you should configure the Access Policy Manager as a communication server. This setting is used by the RSA Authentication Manager to determine how communication with the Access Policy Manager will occur. |
Configuring Access Policy Manager for RADIUS accounting
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The New Server General Properties screen opens. |
| 2. | In the Name box, type the name for your AAA server. |
| 3. | In the Type box, select the RADIUS option as your AAA server type. The screen refreshes to show configuration options for RADIUS. |
| 4. |
| 5. | For Accounting Host, type the IP address of your RADIUS accounting server. |
| 6. | In the Accounting Service Port box, type the service port for your Accounting server. The default is 1813. |
| 7. | For Secret, type the shared secret value or string used by both the RADIUS server configuration and the Access Policy Manager configuration. |
| 8. | In the Confirmed Secret, box re-type the shared secret value or string. |
| 9. | Click Finished |
To complete configuring the RADIUS accounting process, you must add the RADIUS Acct action to an access policy.
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | On the Access Profiles list screen, click the name of your profile. The General Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 Acct and click Add item. The RADIUS Auth object popup opens in the visual policy editor. |
| 7. | On the Properties tab, select the name of your RADIUS accounting server from the AAA Server list, and click Save. |
| 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. |
The RADIUS access policy action automatically creates the session variables, as shown in Table 11.9.
| $acct_attr_name is a value that represents the users accounting information attributes. |
You may run into problems with RADIUS accounting in some instances. Follow the tips in table 11.10 to try to resolve any issues you may encounter. Additionally, you can view specific error messages concerning authentication in the /var/log/apm file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click Access Policy.
| Check that the Access Policy Manager is configured as a client on the RADIUS server. You may have encountered a general network connection problem. | |
| Accounting failed due to RADIUS access reject | Check that the shared secret on the RADIUS is valid. Check that the user credentials are entered correctly. |
Configuring Access Policy Manager for RADIUS authentication and accounting
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The New Server General Properties screen opens. |
| 2. | Type a name for your AAA server, and select RADIUS from the Type list. The screen refreshes to provide additional settings specific to the RADIUS Type. |
| 3. | In the Configuration section, select Auth & Accounting mode. |
To complete the authentication and accounting process, you must add the RADIUS Auth action to an access policy.
To add the RADIUS authentication and accounting server as an access policy action item
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | On the Access Profiles list screen, click the name of your profile. The Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 in the visual policy editor. |
| 6. |
| 7. | Now select RADIUS Acct and click Add item. The RADIUS authentication and accounting objects popup opens in the visual policy editor. |
| 8. | On the Properties tab, select the name of your RADIUS server from the AAA Server list, and click Save. |
| 9. | Click Activate Access Policy to save your configuration. The RADIUS authentication and accounting server is added to the access policy, and is now a part of the overall authentication process. |
Setting up Access Policy Manager for RSA Native SecurID for authentication and authorization
RSA Native SecurID is a two-factor authentication mechanism developed by RSA®, the Security Division of EMC. This mechanism of authentication is based on a user PIN or password and a token generated by an authenticator and provided to the user.
A token is an authentication code generated every 60 seconds by an authenticator (hardware or software) assigned to the user.
The Access Policy Manager supports the following RSA Native SecurID feature checklist.
Setting up RSA Native SecurID authentication and authorization involves the following tasks:
| Add the Access Policy Manager as an agent host to an RSA Native SecurID authentication server |
| Configure the Access Policy Manager to use the RSA Native SecurID authentication server |
Note: Please refer to your RSA SecurID Implementation Guide for information on how to set up your RSA Native SecurID authentication server.
Adding the Access Policy Manager as an agent host to an RSA Native SecurID authentication server
To enable communications between the Access Policy Manager and an RSA Native SecurID authentication server, you must add the Access Policy Manager as an agent host to the authentication server. The agent host record identifies the Access Policy Manager within the server authentication database, and includes information about communication and encryption.
To add the Access Policy Manager as an agent host to an RSA Native SecurID authentication server
| 1. | On the administrative interface of your RSA Native SecurID authentication server, click the Agent Host tab, and select the Add Agent item. |
| 2. | In the Name box, specify a name for identifying the Access Policy Manager agent host configuration. This may or may not be a DNS-resolvable name. This name can be different from the FQDN configured on the Access Policy Manager. |
| 3. | In the Network Address box, type the IP address used by the Access Policy Manager while communicating with the RSA Native SecurID authentication server. This address must be the source IP address present in the IP packets received by the RSA Native SecurID authentication server from the Access Policy Manager. |
| 4. |
| 5. |
| 6. | Verify that the Node Secret Created check box is cleared, if it is currently checked. |
| 7. | Check the Open to All Locally Known Users check box. |
| 8. | Check the Search Other Realms for Known Users check box. |
| 9. | Click the Requires Name Lock check box. |
| 10. | Clear any selection from the check boxes Enable Offline Authentication, Enable Windows Password Integration, and Create Verifiable Authentication. |
| 11. | Click OK. |
| 12. | Click the Agent Host tab, and select the Generate Configuration Files item. The Generate Configuration File screen opens. |
| 13. | Select the One Agent Host option, and then select from the list the Access Policy Manager agent host you just configured. |
| 15. | Click OK. |
| 16. | Add users who are authorized to use the Access Policy Manager. For more information on how to do this, refer your RSA Native SecurID authentication server administrator guide. |
Configuring the Access Policy Manager to use the RSA Native SecurID authentication server
After you add the Access Policy Manager as an agent host to your RSA Native SecurID authentication server, you can configure the Access Policy Manager to use the authentication server as part of your authentication process.
To configure the Access Policy Manager to use the RSA Native SecurID authentication server
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The New Server General Properties screen opens. |
| 2. | In the Name box, type the name for your AAA server. |
| 3. | In the Type box, select the SecurID option as your AAA server type. The screen refreshes to show configure options for SecurID. |
| 4. | In the Configuration section, for the Agent Host IP Address (must match the IP address in SecurID Configuration File), if there is a NAT device in the network path between the Access Policy Manager and the RSA SecurID server, type the address as translated by the NAT device. Otherwise, select the IP address from among those configured on the Access Policy Manager. In all cases, this IP address must match the SourceIP address in the IP packets received by the RSA SecurID server. |
| 5. | For the Configuration File, browse to upload the sdconf.rec file from your authentication server. Consult your RSA Authentication Manager administrator to obtain this file. |
| 6. |
Important: You must rename the configuration file to sdconf.rec and copy it to the Access Policy Manager before you can use the command line interface commands to configure RSA Native SecurID. Then, you add the SecurID server as you would add any AAA server. Remember that the server name must be the directory name to which the configuration file was copied to.
Setting up RSA Native SecurID authentication and authorization access policy action item
To complete the authentication process, you must add the RSA Native SecurID action to an access policy.
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | On the Access Profiles list screen, click the name of your profile. The Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 SecurID and click Add item. The RSA SecurID object popup opens in the visual policy editor. |
| 7. | On the Properties tab, select the name of your RSA SecurID server from the AAA Server list, and click Save. |
| 8. | Click Activate Access Policy to save your configuration. The SecurID server is added to the access policy, and is now a part of the overall authentication process. |
You can authorize your users with user information provided by the RSA Native SecurID authentication 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.
The RSA Native SecurID access policy action automatically creates the session variables, as shown in Table 11.12.
| Provides the result of the RSA Native SecurID authentication. The available values are: 0:Failed 1:Passed | |
| $attr_name is a value that represents the users attributes received during RSA Native SecurID authentication. Each attribute is converted to separate session variables. |
| 1. |
| 2. | Click an active session ID. The Properties screen opens. |
| 3. | Scroll down the list of session variables until you see the RSA Native SecurID session variables. |
The Access Policy Manager provides two default rules for the RSA Native SecurID access policy action. You use these rules to organize your users into the following two categories:
| RSA SecurID passed: These users were authenticated successfully and are able to access their webtop. |
| RSA SecurID not passed: 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 7, Creating Access Profiles and Access Policies.
You may run into problems with RSA Native SecurID authentication in some instances. You can view specific error messages concerning authentication in the /var/log/apm file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click Access Policy.
Setting up Access Policy Manager for LDAP authentication and authorization
The Access Policy Manager can authenticate using any LDAP database, including a Windows Active Directory.
You can use an LDAP-protocol-based directory, including an Active Directory, to authenticate users. In this case, you do not store user information on the Access Policy Manager. Instead, you obtain it from the LDAP entry.
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The New Server General Properties screen opens. |
| 2. | Type a name for your AAA server and select RADIUS from the Type list. The screen refreshes to provide additional settings specific to the LDAP Type. |
| 3. | Fill in the required fields. You can find details for each setting in the online help. For Admin DN, enter the value in this format: CN=administrator,CN=users,DC=sales,DC=mycompany,DC=com. |
| 4. |
Note: If your LDAP directory allows anonymous query, you do not need to specify an administrative 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 Access Policy Manager.
To use LDAP authentication, you must specify the authentication type as LDAP Auth from the visual policy editor. Additionally, you need specific information from your LDAP server administrator.
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | In the Access Profiles list screen, click the name of your profile. The Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 Auth, and click Add item. The LDAP object popup opens in the visual policy editor. |
| 7. | On the Properties tab, select the name of your LDAP server from the AAA Server list, and click Save. |
| 8. | Specify information for the SearchFilter and SearchDN settings. For more information about these settings, refer to Specifying SearchFilter and SearchDN settings. |
| 9. | Specify information for the UserDN setting. This step is required only if you do not use the SearchDN setting with the SearchFilter setting. For more information about the UserDN setting, refer to Specifying UserDN setting. |
| 10. | Enable the Show Extended Error option. This displays comprehensive error messages generated by the authentication server to display on the users Logon page. We recommend enabling this setting only in a testing or debugging environment. Otherwise, your system might be vulnerable to malicious attacks. |
| 11. | 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. |
| Set this value to be greater than 1, and a logon page reappears for the user after a log on failure. |
| Set this value to 1, and no logon retry is allowed. The available range is 1-5, with 3 set as the default value. |
| 12. | Click Activate Access Policy to save your configuration. The SecurID server is added to the access policy, and is now a part of the overall authentication process. |
The Access Policy 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.
Depending on the LDAP structure, a Search base DN would be similar to the following string:
dc=sales, dc=mycompany, dc=com
In an LDAP structure, a Search filter would be similar to the following string: sAMAccountName=%{session.logon.last.username}.
dc=sales, dc=mycompany, dc=com
In an LDAP structure, a Search filter would be similar to the following string: sAMAccountName=%{session.logon.last.username}.
By default, all user attributes are loaded if the administrator does not specify any required attributes. However, if the administrator specifies certain user attributes, then only those specified attributes are loaded, which improves performance on the LDAP server.
The Access Policy Manager attempts to bind with the LDAP server using the supplied DN and user-entered password. If the bind succeeds, that is, authentication succeeds, the user is validated. If the bind fails, the authentication fails.
This value 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=sales, dc=com.
This value 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=sales, dc=com.
Access Policy Manager supports using session variables in the SearchFilter, SearchDN, and UserDN fields. For example, if you want to use the users CN from the users SSL certificate as input in one 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.
To complete the authentication process, you must add the LDAP Query action to an access policy.
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | On the Access Profiles list screen, click the name of your profile. The Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 Query, and click Add item. The LDAP object popup opens in the visual policy editor. |
| 7. | On the Properties tab, select the name of your LDAP server from the AAA Server list, and click Save. |
| 8. | Specify information for the SearchFilter and SearchDN settings. For more information about these settings, refer to Specifying SearchFilter and SearchDN settings. |
| 9. | Enable the Fetch Nested Groups option. For more information on nested groups, refer to Understanding nested groups. |
| 10. | Enable the Required Attributes (optional) . By default, all user attributes are loaded if you do not specify any required attributes. However, if you specify certain required attributes, then only those specified attributes are retrieved from the LDAP server, which will improves system performance. |
| 11. | 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. |
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 | |
| $attr_name is a value that represents the users attributes received during LDAP authentication/query. Each attribute is converted to separate session variables. | |
| 1. |
| 2. | Click an active session ID. The Session Summary screen opens. |
| 3. | Scroll down the list of session variables until you see the LDAP session variables. |
The Access Policy Manager provides two default rules for the LDAP authentication access policy action. You use these rules to organize your users into 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. |
To view these default rules, refer to Example: Using LDAP query and LDAP authentication to authenticate and authorize users.
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 7, Creating Access Profiles and Access Policies.
There is an existing default rule for LDAP query called User Group Membership, but you must modify it to make it work properly.
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. |
| 3. | On the visual policy editor screen, click the LDAP Query access policy action item. The Properties screen of the visual policy editor opens. |
| 4. | Click the Branch Rules tab. |
| 5. | On the Branch rules screen, click the change link next to the default rule User Membership Group. |
User is a member of CN=MY_GROUP, CN=USERS, CN=MY_DOMAIN
| 7. | Click Finish to update the rule and return to the LDAP Query properties. |
| 8. | Click Save to update the LDAP Query properties and return to the access policy. |
Note: This is an example of how to update the default rule. Alternatively, you can change both the expression type and value and add other rules.
Example: Using LDAP query and LDAP authentication to authenticate and authorize users
Figure 11.1 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.
Figure 11.1, following, displays an example of default rules created for both LDAP authentication and query.
Figure 11.1 Customized rule for LDAP query
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 16, Advanced Topics in Access Policies.
Figure 11.2 Authenticating against an external LDAP server
To troubleshoot LDAP authentication or query issues, you can view specific error messages in the /var/log/apm file. Or from the navigation pane, expand Systems, click Logs, and on the menu bar, click Access Policy.
Tip: Make sure that your log level is set to the appropriate level. The default log level is notice. Refer to Chapter 17, Logging and Reporting, for more information on how to use the logging feature.
Additionally, you can look into the session reports for information on users logon attempts. In the navigation pane, expand Access Policy, choose Reports, and click the active session ID to see all the session variables.
| The target LDAP server host/port information associated with the LDAP Auth agent may be invalid. | |
| The target LDAP server host/port information associated with the LDAP Query agent may be invalid. If the LDAP Query is successfully, then check whether the LDAP Query Rules are properly configured. |
Refer to Table 11.15 for steps on how to ensure that a connection is successfully made between the Access Policy Manager and your authentication server, and that your authentication method is working properly.
| Check that your access policy is attempting to perform authentication | Refer to the message boxes in your access policy to display information on what the access policy is attempting to do. Refer to /var/log/apm file to view authentication attempts by the access policy. Note: Make sure that your log level is set to the appropriate level. The default log level is notice. Refer to Chapter 17, Logging and Reporting, for more information on how to use the logging feature. |
| Access the Access Policy Manager through the command line interface and check your connectivity by pinging the LDAP server using the host entry in the AAA Server box. Confirm that the LDAP port 389 is not blocked between the Access Policy Manager and the LDAP server. | |
| Verify that the administrative credentials are correct on the LDAP server, and that they match the credentials used by the AAA entry. Note: A good test is to use full administrative credentials with all rights. If that works, you can use less powerful credentials for verification. | |
| Use the tcpdump utility from the Access Policy Manager when authentication attempts are made. For example, %tcpdump-i 1.1 -s /tmp/dump. You must first determine what interface the self IP is on. The tcpdump records indicate activities between the Access Policy Manager and the authentication server. Run the authentication test. After authentication fails, stop the tcpdump, and download the tcpdump to a client system, and use an analyzer to troubleshoot. Important: If you decide to escalate the issue to Customer Support when you encounter authentication issues that you cannot otherwise resolve on your own, you must provide the output of running the tcpdump utility. |
Setting up Access Policy Manager for Windows Active Directory authentication and authorization
Setting up Windows Active Directory authentication and authorization involves the following tasks:
| Configure Access Policy Manager to set up an Active Directory server for authentication |
| Configure Access Policy Manager to access Active Directory authentication policy action item |
| Configure Access Policy Manager to access Active Directory query policy action item |
Configuring Access Policy Manager to set up an Active Directory for authentication
The first task for setting up Active Directory authentication is to set up an Active Directory server.
We highly recommend that you configure an NTP Server. The reason is that the time on your Access Policy Manager and the time on your domain controller need to be within 5 minutes of each other. Otherwise, authentication will fail. In 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. In the navigation pane, expand System, click General Properties, and from the Device menu, choose DNS.
If you do not have an NTP server, find the time on your domain controller, and set the time on the Access Policy Manager to be within 5 minutes of that time using the date command. To enter a new date/time, type the command: date MMDDHHmmYYYY,
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 domain controller says it is November 7, 2007 8:24a.m., you would type:
date 110708242007
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 domain controller says it is November 7, 2007 8:24a.m., you would type:
date 110708242007
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The New Server General Properties screen opens. |
| 2. | Type a name for your AAA server and select Active Directory from the Type list. The screen refreshes to provide additional settings specific to the Active Directory Type. |
| 3. | Fill in the required fields. You can find details for each setting in the online help. This adds the new Active Directory server to the AAA Servers List. |
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.
Access Policy Manager supports password management for Active Directory authentication. This works in the following order:
| Access Policy Manager uses the clients user name and password to authenticate against the Active Directory server on behalf of the client. |
| If the clients user password on the Active Directory server has expired, Access Policy Manager returns a new logon page back to the client, requesting that the client change its password. |
| After the client submits the new password, Access Policy Manager attempts to change the password on the Active Directory server. |
If the password change fails, it is likely that the Active Directory server rejected it because the password did not meet the minimum requirements such as password length.
Note: By default, users are given only one attempt to reset their password. However, an administrator can configure the max logon attempt allowed of the authentication agent to a value larger than 1, which gives users multiple opportunities to reset their passwords.
Configuring Access Policy Manager to access the Active Directory for authentication
To use Active Directory authentication, you must specify the authentication type as AD Auth in the visual policy editor. Additionally, you need specific information from your Active Directory server administrator.
To configure Access Policy Manager to access the Active Directory policy action item for authentication
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | On the Access Profiles list screen, click the name of your profile. The Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 AD Auth, and click Add item. The Active Directory object popup opens in the visual policy editor. |
| 7. | Specify information for the UserPrincipalName setting. This allows the administrator to enforce the user to enter the username in the UPN naming style, and to use the domain name from the user-specified UPN for authentication. For example, user@domain. |
| 8. | Enable the Show Extended Error option. This displays comprehensive error messages generated by the authentication server to display on the users Logon page. We recommend enabling this setting only in a testing or debugging environment. Otherwise, your system might be vulnerable to malicious attacks. |
| 9. | 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. |
| Set this value to be greater than 1, and a logon page reappears for the user after a log on failure. |
| Set this value to 1, and no logon retry is allowed. The available range is 1-5, with 3 set as the default value. |
| 10. | Click Activate Access Policy to save your configuration. The Active Directory server is added to the access policy, and is now a part of the overall authentication process. |
Configuring Access Policy Manager to access the Active Directory action item for query
To use Active Directory query, you must specify the authentication type as Query and then use the appropriate Active Directory server.
This feature 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 configure Access Policy Manager to access Active Directory action item for query
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | On the Access Profiles list screen, click the name of your profile. The Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 AD Query, and click Add item. The LDAP object popup opens 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. | Specify information for the SearchFilter setting. For more information about these settings, refer to Specifying SearchFilter and SearchDN settings. |
| 9. | Enable the Fetch Primary Group option. This adds the users primary group settings to the memberOf session variable. Additionally, sub-groups from the users primary group are added to the memberOf session variable if the nested group feature variable is enabled. For example, user@domain. |
| 10. | Enable the UserPrincipalName option. This allows the administrator to enforce the user to enter their username in the UPN naming style, and to use the domain name from the user-specified UPN for authentication. For example, user@domain |
| 11. | Enable the Fetch Nested Groups option. For more information on nested groups, refer to Understanding nested groups. |
| 12. | Enable the Required Attributes (optional). By default, all user attributes are loaded if you do not specify any required attributes. However, if you specify certain required attributes, then only those specified attributes are retrieved from the LDAP server, which will improves system performance. |
| 13. | 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. |
Tip: Both DNS forward and reverse lookup of the domain name processes should work properly to ensure that the domain name resolves to the IP address of the domain controller, and the reverse address resolves to the domain name.
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.
The Active Directory access policy action automatically creates the session variables, as shown in table 11.16.
| Session Variable for Active Directory Authentication and Query | |
| Provides the result of Active Directory authentication/query. The available values are: 0:Failed 1:Passed | |
| $attr_name is a value that represents the users attributes received from the 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 Active Directory server. Each attribute is converted to separate session variables. |
| 1. |
| 2. | Click an active session ID. The Session Summary screen opens. |
| 3. | Scroll down the list of session variables until you see the Active Directory session variables. |
To troubleshoot Active Directory authentication or query issues, you can view specific error messages in the /var/log/apm file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click Access Policy.
Tip: Make sure that your log level is set to the appropriate level. The default log level is notice. Refer to Chapter 17, 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. In the navigation pane, expand Access Policy, click Reports and on the screen, click the active session ID to see all the session variables.
| Domain controller reply did not match expectations, (-1765328237) | This error occurs when the principal/domain name does not match with the domain controller servers database. For example, if the actual domain is SALES.MYCOMPANY.COM", and the administrator specifies STRESS as the domain, then the krb5.conf file displays the following, So, when the administrate tries to authenticate with useraccount@SALES, the krb5 library notices that the principal name SALES differs from the actual one in the server database. |
Refer to Table 11.18 for steps on how to ensure that a connection is successfully made between the Access Policy Manager and your authentication server, and that your authentication method is working properly
| Check to see if your access policy is attempting to perform authentication | Refer to the message boxes in your access policy to display information on what the access policy is attempting to do. Refer to the /var/log/apm file to view authentication attempts by the access policy. Note: Make sure that your log level is set to the appropriate level. The default log level is notice. Refer to Chapter 17, Logging and Reporting, for more information on how to use the logging feature. |
| Access the Access Policy Manager through the command line interface and check your connectivity by pinging the Active Directory server using the host entry in the AAA Server. Confirm that the Active Directory port 88 or 389 is not blocked between the Access Policy Manager, and the Active Directory server. | |
| Check the Active Directory Server Configuration | Confirm that the Active Directory server name can be resolved to the correct IP address, and that the reverse name resolution (IP address to name) is also possible. Confirm that the Active Directory server and the Access Policy Manager have the correct time setting configured. Note: Since Active Directory is sensitive to time settings, we suggest that NTP be used to set the correct time on the Access Policy Manager. |
| Use the tcpdump utility from the Access Policy Manager when authentication attempts are made. For example, use the command %tcpdump-i 1.1 -s /tmp/dump. You must first determine what interface the self IP address is on. These TCP dumps indicate activities between the Access Policy Manager and the authentication server. Run the authentication test. After authentication fails, stop the tcpdump, and download the output to a client system and use an analyzer to troubleshoot. Important: If you decide to escalate the issue to Customer Support when you encounter authentication issues that you cannot otherwise resolve on your own, you must provide the output of running the tcpdump utility. |
Example: Authenticating and authorizing users with Active Directory query and authentication
Figure 11.3 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.
Figure 11.3 Example of authenticating and authorizing users with Active Directory query and authentication
The nested group feature is used to identify all groups that the user belongs to. Access Policy Manager stores all such groups in the memberOf session variable. For example, if user1 is a member of group 1 and group 2, and group 1 is a member of group 3 and group 4, then user1 belongs to all of these groups. In addition, group 3 and group 4 privileges are nested by user1 through group 1.
If the nested group feature is disabled on the Access Policy Manager, then the memberOf session variable contains only groups the user belongs to directly, for instance, group 1 and group 2.
If the nested group feature is enabled on the Access Policy Manager, then the memberOf session variable contains all groups the users belongs to, which include group 1, group 2, group 3, and group 4.
Note: The nested groups feature works slightly differently for both LDAP and Active Directory. If you want to use nested groups for Active Directory query, you can also use it in conjunction with, or independently from, Fetch Group Attribute.
The table, following, displays the results of your Active Directory query if nested groups is used in conjunction with Fetch Group Attributes.
| Fetch Nested Group | ||
| This setting queries all groups the user belongs to. This includes the users memberOf groups which include the users primary group, and groups nested through all membersOf groups. | ||
| This setting queries the users memberOf groups plus the primaryGroupDN. However, it does not query any nested groups. | ||
| This setting queries the users memberOf groups, including the nested groups through the memberOf groups. However, the primaryGroupDN is not queried. | ||
| This setting queries the users memberOf group only. This means that only the groups with which users are directly associated are queried. |
Setting up Access Policy Manager for HTTP authentication
You configure Access Policy Manager to use an external, web-based authentication server if you choose to use the HTTP basic authentication method. This authentication method uses external web-based authentication servers to validate user logons IDs and passwords.
Basic authentication requires a valid URL resource. The URL resource must respond with a challenge to a non-authenticated request, and the basic authentication method supports authentication over both HTTP and HTTPS protocols.
Note: F5 Networks strongly recommends using HTTPS because basic authentication passes user credentials as clear text. However, to support HTTPS authentication, Access Policy Manager must be set up and configured through a layered virtual. For more information, refer to HTTPS basic authentication
To configure Access Policy Manager to use an external server for HTTP basic authentication
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The AAA Server screen opens. |
| 2. | Type a name for your AAA server and select HTTP from the Type list. The screen refreshes to provide additional settings specific to the HTTP Type. |
| 3. | For the Auth Type setting, select Basic/NTLM. The screen refreshes to display only the option that is specific to HTTP |
| 4. | In the Start URL box, type the complete URL that returns the logon form. |
| 5. | Click Finished. |
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 entered.
To support HTTPS basic authentication, you must configure Access Policy Manager through a layered virtual server.
| Create a AAA server for the HTTPS server, and create an access profile using the HTTP agent. |
| Create a new node for the HTTPS server that performs the HTTPS authentication. |
| Create a new virtual server for HTTPS which will perform authentication, and assign the access policy to the virtual server. |
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The AAA Server screen opens. |
| 2. |
| 3. |
| 4. | In the Start URI setting, type in your URI resource, such as http://plum.tree.lab2.sp.companynet.com/. |
| 5. | Click Finished. |
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List opens. |
| 2. | Locate the access policy you just created, and click the Edit link. The visual policy editor screen opens in a separate browser. |
| 3. | Add the HTTP agent to your access policy, and make sure you select the virtual HTTP server you created. This is important so that the HTTPS traffic goes through the virtual server. |
| 4. |
To create a new node for the server that performs the HTTPS authentication
| 1. |
| 2. |
| 3. |
| 1. |
| 2. |
| 3. | In the Name box, type a name of your pool. |
| 4. | In the Address under Resources, type in the IP address, and select https from the list. The service port should automatically display port 443. |
| 5. |
| 6. | Clicked Finished. |
| 1. | In the navigation pane, expand Local Traffic, and click Virtual Server List. The Virtual Server List screen opens. |
| 2. |
| 3. | Type in a Name, Destination, and Service port. The destination address is the virtual server IP address used as the external HTTPS authentication server in HTTPS server configuration. The service port should be 80. |
| 4. | From the SSL Profile (Server) list, select serverssl. This ensures that there is an SSL connection between the HTTP virtual server and the external HTTPS server. |
| 5. | In the Resources area, from the Default Pool list, make sure to select the name of the pool you previously created. |
| 6. | Under the virtual server resource (Load Balancing: Default Pool) select the pool you created for the HTTPS server. |
| 7. | In the navigation pane, click Local Traffic, point to Virtual Servers, and choose Virtual Address List. |
| 8. | Select the new servers IP address from the list. The Configuration screen opens. |
| 9. | Clear the ARP check box to disable ARP for the new virtual server. |
NTLM employs a challenge-response mechanism for authentication, where clients are able to prove their identities without sending a password to the server.
To configure Access Policy Manager to use an external server for HTTP NTLM authentication
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The AAA Server screen opens. |
| 3. |
| 4. |
| 5. | For the Start URL setting, type the complete URL that returns the logon form. Make sure to include the protocol (HTTP or HTTPS), server, and port. |
| 6. | Click Finished. |
When the system detects the starting URL match or the logon form page, the cached users identity is leveraged in order to construct and send the HTTP form-based post request on behalf of the user.
To configure Access Policy Manager to use an external server for HTTP form-based authentication
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The AAA Server screen opens. |
| 3. |
| 4. |
| 5. | For the Form Method setting, select either GET or POST. By default, the form method value is POST. If you specify GET, then the authentication request is converted as HTTP GET. |
| 6. | For the Form Action setting, type the complete destination URL use for authentication. |
| 7. | In the Form Parameter for both User Name and Password, type the parameter names and password used by the form you are sending the POST request to. An example of a user name is USER, and a password example is PASSWORD. |
| 8. | In the Hidden Form Parameters/Values box, type the hidden form parameters required by the authentication server logon form at our location. For more information on how to determine hidden parameters and values, refer to Determining the hidden parameters, following. |
| 9. | In the Number Of Redirects To Follow box, type the number of pages away from the landing page the request should travel before failing. |
| 10. | In the Successful Logon Detection Match Type box, choose the method your authenticating server uses, and specify the option definition. For example, if you select the By Presence Of A Specific Cookie option, the next field changes to Cookie Name. As an example, enter a cookie name, such as SMSESSION. |
| 11. | The Success Logon Detection Value setting populates to whatever method you selected for the Successful Logon Detection Type setting. |
One of the requirements to set up HTTP form-based authentication is to provide hidden form parameters and values, as indicated in Step 8 above.
The hidden parameters and values are required by the authentication server logon form at your location.
| 3. |
| 4. | Type the name and value of each hidden parameter in the text box, in the format NAME VALUE, using a separate line for each parameter. For example: SMAUTHREASON- 0 SMAGENTNAME $SM$K36kRZMqrZGtQof83Lsss6NdinGFhuoOAUmTkUffmhFUhmA%2bHwBxZja%3d TARGET http://sales.example.com SMENC ISO-8858-1 SMLOCALE US-EN POSTPRESERVATIONDATA |
You configure Access Policy Manager to use Oracle Access Manager (OAM) server for authentication and authorization to eliminate the need of deploying a WebGate proxy in front of each application. In addition, you can achieve SSO functionality for HTTP/HTTPS requests passing through a virtual to a backend web application. For more information on how to configure OAM as the SSO method type, refer to chapter 13 About External Access Management.
Setting up Access Policy Manager for AAA high availability
The Access Policy Manager supports access policies configured for RADIUS and LDAP.
Generally, if the BIG-IP system loses connectivity to the authentication server, new authentications will fail. (Existing sessions are unaffected as long as they do not attempt to re-authenticate.)
AAA High Availability provides a mechanism to alleviate the problem. It allows you to configure multiple authentication servers to process the requests. If one goes down or loses connectivity, the others can resume authentication requests, and new sessions can be established, as usual.
| Set up server pools. These contain the server addresses that are used in AAA high availability. |
| Set up dummy virtual servers. These servers serve as the front-end address for the backend servers. |
| Set up an AAA server object using the dummy virtual server for the server address. You configure an action in your access policy to use this object. |
These tasks apply to the authentication servers that Access Policy Manager supports (RADIUS and LDAP).
You can set up AAA high availability for RADIUS and accounting services to ensure that services to the Access Policy Manager are not affected if one of the AAA servers goes down for any reason.
| 1. |
| 2. |
| 3. | Type a descriptive name for your pool. For example, RADIUSAuthenticationPool. |
| 4. | For the Health Monitors setting, select gateway_icmp, and click the more button (<< ) to add it to the Active list. This lets the BIG-IP system know when the servers are active or inactive. |
| 5. | Optionally, in the Resources area, enable the Priority Group Activation by selecting Less than from the list. |
| 6. | For the New Members setting, in the Address box, type in the IP address for your RADIUS server, the Service Port (1812), and a Priority level. |
| 7. | Repeat steps 1-6 for each RADIUS server you wish to add, and then click the Add button. Each IP address of the RADIUS server should appear in the New Members table. |
| 8. | Click Finished. |
Important: You will need to add a second server pool for RADIUS accounting. You add this the same way as the authentication pool. However, instead of using port 1812, use port 1813 since that is the default RADIUS accounting port.
| 1. | In the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Server screen opens. |
| 2. |
| 3. | In the Name box, type in a name for your dummy virtual server. |
| 4. |
| 5. | In the General Properties area, in the Address box, type a loopback address. We recommend that you use an unroutable IP address. |
| 6. |
| 7. |
| 8. |
| 1. |
| 2. |
| 3. | On the menu bar, click the Resources tab. |
| 4. | For Default Pool, select the server pool you created. |
| 5. | Click Update to save your information. |
Important: You will need to create a second virtual server, using the same procedure for RADIUS accounting. Remember to use port 1813.
| 1. | In the navigation pane, expand Access Policy, and click the [+] sign next to the AAA Servers to add a new server. The AAA Server screen opens. |
| 2. |
| 3. | In the Name box, type a name for your RADIUS server. |
| 4. |
| 5. |
| 6. | Enter the dummy virtual host and port information for both authentication and accounting. |
| 7. | Enter the Secret information and confirm it. This needs to be the same on both servers. Additionally, both servers must have the self IP address of the BIG-IP system. |
| 8. |
To effectively test that AAA high availability works for RADIUS, you should have two RADIUS servers that are accessible, where you can remove one of them from the network.
| 1. | Begin a TCPDump on the Access Policy Manager device, using a protocol analyzer, and scanning for packets destined for port 1812. |
| 3. | Verify using the TCP dump that the requests are being sent to the higher priority server. |
| 8. | Log out again, re-enabling the server, and try one more time to verify that the new requests are being sent to the high priority server again. |
You can set up AAA high availability for LDAP servers for LDAP authentication and LDAP query. These servers must serve the same domain. Ideally, the servers should belong to the same server farm, with one being the backup for the other server. However, they can also be both primary servers that serve the domain. For that particular setup, users must be updated on each system individually.
| 1. |
| 2. |
Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a custom monitor.
| 4. |
| 5. | For Import Settings, select a monitor; the default is ldap. By selecting a monitor, you copy its settings, after which you can modify them. |
| 6. |
| You must enter a value for the Base field to specify the location (base DN) in the LDAP tree at which the monitor starts the search. The base DN and all of its subtrees will be searched for the requested object. For example, if the base value is set to dc=bigip-test,dc=net, the search will include the entire bigip-test subtree branch. |
| Although the Filter setting is not mandatory, you should enter a value to effectively limit the scope of the search. The filter setting defines how each entry in the search scope will be evaluated for a match. For example, objectClass=person will match entries corresponding only to persons listed in the directory. |
| 8. | Click Finished. |
| 1. |
| 2. |
| 3. | Type a descriptive name for your pool. For example, LDAPAuthenticationPool. |
| 4. | For the Health Monitors setting, select the LDAP health monitor that you previously created from the Available list, and click the (<< ) button to move it to the Active list. This lets the BIG-IP system know when the servers are active or inactive. |
| 5. | Optionally, under the Resources area, enable Priority Group Activation by selecting Less than from the list. |
| 6. | For the New Members setting: |
| In the Address box, type in the IP address for your LDAP server. |
| If you enabled Priority Group Activation, set Priority level. |
| 7. | Repeat steps 1-6 for each LDAP server you wish to add, and then click the Add button. Each IP address of an LDAP server should appear in the New Members list. |
| 8. | Click Finished. |
Virtual servers act as the front-end address for the backend servers that are in the server pool.
| 1. | In the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Server screen opens. |
| 2. |
| 3. | In the Name box, type a name for your dummy virtual server. |
| 4. | For the Destination setting, under General Properties, in the Address box, enter a loopback address. We recommend that you use an unroutable IP address. |
| 5. |
| 6. | In the Resources area, from the Default Pool list, select the name of the server pool you previously created. |
| 7. | Ensure that Protocol is set to the default value TCP. |
| 8. |
| 1. |
| 2. |
| 3. | In the Name box, type a name for your LDAP server. |
| 4. |
| 5. | For Host, type the IP address of the virtual server you previously created. |
| 6. |
| 7. |
You can configure either LDAP Auth or LDAP Query or both actions. Use the LDAP Auth action for authentication. Use the LDAP Query action to ask for user attributes.
| 1. | In the navigation pane, expand Access Policy, and click Access Profiles. The Access Profiles List screen opens. |
| 2. | On the Access Profiles list screen, click the name of your profile. The Properties screen opens. |
| 3. |
| 4. | For the Visual Policy Editor setting, 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 either LDAP Auth or LDAP Query, and click Add item. An LDAP object popup opens in the visual policy editor. |
| 7. | On the Properties tab from the AAA Server list, select the name of AAA LDAP server that you previously created. |
| 8. | Enter information in any other required fields. You can find details for each setting in the online help. |
| 9. | Click Activate Access Policy to save your configuration. |
To effectively test that AAA high availability works for LDAP, you should have two LDAP servers that are accessible, where you can remove one of them from the network.
| 1. | Begin a TCP dump on the Access Policy Manager device, using a protocol analyzer, and scanning for packets destined for port 88. |
| 3. | Verify with the TCP dump that the requests are being sent to the higher priority server. |
| 8. | Log out again, re-enable the server, and try one more time to verify that the new requests are being sent to the high priority server. |
Search AskF5
- Supported Products
- BIG-IP LTM / VE
- BIG-IP AFM / VE
- BIG-IP Analytics / VE
- BIG-IP APM / VE
- BIG-IP ASM / VE
- BIG-IP Edge Gateway / VE
- BIG-IP GTM / VE
- BIG-IP Link Controller
- BIG-IP PEM / VE
- BIG-IP PSM / VE
- BIG-IP WebAccelerator / VE
- BIG-IP WOM / VE
- ARX / VE
- ARX Cloud Extender
- Data Manager
- Enterprise Manager / VE
- F5 Monitoring Pack
- FirePass / VE
- BIG-IQ Cloud
- BIG-IQ Security
- BIG-IP Edge Apps
- End-of-Life Products
- Recent Additions
- About AskF5
