Applies To:

Show Versions Show Versions

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

11 
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 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 Access Policy Manager should match your local network. That is, you should use equally high standards for the Access Policy 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 Policy, and click AAA Servers.
There are two types of authentication as they 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.
Auth and Query 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.
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 RADIUS authentication.
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.
User-Name: This indicates the name of the user to be authenticated.
User-Password: This indicates the password of the user to be authenticated
NAS-IP-Address: This indicates the identifying IP Address of the NAS.
Service-Type: This indicates the type of service the user has requested.
NAS-Port - This 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, it is assumed 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 whether or not network access is initiated or terminated by sending the RADIUS accounting start and stop messages, though the radius accounting start message doesn't mean the actual network access will be successfully established. If 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 they are 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 of 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 for which the user session was active.
The following are specific RADIUS accounting attributes that the Access Policy Manager sends for RADIUS Accounting-Request (start message) and RADIUS Accounting-Request (stop message).
Attributes for start message include the following:
User-name: This is the name of authenticated user.
Acct-Session-Id: This is 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.
Acct-Status-Type: This indicates whether the Accounting-Request marks the beginning of the user service (Start) or the end (Stop).
Acct-Authentic: This indicates how the user was authenticated, whether by RADIUS, the NAS itself, or by another remote authentication protocol.
Service-Type: This indicates the type of service the user has requested.
Nas-IP-Address: This identifies the IP Address of the NAS which is requesting authentication of the user. The administrator can enter this address on the AAA RADIUS server configuration page.
NAS-Port: This is the physical port number of the NAS which is authenticating the user. It is always set to 0.
Tunnel-Client-Endpoint: This contains the IP address of the initiator end of the tunnel.
Class: This is available to be sent by the server to the client in an Access-Accept. The administrator can make resource assignments using this attribute.
Attributes for stop messages include the following:
Acct-Terminate-Cause: This indicates how the session was terminated. In Access Policy Manager, we support 3 values for this attribute:
Acct-Session-Time: This indicates how many seconds the user has received service for.
Framed-IP-Address: This indicates the address to be configured for the user.
Acct-Input-Octets: This indicates how many octets have been received from the port over the course of the service provided.
Acct-Output-Octets: This attribute indicates how many octets are 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 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
1.
On the navigation pane, expand Access Policy, and click AAA Servers.
The AAA Server List screen opens.
2.
Click Create.
The General Properties screen opens.
3.
5.
Enter the information in the required fields (marked with a vertical blue line) 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 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.
1.
On the navigation pane, expand Access Policy, and click Access Profiles.
The Access Profiles List 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 Auth and click Add item.
The RADIUS Auth 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.
Displays the error message for the last login. If session.radius.last.result is set to 0, then session.radius.last.errmsg may be useful for troubleshooting purposes.
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 Access Policy Manager provides two default rules for the RADIUS 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. 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. Note 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/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.3 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.
SSH to the Access Policy Manager and check your connectivity by pinging the RADIUS server using the host entry in the AAA Server box.
Confirm that the RADIUS port 1812 is not blocked between the Access Policy Manager and the RADIUS server.
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.
Take a tcpdump 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. These tcpdumps indicate activities between the Access Policy Manager and the authentication server.
Run the authentication test. After authentication fails, stop the tcpdump, download the tcpdump to a client system, and use an analyzer to troubleshoot.
Important: Since it is required that you provide a tcpdump, should you decide to escalate the issue to Customer Support, we highly recommend that you take a capture of the tcpdump when you encounter authentication issues that you cannot otherwise resolve on your own.
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 Secure ID feature checklist over RADIUS protocol.
Troubleshooting RSA SecurID on Windows using RADIUS configuration
If you are having difficulty authenticating using RSA SecurID over RADIUS on the authentication server that is running RSA SecurID server, 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.
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 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.
Hostname
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.
1.
On the navigation pane, expand Access Policy, and the (+) sign next to AAA Servers.
The New Server List page opens.
2.
Click Create.
The General Properties page opens.
3.
In the Name field, type the name for your AAA server.
4.
In the Type field, select the RADIUS option as your AAA server type.
The General Properties screen for RADIUS opens.
6.
In the Accounting Host field, type the IP address of your RADIUS accounting server.
7.
In the Accounting Service Port field, type the service port for your Accounting server. The default is 1813.
8.
In the Secret field, type the shared secret value or string used by both the RADIUS server configuration and the Access Policy Manager configuration.
9.
In the Confirmed Secret field, re-type the shared secret value or string.
10.
Click Finished
1.
On the navigation pane, expand Access Policy, and click Access Profiles.
The Access Profiles List screen opens.
2.
From the Access Profiles list, select the name of your profile.
The Properties screen opens. On the menu bar, click Access Policy.
The Access Policy screen opens.
3.
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.
4.
Click the small plus sign where you want to add the new access policy action item.
A properties screen opens.
5.
Under Authentication, select RADIUS ACCT and click Add item.
The RADIUS accounting object appears in the visual policy editor.
6.
From the Properties tab, select the name of your RADIUS accounting server from the AAA Server list, and click Save.
7.
Click Activate Access Policy to save your configuration.
The RADIUS accounting server is added as part of your access policy.
$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 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.
Check that the shared secret on the RADIUS is valid.
Check that the user credentials are entered correctly.
1.
On the navigation pane, expand Access Policy, and the (+) sign next to AAA Servers.
The New Server List page opens.
2.
Click Create.
The General Properties page opens.
3.
In the Name field, type the name for your AAA server.
4.
In the Type field, select the RADIUS option as your AAA server type.
The General Properties screen for RADIUS opens.
5.
To complete the authentication and accounting process, you must add the RADIUS authentication and accounting server to an access policy as an action item.
1.
On the navigation pane, expand Access Policy, and click Access Profiles.
The Access Profiles List screen opens.
2.
From the Access Profiles list, select the name of your profile.
The Properties screen opens. On the menu bar, click Access Policy.
The Access Policy screen opens.
3.
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.
4.
Click the small plus sign where you want to add the new access policy action item.
A properties screen opens.
5.
Under Authentication, select RADIUS Auth and click Add item.
6.
Now select RADIUS Acct and click Add item
The RADIUS authentication and accounting objects appear in the visual policy editor.
7.
From 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 RADIUS authentication and accounting server is added as part of your access policy.
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 pincode and a token provided to the user.
A token is a piece of hardware or software assigned to a computer that generates an authentication code at fixed intervals using a built-in clock and the cards seed.
Setting up RSA Native SecurID authentication and authorization involves the following tasks:
Note: Please refer to your RSA SecurID Implementation Guide for information on how to set up your 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 field, 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 field, 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.
5.
For Encryption Type, select DES.
6.
Clear the Node Secret Created check box, if it is currently checked and available.
7.
Click the Open to All Locally Known Users check box.
8.
Clear 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.
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.
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.
On the navigation pane, expand Access Policy, and the (+) sign next to AAA Servers.
The New Server screen opens.
2.
In the Name field, type the name of your server.
3.
In the Type field, select the SecurID option as your AAA server type.
5.
In the Configuration File field, browse to upload the sdconf.rec file from your authentication server.
Consult your RSA Authentication Manager administrator to obtain this file.
6.
Click Finish.
The new RSA server is added.
Note: Although it is possible to configure RSA Native SecurID through the command line interface, the configuration file must be renamed to sdconf.rec and copied to the Access Policy Manager before you can use the CLI commands to configure RSA Native SecurID. Then, 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.
To complete the authentication process, you must add the RSA Native SecurID authentication server to an access policy as an action item.
1.
On the navigation pane, expand Access Policy, and click Access Profiles.
The Access Profiles List 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 SecurID and click Add item.
The SecurID object appears in the visual policy editor.
7.
From the Properties tab, select the name of your authentication server from the AAA Server list, and click Save.
8.
Click Activate Access Policy to save your configuration.
The authentication 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 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.
$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.
On the navigation pane, expand Overview, and click Reports.
The Reports screen opens.
2.
Click an active session ID.
The Properties screen opens.
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.
RSA Native SecurID authentication is an important part of the access policy. To ensure that your users are authenticated, you must add the authentication server as an action item to the access policy.
Figure 11.2 shows an example of an access policy with all the elements associated to authenticate and authorize your users. Notice that the RSA native securid object was added to the access policy as part of the authentication process.
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
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.
On the navigation pane, expand Access Policy, and click AAA Servers.
The AAA Servers List screen opens
2.
Click the plus sign next to AAA Server to add a new server, or simply click the Create button.
The General Properties screen opens.
3.
4.
Enter the information in the required fields (marked with a vertical blue line). For Admin DN, enter CN=administrator,CN=users,DC=sales,DC=mycompany,DC=com, for example
5.
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 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.
On the navigation pane, expand Access Policy, and click Access Profiles.
The Access Profiles List 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 Auth, and click Add item.
The LDAP object appears.
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 Search DN settings.
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: APMAccountName=%{session.logon.last.username}.
By default, all user attributes are loaded if the admin does not specify any required attributes. However, if the admin specifies certain user attributes, then only those specified attributes are loaded, which improves performance on the LDAP server.
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 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.
10.
Show Extended Error: 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. 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 logon retry is allowed. The available range is 1-5, with 3 set as the default value.
Additionally, Access Policy 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 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.
1.
On the navigation pane, expand Access Policy, and click Access Profiles.
The Access Profiles List 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 Query, and click Add item.
The LDAP object appears.
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 SearchDN and Search Filter settings.
The Access Policy 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, depending 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}.
Fetch Nested Groups: allow the administrator to raise and lower the level of domain functions within the Active Directory hierarchy. Within an Active Directory there are usually a number of groups defined, with users belonging to one or more of these groups. One group is specified as the user's primary domain group. The administrator can map these Active Directory groups directly to existing Access Policy Manager resource groups. When a user attempts to log on the system, the Active Directory groups that the user belongs to are queried from the domain. For more information on nested groups, refer to Understanding nested groups.
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.
9.
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
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 Access Policy 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 7, Creating Access Profiles and Access Policies.
Although there is an existing default rule for LDAP query called User Group Membership, 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 Policy, 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 Query 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 a name for your new LDAP query rule, such as LDAP query has passed.
7.
For the Expression setting, click the change link.
A pop-up screen 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 11.3.
Figure 11.4 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.5 displays an example of default rules created for both LDAP authentication and 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.
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.
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.
Additionally, you can look into the session reports for information on users logon attempts. On the navigation pane, expand Overview, choose Reports, and click the active session ID to see all the session variables.
Refer to Table 11.10 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 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.
SSH into the Access Policy Manager 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.
Take a tcpdump 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. These tcpdumps 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: Since it is required that you provide a tcpdump, should you decide to escalate the issue to Customer Support, we highly recommend that you take a capture of the tcpdump when you encounter authentication issues that you cannot otherwise resolve on your own.
Setting up Access Policy Manager for Windows Active Directory authentication and authorization
1.
On the navigation pane, expand Access Policy and click AAA Servers.
The AAA Servers List screen opens.
2.
Click Create.
The 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) and click Finish.
The new Active Directory server is added to the AAA Server list.
Note: 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. 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.

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
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.
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.
On the navigation pane, expand Access Policy, and click Access Profiles.
The Access Profiles List 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.
The Properties screen opens.
6.
Under Authentication, select AD Auth and click Add item.
The Active Directory object appears in the visual policy editor.
7.
For the Server setting, select the name of your Active Directory server.
a)
UserPrincipalName: 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.
b)
Show Extended Error: displays comprehensive error messages generated by the authentication server to show 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.
c)
Max Logon Attempt Allowed: gives the user 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.
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.
1.
On the navigation pane, expand Access Policy, and click Access Profiles.
The Access Profiles List 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.
The Properties screen opens.
6.
Under Authentication, select AD Query and click Add item.
The Active Directory object appears in the visual policy editor.
7.
For the Server setting, select the name of your Active Directory server.
d)
SearchFilter: Allows the administrator to specify the search criteria to be used while querying Active Directory server for users information. Session variables are supported as part of search query string.For example, (sAMAccountName=%{session.logon.last.username})
e)
Fetch Primary Group: Adds the users primary group settings to the memberOf session variable. Additionally, subgroups from the users primary group are added to the memberOf session variable if the nested group feature variable is enabled.
f)
UserPrincipalName: 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..
g)
Fetch Nested Groups: Allow the administrator to raise and lower the level of domain functions within the Active Directory hierarchy. Within an Active Directory there are usually a number of groups defined, with users belonging to one or more of these groups. One group is specified as the user's primary domain group. The administrator can map the Active Directory groups directly to existing Access Policy Manager resource groups. When a user attempts to log into the system, the Active Directory groups that the user belongs to are queried from the domain. For more information on nested groups, refer to Understanding nested groups.
h)
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 Active Directory server, which improves system performance.
Tip: Both DNS forward and reverse lookup of the domain name 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.
session.ad.last.authresult
session.ad.last.queryresult
$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.
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/apm file. Or from the navigation pane, expand System, click Logs, and on the menu bar, click 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.
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.
Domain controller reply did not match expectations, (-1765328237)
This error occurs when the principal/domain name doesnt match with the domain controller servers database. For example, if the actual domain is SALES.MYCOMPANY.COM", and the admin specifies STRESS as the domain, then the krb5.conf will display the following,
So, when the admin tries to authenticate with useraccount@SALES, the krb5 lib will notice that the principal name SALES differs from the actual one in the server database.
Refer to Table 11.13 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.
SSH into the Access Policy Manager 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 SAM controller and the Active Directory server.
Confirm that the Active Directory server name can be resolved to the correct IP address, and that the reverse name resolution (IP 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.
Take a tcpdump 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. These tcpdumps 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: Since it is required that you provide a tcpdump should you decide to escalate the issue to Customer Support, we highly recommend that you take a capture of the tcpdump when you encounter authentication issues that you cannot otherwise resolve on your own.
Figure 11.6 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.
This feature is used to retrieve 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 will contain 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 will contain all groups the users belongs to, which includes, group 1, group 2, group 3, and group 4.
Note: Nested groups works slightly different 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 preceding table displays the results of your Active Directory query if nested groups is used in conjunction with Fetch Group Attributes.
This queries all groups the user belongs to. This includes the users memberOf groups which includes the users primary group, and groups nested through all membersOf groups.
This queries the users memberOf groups plus the primaryGroupDN. However, it will not query any nested groups.
This queries the users memberOf groups, including the nested groups through the memberOf groups. However, the primaryGroupDN will not be queried.
This queries the users memberOf group only. This means that only the groups users are directly associated with are queried.
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 and passwords.
Basic authentication requires a valid URL resource. This resource must respond with a challenge to a non-authenticated request. This method supports authentication over both HTTP and HTTPS protocols.
Note: F5 Networks strongly recommends using HTTPS because basic authentication passes user credentials as clear text. However, to support HTTPS authentication, it 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.
On the navigation pane, expand Access Policy, and click AAA servers.
The New Server screen opens.
3.
From the Type field, select HTTP from the list.
The General Properties page opens
5.
From the Start URL field, type the complete URL that returns the logon form. Make sure to include the protocol (HTTP or HTTPS, server, and port).
6.
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.
1.
In the navigation pane, expand Access Policy, and click AAA servers.
The AAA server list screen opens.
2.
Click Create.
The New Server screen opens.
3.
5.
In the Start URI field, type in your URI resource, such as http://plum.tree.lab2.sp.companynet.com/.
6.
Click Finished.
7.
In the navigation pane, expand Access Policy, and click Access Profiles.
The Profile List opens.
8.
Select the access policy you just created, and click Edit.
The visual policy editor screen opens in a separate browser.
9.
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.
10.
Click Save, and then click Apply Access Policy to save your changes.
1.
From the navigation pane, click Local Traffic, and select Nodes.
The Nodes List screen opens.
2.
Click Create.
The New Node screen opens.
3.
Type in the Address of your server and click Finished.
The new node is created.
1.
On the navigation pane, expand Local Traffic, and click Pools.
The Pool list screen opens.
2.
Click Create.
The New Pool screen opens.
4.
In the Address field under Resources, type in the IP Address, and select https from the drop-list. The Service Port should automatically display port 443.
6.
Clicked Finished.
1.
On the navigation pane, expand Local Traffic, and click Virtual Server List.
The Virtual Server List screen opens.
2.
Click Create.
The New Virtual Server screen opens.
3.
Type in a Name, Destination, and Service port.
The Destination address is the virtual IP address that will be used as the external HTTP authentication server in HTTP server configuration.The service port should be 80.
4.
From the SSL Profile (Server) drop-list, select serverssl.
This ensures that there is an SSL connection between the HTTP virtual server and the external HTTP server.
6.
Under the virtual server resource (Load Balancing: Default Pool) select the pool created for the HTTP server.
7.
On the navigation pane, click Local Traffic, select Virtual Servers, and choose Virtual Address List.
8.
9.
Uncheck the ARP 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.
1.
On the navigation pane, expand Access Policy, and click AAA servers.
The New Server screen opens.
3.
From the Type field, select HTTP from the list.
The General Properties page opens
5.
From the Start URL field, type the complete URL that returns the logon form. Make sure to include the protocol (HTTP or HTTPS, server, and port).
6.
Click Finished.
Upon detecting the start 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.
On the navigation pane, expand Access Policy, and click AAA servers.
The New Server screen opens.
3.
From the Type field, select HTTP.
4.
In the Auth type field, select Form Based.
5.
From the Form Method field, select either GET or POST. By default, the Form Method value is POST. If GET is specified, then the authentication request will be converted as HTTP GET.
6.
From the Form Action field, type the complete destination URL use for authentication.
7.
From 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 Password example is PASSWORD.
8.
In the Hidden Form Parameters/Values field, 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.
9.
From the Number of Redirects to Follow field, type the number of pages away from the landing page the request should travel before failing.
10.
In the Successful Logon Detection Type field, 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.
In the Success Logon Detection Value, the field will populate to whatever method you selected in the Successful Logon Detection Type field.
One of the requirements to set up HTTP form-based authentication is to provide hidden form parameters and values, as indicated in Step 7 above.
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
Generally, if BIG-IP loses connectivity to the authentication server, new authentications will fail. (Existing sessions will be unaffected as long as they don't 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.
Configuring AAA high availability requires the following steps. These steps apply to all types of authentication servers that Access Policy Manager supports, which includes RADIUS, LDAP, and Active Directory:
Setting up server "dummy" virtuals. These servers serve as the front-end address for the backend servers.
Setting up an AAA server object using the dummy virtual for the server address. This object appears in your access policy.
You can set up AAA high availability for RADIUS and accounting services to ensure that services to the Access Policy Manager are not affected should one of the AAA servers goes down for any reason.
1.
On the navigation pane, expand Local Traffic, and click Pools.
The Pool screen opens.
2.
Click Create.
The New Pool screen opens.
3.
Type a name for your Pool. The name of your pool should be descriptive, for example, RADIUSAuthenticationPool.
4.
Under Health Monitors, select gateway_icmp and click the << arrow to add it to the Active list.
This lets BIG-IP know when the servers are active or inactive.
5.
Optionally, under the Resources section, enable the Priority Group Activation by selecting Less than...from the drop box.
6.
In the Address field, type in the IP address for your RADIUS server, the Service Port (1812), and a Priority level.
7.
Repeat 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.
Note: 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.
On the navigation pane, expand Local Traffic and click Virtual Servers.
The Virtual Server screen opens.
2.
Click Create.
The New Virtual Server screen opens.
3.
In the Name field, type in a name for your "dummy" virtual server.
4.
Next to Configuration, select Advanced.
More options appear on screen.
5.
Under General Properties, in the Address field, enter a loopback address. We recommend that you use an unroutable IP address.
6.
In the Server Port field, enter port 1812, which is the default port for RADIUS servers.
1.
From the navigation pane, expand Local Traffic and click Virtual Servers.
3.
Select the Resources tab.
4.
For Default Pool, select the server pool you created.
5.
Click Update to save your information.
Note: You will need to create a second virtual server, using the same procedure for RADIUS accounting. Remember to use port 1813.
1.
From the navigation pane, expand Access Policy, and click AAA servers.
The AAA Servers screen opens.
2.
Click Create.
The New Server screen opens.
3.
In the Name field, type a name for your RADIUS server.
4.
Under Type, select RADIUS.
5.
Under Configuration, select the Auth & Accounting mode.
6.
Enter the "dummy" virtual host and port information for both authentication and accounting.
7.
Enter and confirm Secret information. This needs to be the same on both servers.Additionally, both servers must have the self-IP address of the device as permitted NAS.
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.
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 Active Directory authentication or 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 server the domain. For that particular setup, users must be updated on each system individually.
Configure for both 389 (LDAP) and 88 (Kerberos) ports by creating a separate virtual and pool for each port. An alternative step is to create a single virtual with a single pool and assign all ports to the virtual.
1.
On the navigation pane, expand Local Traffic, and click Pools.
The Pool screen opens.
2.
Click Create.
The New Pool screen opens.
3.
Type a name for your Pool. The name of your pool should be descriptive, for example, LDAPAuthenticationPool.
4.
Under Health Monitors, select gateway_icmp and click the << arrow to add it to the Active list.
This lets BIG-IP know when the servers are active or inactive.
5.
Optionally, under the Resources section, enable the Priority Group Activation by selecting Less than...from the drop box.
6.
In the Address field, type in the IP address for your LDAP server, the Service Port 389 (for LDAP) or 88 (for Kerberos), and a Priority level.
7.
Repeat for each Active Directory server you wish to add, and then click the Add button.
Each IP address of the Active Directory server should appear in the New Members table.
8.
Click Finished.
1.
On the navigation pane, expand Local Traffic and click Virtual Servers.
The Virtual Server screen opens.
2.
Click Create.
The New Virtual Server screen opens.
3.
In the Name field, type in a name for your "dummy" virtual server.
4.
Next to Configuration, select Advanced.
More options appear on screen.
5.
Under General Properties, in the Address field, enter a loopback address. We recommend that you use an unroutable IP address.
6.
In the Server Port field, enter port 389 or 88, which is the default port for Active Directory servers.
For Active Directory, you need to add the virtual server name to the Access Policy Managers /etc/hosts file in order for it to resolve correctly. For example:
1.
From the navigation pane, expand Access Policy, and click AAA servers.
The AAA Servers screen opens.
2.
Click Create.
The New Server screen opens.
3.
In the Name field, type in a name for your Active Directory server.
4.
Under Type, select Active Directory.
5.
In the domain controller field, enter the KDS hostname (as defined in the /etc/hosts file), and the name of the domain in the Domain Name field.
6.
Enter the Admin Name and enter and verify the Admin Password.
These must be identical on both servers.
Setting up Active Directory query high availability servers is more involved because of limitations imposed by the Active Directory server.
1.
On the navigation pane, expand Local Traffic, and click Pools.
The Pool screen opens.
2.
Click Create.
The New Pool screen opens.
3.
Type a name for your Pool. The name of your pool should be descriptive, for example, ActiveDirectoryQueryPool.
4.
Under Health Monitors, select tcp and click the << arrow to add it to the Active list.
This lets BIG-IP know when the servers are active or inactive.
5.
Optionally, under the Resources section, enable the Priority Group Activation by selecting Less than from the drop box.
6.
In the Address field, type in the IP address for your Active Directory server, the Service Port (389 or 88), and set the priority level to *All Services.
7.
Repeat for each Active Directory server you wish to add, and then click the Add button.
Each IP address of the Active Directory server should appear in the New Members table.
8.
Click Finished.
1.
On the navigation pane, expand Local Traffic and click Virtual Servers.
The Virtual Server screen opens.
2.
Click Create.
The New Virtual Server screen opens.
3.
In the Name field, type in a name for your "dummy" virtual server.
4.
Next to Configuration, select Advanced.
More options appear on screen.
5.
Under General Properties, in the Address field, enter a loopback address. We recommend that you use an unroutable IP address.
6.
In the Server Port field, enter port 389 or 88, which is the default port for Active Directory servers.
1.
From the navigation pane, expand Local Traffic and click Virtual Servers.
3.
Select the Resources tab.
4.
For Default Pool, select the server pool you created.
5.
Click Update to save your information.
For Active Directory, you need to add the virtual server name to the Access Policy Managers /etc/hosts file in order for it to resolve correctly. This should point to the dummy virtual IP address, and is used for reverse DNS resolution.
1.
From the navigation pane, expand Access Policy, and click AAA servers.
The AAA Servers screen opens.
2.
Click Create.
The New Server screen opens.
3.
In the Name field, type in a name for your Active Directory server.
4.
Under Type, select Active Directory.
5.
In the domain controller field, enter the KDS hostname (as defined in the /etc/hosts file), and the name of the domain in the Domain Name field.
In addition to adding an entry to the /etc/hosts file, you must supply the following information to your DNS server.
Service Location (SRV(records) for UDP for Kerberos, LDAP, and Kerberos-master (port 88) pointing to your virtual.
6.
Enter the Admin Name and enter and verify the Admin Password.
These must be identical on both servers.
You must make sure that all of your Active Directory servers recognize that your virtual is hosting the Active Directory service. You do this by adding a Service Principal Name entry on each of the authentication servers using Microsofts setspn utility.
1.
Download the setspn utility from Microsofts website.
This is a separate download for Windows 2000 Server, but a part of the Windows Server 2003 Support Tools for Windows 2003 Server.
So, if you are configuring your Active Directory server as testauth1, and you are adding an entry for your virtual as myvirtual.mydomain.com, you would run the following command:
One of the entries will show Active Directory as being registered for your virtual on the server. Add entries on each of your authentication servers, and Active Directory query should work successfully.
To effectively test that AAA high availability works for Active Directory, 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 389.
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. 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 server the domain. For that particular setup, users must be updated on each system individually.
1.
On the navigation pane, expand Local Traffic, and click Pools.
The Pool screen opens.
2.
Click Create.
The New Pool screen opens.
3.
Type a name for your Pool. The name of your pool should be descriptive, for example, LDAPAuthenticationPool.
4.
Under Health Monitors, select gateway_icmp and click the << arrow to add it to the Active list.
This lets BIG-IP know when the servers are active or inactive.
5.
Optionally, under the Resources section, enable the Priority Group Activation by selecting Less than...from the drop box.
6.
In the Address field, type in the IP address for your LDAP server, the Service Port (389 or 88), and a Priority level.
7.
Repeat for each LDAP server you wish to add, and then click the Add button.
Each IP address of the LDAP server should appear in the New Members table.
8.
Click Finished.
1.
On the navigation pane, expand Local Traffic and click Virtual Servers.
The Virtual Server screen opens.
2.
Click Create.
The New Virtual Server screen opens.
3.
In the Name field, type a name for your "dummy" virtual server.
4.
Next to Configuration, select Advanced.
More options appear on screen.
5.
Under General Properties, in the Address field, enter a loopback address. We recommend that you use an unroutable IP address.
6.
In the Server Port field, enter port 389, which is the default port for LDAP servers.
1.
From the navigation pane, expand Local Traffic and click Virtual Servers.
3.
Select the Resources tab.
4.
For Default Pool, select the server pool you created.
5.
Click Update to save your information.
1.
From the navigation pane, expand Access Policy, and click AAA servers.
The AAA Servers screen opens.
2.
Click Create.
The New Server screen opens.
3.
In the Name field, type a name for your LDAP server.
4.
Under Type, select LDAP.
5.
Enter the Admin Name and enter and verify the Admin Password.
These must be identical on both servers.
To effectively test that AAA high availability works for LDAP, you should have two LDAPservers 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 389.
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.
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)