BIG-IP Access Policy Manager Authentication Configuration Guide. Version 11.0

Transcription

1 BIG-IP Access Policy Manager Authentication Configuration Guide Version 11.0

2

3 Table of Contents Table of Contents Legal Notices...5 Acknowledgments...7 Chapter 1: Authentication Concepts...9 Authentication in Access Policy Manager...10 Differences between auth and query types...11 What are nested groups?...11 Chapter 2: Authentication Methods...13 Supported authentication methods...14 About RADIUS authentication...15 Configuring for RADIUS authentication and authorization...15 Completing the authentication process for RADIUS...16 About RADIUS accounting...17 Configuring RADIUS Accounting authentication...17 Completing the authentication process for RADIUS accounting...18 About LDAP and LDAPS authentication...20 Configuring for LDAP authentication and authorization...21 Completing the authentication process for LDAP...21 Task summary for configuring for LDAPS authentication...22 About Active Directory authentication...24 About Active Directory password management...24 Configuring for Active Directory authentication and authorization...24 Completing the authentication process for Active Directory...25 Active Directory's cross-domain support rules...26 About using external servers for authentication...26 What are hidden parameters?...26 Task summary for configuring an external, web-based server for HTTP authentication.27 Task summary for configuring an external, web-based server for HTTP authentication.28 About RSA Native SecurID authentication...30 Task summary for configuring an external, web-based server for HTTP authentication.30 About OCSP authentication...32 Task summary for OCSP authentication...32 About CRLDP authentication...34 Task summary for CRLDP authentication...34 About TACACS+ authentication and accounting...36 Task summary for TACACS+ authentication and accounting

4 Table of Contents Chapter 3: AAA and Configuring High Availability...39 Task summary for configuring AAA high availability...40 Setting up a AAA server object for high availability...40 Testing AAA high availability for all supported authentication servers...41 Upgrading an Access Policy Manager high availability failover pair...41 Chapter 4: Configuring Kerberos Authentication with End-User Logons...43 About basic authentication and Kerberos end-user logon...44 How does end-user login work?...44 Task summary for configuring end-user login support...45 Access policy example for end-user logon...46 Appendix A: AAA Session Variables...49 List of AAA session variables...50 AAA server session variables for access policy rules...50 Appendix B: AAA Configuration Examples...53 AAA server configuration examples...54 Example for converting hex attributes...54 Example of authenticating and authorizing users with Active Directory...55 Example of LDAP auth and query default rules...56 Appendix C: Troubleshooting AAA Configurations...57 List of troubleshooting tips for authentication...58 RADIUS authentication and accounting troubleshooting tips...58 LDAP authentication and query troubleshooting tips...59 Active Directory authentication and query troubleshooting tips...61 RSA SecurID on Windows using RADIUS configuration troubleshooting tips

5 Legal Notices Publication Date This document was published on August 17, Publication Number MAN Copyright Copyright 2011, F5 Networks, Inc. All rights reserved. F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice. Trademarks 3DNS, Access Policy Manager, Acopia, Acopia Networks, Advanced Client Authentication, Advanced Routing, APM, Application Security Manager, ARX, AskF5, ASM, BIG-IP, Cloud Extender, CloudFucious, CMP, Data Manager, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client, Edge Gateway, Edge Portal, EM, Enterprise Manager, F5, F5 [DESIGN], F5 Management Pack, F5 Networks, F5 World, Fast Application Proxy, Fast Cache, FirePass, Global Traffic Manager, GTM, IBR, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iapps, icontrol, ihealth, iquery, irules, irules OnDemand, isession, IT agility. Your way., L7 Rate Shaping, LC, Link Controller, Local Traffic Manager, LTM, Message Security Module, MSM, Netcelera, OneConnect, Packet Velocity, Protocol Security Module, PSM, Real Traffic Policy Builder, Scale N, SSL Acceleration, StrongBox, SuperVIP, SYN Check, TCP Express, TDR, TMOS, Traffic Management Operating System, TrafficShield, Transparent Data Reduction, VIPRION, vcmp, WA, WAN Optimization Manager, WANJet, WebAccelerator, WOM, and ZoneRunner, are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without F5's express written consent. All other product and company names herein may be trademarks of their respective owners. Patents This product may be protected by U.S. Patent 7,114,180. This list is believed to be current as of August 17, Export Regulation Notice This product may include cryptographic software. Under the Export Administration Act, the United States government may consider it a criminal offense to export this product from the United States. RF Interference Warning This is a Class A product. In a domestic environment this product may cause radio interference, in which case the user may be required to take adequate measures.

6 Legal Notices FCC Compliance This equipment has been tested and found to comply with the limits for a Class A digital device pursuant to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This unit generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user, at his own expense, will be required to take whatever measures may be required to correct the interference. Any modifications to this device, unless expressly approved by the manufacturer, can void the user's authority to operate this equipment under part 15 of the FCC rules. Canadian Regulatory Compliance This Class A digital apparatus complies with Canadian ICES-003. Standards Compliance This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to Information Technology products at the time of manufacture. 6

7 Acknowledgments This product includes software developed by Bill Paul. This product includes software developed by Jonathan Stone. This product includes software developed by Manuel Bouyer. This product includes software developed by Paul Richards. This product includes software developed by the NetBSD Foundation, Inc. and its contributors. This product includes software developed by the Politecnico di Torino, and its contributors. This product includes software developed by the Swedish Institute of Computer Science and its contributors. This product includes software developed by the University of California, Berkeley and its contributors. This product includes software developed by the Computer Systems Engineering Group at the Lawrence Berkeley Laboratory. This product includes software developed by Christopher G. Demetriou for the NetBSD Project. This product includes software developed by Adam Glass. This product includes software developed by Christian E. Hopps. This product includes software developed by Dean Huxley. This product includes software developed by John Kohl. This product includes software developed by Paul Kranenburg. This product includes software developed by Terrence R. Lambert. This product includes software developed by Philip A. Nelson. This product includes software developed by Herb Peyerl. This product includes software developed by Jochen Pohl for the NetBSD Project. This product includes software developed by Chris Provenzano. This product includes software developed by Theo de Raadt. This product includes software developed by David Muir Sharnoff. This product includes software developed by SigmaSoft, Th. Lockert. This product includes software developed for the NetBSD Project by Jason R. Thorpe. This product includes software developed by Jason R. Thorpe for And Communications, This product includes software developed for the NetBSD Project by Frank Van der Linden. This product includes software developed for the NetBSD Project by John M. Vinopal. This product includes software developed by Christos Zoulas. This product includes software developed by the University of Vermont and State Agricultural College and Garrett A. Wollman. This product includes software developed by Balazs Scheidler which is protected under the GNU Public License.

8 Acknowledgments This product includes software developed by Niels Mueller which is protected under the GNU Public License. In the following statement, This software refers to the Mitsumi CD-ROM driver: This software was developed by Holger Veit and Brian Moore for use with 386BSD and similar operating systems. Similar operating systems includes mainly non-profit oriented systems for research and education, including but not restricted to NetBSD, FreeBSD, Mach (by CMU). This product includes software developed by the Apache Group for use in the Apache HTTP server project ( This product includes software licensed from Richard H. Porter under the GNU Library General Public License ( 1998, Red Hat Software), This product includes the standard version of Perl software licensed under the Perl Artistic License ( 1997, 1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current standard version of Perl at This product includes software developed by Jared Minch. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( This product includes cryptographic software written by Eric Young ([email protected]). This product contains software based on oprofile, which is protected under the GNU Public License. This product includes RRDtool software developed by Tobi Oetiker ( and licensed under the GNU General Public License. This product contains software licensed from Dr. Brian Gladman under the GNU General Public License. This product includes software developed by the Apache Software Foundation ( This product includes Hypersonic SQL. This product contains software developed by the Regents of the University of California, Sun Microsystems, Inc., Scriptics Corporation, and others. This product includes software developed by the Internet Software Consortium. This product includes software developed by Nominum, Inc. ( This product contains software developed by Broadcom Corporation, which is protected under the GNU Public License. This product contains software developed by MaxMind LLC, and is protected under the GNU Lesser General Public License, as published by the Free Software Foundation. 8

9 Chapter 1 Authentication Concepts Topics: Authentication in Access Policy Manager

10 Authentication Concepts Authentication in Access Policy Manager Access Policy Manager provides several benefits when it comes to authenticating and authorizing your users. Benefit Policy component Flexibility Performance Extensible Customizable input Generic output Description Administrators are able to add various types of supported authentication methods as basic components to their access policy. Administrators can combine multiple authentication mechanisms in an arbitrary manner for a single access policy. Administrators should see high optimization (approximately 250 logins/sec.) Administrators can set up to retrieve user's credentials from multiple sources (for example, client certificate fields) as input to the/an? authentication subsystem. Administrators are able to add various types of supported authentication methods as basic components to their access policy. Administrators can use the results from the? authentication subsystem as input for various other functionality, for instance, resource assignments. These illustrations depict the use of authentication as an access policy component. It also shows how various authentication schemas are combined together within a single access policy, and the result from authentication is used for assigning the appropriate resources to a user. Figure 1: Create a AAA server object Figure 2: Create an access policy 10

11 BIG-IP Access Policy Manager Authentication Configuration Guide Differences between auth and query types There are two types of authentication that pertain only to Active Directory and LDAP authentications, and they use two separate access policy items. The auth type is authentication only. In this case, the Access Policy Manager just verifies the user's credentials against an external server. The query type causes the Access Policy Manager to query 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 access policy item you would like to add to your access policy. For instance, if you added AD auth to your access policy, you cannot change it later to AD query unless you edit your access policy and delete the AD auth item completely from your access policy. Attention: If you use either LDAP query or AD query, Access Policy Manager does not query for the primary group and add it to the memberof attribute. You must manually look up the attribute memberof as well as the primary group. What are nested groups? 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 that 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 memberofsession 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. 11

12 Authentication Concepts 12

13 Chapter 2 Authentication Methods Topics: Supported authentication methods About RADIUS authentication About RADIUS accounting About LDAP and LDAPS authentication About Active Directory authentication About using external servers for authentication About RSA Native SecurID authentication About OCSP authentication About CRLDP authentication About TACACS+ authentication and accounting

14 Authentication Methods Supported authentication methods You can configure authentication and authorization using AAA servers with Access Policy Manager. Access Policy Manager uses the concept of access policies to authenticate and authorize users on the system. The stringent nature of the authentication mechanism you use for 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 those you use for your local network. You can set up authentication using Access Policy Manager by any combination of the following methods. Note: To use a specific authentication method, you must have a server that supports your scheme at your site. Note: Routing domain is currently not supported if you configure your AAA server through a direct connection. However, you can achieve routing domain by using pool members when you configure your AAA server. Authentication method RADIUS LDAP Microsoft Active Directory Description Uses the server at your site that supports using the RADIUS protocol. Uses the server at your site that supports authentication using LDAP. Uses the server at your site that supports Kerberos authentication against a Windows 2000 or later server. For a list of network ports required for authentication with Active Directory, refer to the Microsoft KB article under such sections as: Kerberos Distribution Center Group Policy DNS Server External web-based servers Uses external web-based authentication servers to validate user logins? and passwords, and to control user access to specific network resources. This method includes HTTP basic, HTTPS, HTTP NTLM, and HTTP form-based methods. Restriction: For HTTP Auth, NTLMv2 is currently not supported. RSA SecurID over RADIUS RSA Native SecurID Oracle Access Manager CRLDP Uses the RADIUS protocol for authentication. To use this authentication method, you must select RADIUS as the authentication method. Uses the RSA Native SecurID protocol for authentication. You must have an authentication server set up and select SecurID as the authentication method. Uses the Oracle Access Manager (OAM) server for authentication and authorization to eliminate the need of deploying a WebGate proxy in front of each application. For more information about OAM and how it works in conjunction with single sign-on, refer to the SSO chapter. Distributes certificate revocation information across a network that identifies how the server obtains CRL information. 14

15 BIG-IP Access Policy Manager Authentication Configuration Guide Authentication method Description Online Certificate Status Protocol (OCSP) Terminal Access Controller Access Control System (TACAS+) Retrieves the revocation status of the X509 certificate to ensure the Access Policy Manager obtains real-time revocation status during the certificate verification process. Encrypts the entire body of the authentication packet. They system collects user credentials using the login screen agentin the access policy, and stores the collected credentials in the session.logon.last.username and session.logon.last.password session variables. About RADIUS authentication Access Policy Manager supports authenticating and authorizing the client against external RADIUS servers. When a client connects with the user name and password, Access Policy Manager authenticates against the external server on behalf of the client, and authorizes the client to access resources if the credentials are valid. Figure 3: How RADIUS works 1. The client requests access to network resources through Access Policy Manager. 2. Access Policy Manager then issues a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access. 3. The RADIUS server then processes the request, and issues one of three responses to Access Policy Manager:Access Accept, Access Challenge, Access Reject. Configuring for RADIUS authentication and authorization 1. On the Main tab, click Access Policy > AAA Servers. 2. Type a name for the authentication server you are creating. 3. For the Mode option, select the Auth button. 4. Type a name for the AAA server pool if you selected Use Pool. 5. Type in a server address for the AAA server. Or, if you selected Use Pool, type in the IP addresses of the pool members, and click Add. 6. Select a monitor to track the health of the AAA server. This is optional. 7. In the Secret field, type the shared secret password of the server. 8. In the Confirm Secret field, re-type the shared secret password of the server. 9. In the Timeout field, type a timeout interval (in seconds) for the AAA server. 15

16 Authentication Methods This setting is optional. 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 time frame, in seconds. If the server does not respond, the Access Policy Manager retries the authentication attempt, depending on how many retries you specify. 10. In the Retries field, type the number of times the BIG-IP system should try to make a connection to the server after the first attempt fails. This setting is optional. 11. Click Finished to add the new server to the configuration, and return to the main screen. The RADIUS server is added to the AAA Servers list. Completing the authentication process for RADIUS Before you set up your RADIUS access policy to complete the authentication process, you must have at least one RADIUS authentication server configured. 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. On the menu bar, click Access Policy. The Access Policy screen opens. 4. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 5. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 6. From the Authentication list of Predefined Actions, select RADIUS Auth and click Add Item. 7. Select the AAA RADIUS server you want to associate to the access policy, and click Save. 8. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overrall authentication process. RADIUS attributes The following table lists the specific RADIUS attributes that the Access Policy Manager sends with RADIUS requests. Attribute User-Name User-Password NAS-IP-Address Service-Type NAS-Port Purpose Indicates the name of the authenticated user. Indicates the password of the authenticated user. Indicates the identifying IP Address of the NAS. Indicates the type of service the user has requested. Indicates the physical port number of the NAS that is authenticating the user. 16

17 BIG-IP Access Policy Manager Authentication Configuration Guide About RADIUS accounting 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. 1. Access Policy Manager first grants network access to the client, then sends an accounting start request message to the external RADIUS server.. The start message typically contains the user's ID, networks address, point of attachment, and a unique session identifier. 2. Once the client terminates the network access session, Access Policy Manager issues an accounting stop message to the external RADIUS server, providing information on the final usage in terms of time, packets transferred, data transferred, and reason for disconnect, as well as other information related to the user's network access. This accounting data is used primarily for billing, statistical, and general network monitoring purposes. Note: 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 Manager does not send RADIUS accounting information to the RADIUS accounting server unless the user has been authorized by the RADIUS server. Configuring RADIUS Accounting authentication 1. On the Main tab, click Access Policy > AAA Servers. 2. Type a name for the authentication server you are creating. 3. For the Mode option, select Accounting. 4. In the Accounting Host field, type the Accounting host name of your accounting server. 5. In the Accounting Service Port field, type the service port for your accounting server. The default is In the Secret field, type the shared secret password of the server. 7. In the Confirm Secret field, re-type the shared secret password of the server. 8. In the Timeout field, type a timeout interval (in seconds) for the AAA server. This setting is optional. 17

18 Authentication Methods 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 time frame, in seconds. If the server does not respond, the Access Policy Manager retries the authentication attempt, depending on how many retries you specify. 9. In the Retries field, type the number of times the BIG-IP system should try to make a connection to the server after the first attempt fails. This setting is optional. 10. Click Finished to add the new server to the configuration, and return to the main screen. Completing the authentication process for RADIUS accounting Before you set up your RADIUS access policy to complete the authentication process, you must have at least one RADIUS authentication server configured. 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. On the menu bar, click Access Policy. The Access Policy screen opens. 4. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 5. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 6. From the Authentication list of Predefined Actions, select RADIUS Acct and click Add item 7. Select the AAA RADIUS accounting server you want to associate to the access policy, and click Save. 8. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overrall authentication process. RADIUS accounting attributes These tables list specific RADIUS accounting attributes that the Access Policy Manager sends for RADIUS Accounting-Request (start messages) and RADIUS Accounting-Request (stop messages). RADIUS attributes for RADIUS Accounting start messages Attribute User-Name Acct-Session-Id Acct-Status-Type Acct-Authentic Service-Type Purpose Indicates the name of the authenticated user. Indicates a unique accounting ID to make it easy to match start and stop records in a log file. It is essentially a user's 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. Indicates the type of service the user has requested. 18

19 BIG-IP Access Policy Manager Authentication Configuration Guide Attribute Nas-IP-Address NAS-Port Tunnel-Client-Endpoint Class Purpose 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. Contains the IP address of the initiator end of the tunnel. Administrators can make resource assignments using this attribute. RADIUS attributes for RADIUS Accounting stop messages Attribute Acct-Terminate-Cause Acct-Session-Id Acct-Status-Type Acct-Session-Time Service-Type Framed-IP-Address Acct-Input-Octets Acct-Output-Octets Purpose Indicates how the session was terminated. Access Policy Manager supports three values for this attribute: User Request Session Timeout Admin Reset. A unique accounting ID to make it easy to match start and stop records in a log file. It is essentially a user s session ID. Indicates whether the accounting-request marks the beginning of the user service (Start) or the end (Stop). Indicates the number of seconds the user has received service for. Indicates the type of service the user has requested.. Indicates the address configured for the user. 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. Note: 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 user s session times out. RADIUS accounting messages are sent asynchronously. The Access Policy Manager stores the user s sessions start and end information in its database, and sends them to the RADIUS accounting server. 19

20 Authentication Methods About LDAP and LDAPS authentication You can use LDAPS in place of LDAP when the authentication messages between the Access Policy Manager and the LDAP server must be secured with encryption. However, there are instances where you will not need LDAPS and the security it provides. For example, authentication traffic happens on the internal side of the Access Policy Manager, and may not be subject to observation by unauthorized users. Another example of when not to use LDAPS is when authentication is used on separate VLANs to ensure that the traffic cannot be observed by unauthorized users. Figure 4: How LDAP works LDAPS is achieved by directing LDAP traffic over a virtual server that uses server side SSL to communicate with the LDAP server.essentially, the system creates an LDAP AAA object that has the address of the virtual server. That virtual server (with server SSL) directs its traffic to a pool, which has as a member that has the address of the LDAP server. Figure 5: How LDAPS works 20

21 BIG-IP Access Policy Manager Authentication Configuration Guide Configuring for LDAP authentication and authorization 1. On the Main tab, click Access Policy > AAA Servers. 2. Scroll down to the type of AAA server you want to create and click the Create (+) button. A New Server General Properties screen opens. 3. Type a name for the authentication server you are creating. 4. Select one of the following options: Select Use Pool to set up high availability for the AAA server. Select Direct to set up the AAA server for standalone functionality. 5. Type a name for the AAA server pool if you selected Use Pool. 6. Type in a server address for the AAA server. Or, if you selected Use Pool, type in the IP addresses of the pool members, and click Add. 7. Select a monitor to track the health of the AAA server. This is optional. 8. For the Mode setting, select LDAP. 9. In the Service Port field, type the port number of the server. The default is 389 for LDAP, and 636 for LDAPS. 10. In the Admin DN field, type the distinguished name (DN) of the user with administrator rights. Type the value in this format: CN=administrator,CN=users,DC=sales,DC=mycompany,DC=com. 11. In the Admin Password field, type the administrative password for the server. 12. In the Verify Admin Password field, re-type the administrative password for the server. 13. In the Timeout field, type a timeout interval (in seconds) for the AAA server. This setting is optional. 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 time frame, in seconds. If the server does not respond, the Access Policy Manager retries the authentication attempt, depending on how many retries you specify. 14. Click Finished to add the new server to the configuration, and return to the main screen. The new LDAP server is added to the AAA Server List. Completing the authentication process for LDAP Before you set up your access policies to complete the authentication process, you must have at least one authentication server configured. 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. On the menu bar, click Access Policy. The Access Policy screen opens. 4. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 21

22 Authentication Methods 5. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 6. In the Authentication area of Predefined Actions, select LDAP Auth or LDAP query and click Add item. 7. Select the AAA LDAP server you want to associate to the access policy, and click Save. 8. For both LDAP auth and AD query, specify the SearchDN, and SearchFilter settings. 9. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overrall authentication process. Attention: If you use either LDAP query, Access Policy Manager does not query for the primary group and add it to the memberof attribute. You must manually look up the attribute memberof as well as the primary group. Task summary for configuring for LDAPS authentication To set up this configuration, perform the procedures in the task list. Task List Configuring for LDAPS authentication and authorization Completing the authentication process for LDAP Testing LDAPS authentication Configuring for LDAPS authentication and authorization 1. On the Main tab, click Access Policy > AAA Servers. 2. Scroll down to the type of AAA server you want to create and click the Create (+) button. A New Server General Properties screen opens. 3. Type a name for the authentication server you are creating. 4. Select one of the following options: Select Use Pool to set up high availability for the AAA server. Select Direct to set up the AAA server for standalone functionality. 5. Type a name for the AAA server pool if you selected Use Pool. 6. Type in a server address for the AAA server. Or, if you selected Use Pool, type in the IP addresses of the pool members, and click Add. 7. Select a monitor to track the health of the AAA server. This is optional. 8. For the Mode setting, select LDAPS. 9. In the Service Port field, type the port number of the server. The default is 389 for LDAP, and 636 for LDAPS. 10. In the Admin DN field, type the distinguished name (DN) of the user with administrator rights. Type the value in this format: CN=administrator,CN=users,DC=sales,DC=mycompany,DC=com. 11. In the Admin Password field, type the administrative password for the server. 12. In the Verify Admin Password field, re-type the administrative password for the server. 22

23 BIG-IP Access Policy Manager Authentication Configuration Guide 13. For SSL Profile (Server), select the SSL server profile from the list. LDAPS is achieved by directing LDAP traffic over a virtual server that uses a server side SSL to communicate with the LDAP server. 14. In the Timeout field, type a timeout interval (in seconds) for the AAA server. This setting is optional. 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 time frame, in seconds. If the server does not respond, the Access Policy Manager retries the authentication attempt, depending on how many retries you specify. 15. Click Finished to add the new server to the configuration, and return to the main screen. The new LDAPS server is added to the AAA Server List. Completing the authentication process for LDAP Before you set up your access policies to complete the authentication process, you must have at least one authentication server configured. 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. On the menu bar, click Access Policy. The Access Policy screen opens. 4. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 5. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 6. In the Authentication area of Predefined Actions, select LDAP Auth or LDAP query and click Add item. 7. Select the AAA LDAP server you want to associate to the access policy, and click Save. 8. For both LDAP auth and AD query, specify the SearchDN, and SearchFilter settings. 9. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overrall authentication process. Attention: If you use either LDAP query, Access Policy Manager does not query for the primary group and add it to the memberof attribute. You must manually look up the attribute memberof as well as the primary group. Testing LDAPS authentication Make sure all the appropriate steps were performed to create an LDAPS authentication. 1. Ensure that LDAP authentication works in your environment. An intermediate virtual server should not exist for this verifications step. 2. Create an access policy that uses a AAA object that points directly to the LDAP server. 3. Add an intermediate virtual server without an server side SSL. Using the same access policy that you just created, modify the AAA object to point to a virtual server. 4. Implement LDAPS by enabling server side SSL, and change the pool member to use port

24 Authentication Methods 5. Review the log messages in /var/log/apm. 6. Make sure your to set your log levels to Debug. 7. Review the log for LDAP messages and locate and confirm that bind and search succeeds. About Active Directory authentication You can authenticate using Active Directory authentication with Access Policy Manager. We also support using Kerberos-based authentication through Active Directory. About Active Directory password management Access Policy Manager supports password management for Active Directory authentication. This process works in the following sequence order: Access Policy Manager uses the client's user name and password to authenticate against the Active Directory server on behalf of the client. If the user password on the Active Directory server has expired, Access Policy Manager returns a new logon screen back to the user, requesting that the user change their password. After the user submits the new password, Access Policy Manager attempts to change the password on the Active Directory server. If this is successful, the user's authentication is validated. 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 for Active Directory authentication and authorization 1. On the Main tab, click Access Policy > AAA Servers. 2. Type a name for the authentication server you are creating. 3. In the Domain Controller field, specify the Active Directory server configured with this role. 4. In the Domain Name field, type the Windows Domain name. You must enter the Fully Qualified Domain Name (FQDN). 5. In the Admin DN field, type the Distinguished Name (DN) of the user with administrator rights. Enter the value in this format: CN=administrator,CN=users,DC=sales,DC=mycompany,DC=com. 6. In the Admin Name field, type an administrator name that has Active Directory administrative permissions. The administrator name is case-sensitive. 7. In the Admin Password field, type the administrative password for the server. 8. In the Verify Admin Password field, re-type the administrative password for the server. 9. In the Timeout field, type a timeout interval (in seconds) for the AAA server. This setting is optional. 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 time frame, in seconds. 24

25 BIG-IP Access Policy Manager Authentication Configuration Guide If the server does not respond, the Access Policy Manager retries the authentication attempt, depending on how many retries you specify. 10. Click Finished to add the new server to the configuration, and return to the main screen. The new Active Directory server is added to the AAA Server List. Completing the authentication process for Active Directory Before you set up your access policies to complete the authentication process, you must have at least one authentication server configured. 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. On the menu bar, click Access Policy. The Access Policy screen opens. 4. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 5. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 6. For Predefined Actions, under Authentication, select AD Auth or AD query. and click Add item. 7. Select the AAA Active Directory server you want to associate with the access policy, and click Save. If you are adding, AD query, make sure to specify the SearchFilter setting. If you choose to enable Cross Domain Auth Support, you must use a variable assignment agent between the Logon page agent and the AD auth agent in your access policy. The custom variable assignment agent maps a non-canonical doman name to a full domain name used by the Active Directory agent. Otherwise, an AD Auth error can occur since the AD agent is unable to authenticate users, such as user@domainname. Here are some other workarounds to map non-canonical names for AD auth: Configure the DNS suffixes properly (either at your corporate DNS server or on your BIG-IP system) to be able to resolve short non-canonical domain names. Configure an external logon page and create a pull-down element with pre-defined domains. In this case, the user can select the domain they want to use, and just type their username and password and then select their domain. Their selection is mapped to a FQDN at the external logon page and saved as session.logon.last.domain session variable. 8. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overrall authentication process. Attention: If you use AD query, Access Policy Manager does not query for the primary group and add it to the memberof attribute. You must manually look up the attribute memberof as well as the primary group. 25

26 Authentication Methods Active Directory's cross-domain support rules Active Directory's cross-domain rules Rules Cross-domain support and split domain from username are both enabled Explanation If you enable cross domain support, enable split domain username at the logon page, and the user enters his/her username such as Access Policy Manager will use the as the user principal name to authenticate the user. Cross-domain support is enabled but split domain from username is disabled Access the Access Policy Manager handles the user's input as a simple username and escape "@" and "\" chars. In other words, Access Policy Manager will use user\@[email protected] to authenticate the user. If user does not specify a user's domain Regardless of whether split domain from username option is enabled or disabled, Access Policy Manager will use [email protected] to authenticate the user. About using external servers for 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 particular authentication method uses external web-based servers to validate user logon/login IDs and passwords. Tip: Use HTTPS instead of HTTP basic authentication for better security, because basic authentication passes user credentials as clear text. However, to support HTTPS authentication, you must set up and configure Access Policy Manager through a layered virtual server. Access Policy Manager supports the following HTTP authentication types: HTTP basic authentication HTTPS basic authentication HTTP NTLM authentication HTTP form-based authentication What are hidden parameters? If you choose to use HTTP form-based authentication for your external server, you must provide hidden form parameters and values. These values are required by the authentication server login form at your location. 26

27 BIG-IP Access Policy Manager Authentication Configuration Guide Task summary for configuring an external, web-based server for HTTP authentication To set up this configuration, perform the procedures in the task list. You can choose to configure with either HTTP NTLM or HTTP form-based. Task List Configuring an external server for HTTP NTLM method Configuring an external server for HTTP form-based method Completing the authentication process for HTTP or HTTPS Configuring for HTTPS authentication Setting up the access profile using the HTTP agent Completing the authentication process for HTTP or HTTPS Adding Access Policy Manager as an agent host to RSA Native SecurID server Configuring for RSA Native SecurID authentication Completing the authentication process for RSA Native SecurID Configuring an external server for HTTP NTLM method 1. On the Main tab, click Access Policy > AAA Servers. 2. Type a name for the authentication server you are creating. 3. For Auth Type, select Basic/NTLM. 4. In the Start URI field, type the complete URI that returns the logon form. The URI resource must respond with a challenge to a non-authenticated request, whereas the basic authentication method supports authentication over both HTTP and HTTPS protocols. 5. Click Finished to add the new server to the configuration, and return to the main screen. Configuring an external server for HTTP form-based method 1. On the Main tab, click Access Policy > AAA Servers. 2. Type a name for the authentication server you are creating. 3. For Authentication Type, select Form Based. 4. In the Start URI field, type in a URL resource, for example, This resource must respond with a challenge to a non-authenticated request. While this field is mandatory for Basic/NTLM, it is optional for Form Based. Using the Start URI field slightly differs for each authentication type. For example, if you select to use Form Based, you are not required to enter a URL resource since the form action field specifies either an absolute URL or relative URL resource. However, if you select to use Form Based and choose to specify both the Start URI and form action, then Access Policy Manager will use both Start URI and form action parameters as the final URL for HTTP POST. Otherwise, if you do not specify a Start URI, Access Policy Manager will likely detect that the absolute URI based on the form action parameter should be used for HTTP POST. 5. From the Form Method list, select either GETor POST. If you specify GET, the authentication request converts as HTTP GET. 6. In the Form Action field, type the complete destination URL to process the form. This is used to specify the form action URL which is used for doing HTTP form-based authentication. This is optional. If you 27

28 Authentication Methods do not specify a form action, then Access Policy Manager uses the URI from the request to perform HTTP form-based authentication. 7. In the Form Parameter For User Name andand Form Parameter For Password fields, type the parameter name and password used by the form to which you are sending the POSTrequest. 8. In the Hidden Form Parameters/Values field, type the hidden form parameters required by the authentication server logon form at your location. 9. In the Number Of Redirects To Follow field, type the number of pages away from the landing page the request should travel before failing. 10. For the Successful Logon Detection Match Type setting, select the method your authenticating server uses, and specify the option definition. 11. Click Finished to add the new server to the configuration, and return to the main screen. Completing the authentication process for HTTP or HTTPS Before you set up your access policies to complete the authentication process, you must have at least one authentication server configured. 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. On the menu bar, click Access Policy. The Access Policy screen opens. 4. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 5. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 6. Select HTTP Auth and click Add item. If you are working with HTTPS, select HTTP auth 7. Select the AAA HTTP server you want to associate to the access policy, and click Save. 8. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overall authentication process. Task summary for configuring an external, web-based server for HTTP authentication To set up this configuration, perform the procedures in the task list. You can choose to configure with either HTTP NTLM or HTTP form-based. Task List Configuring an external server for HTTP NTLM method Configuring an external server for HTTP form-based method Completing the authentication process for HTTP or HTTPS Configuring for HTTPS authentication Setting up the access profile using the HTTP agent Completing the authentication process for HTTP or HTTPS Adding Access Policy Manager as an agent host to RSA Native SecurID server 28

29 BIG-IP Access Policy Manager Authentication Configuration Guide Configuring for RSA Native SecurID authentication Completing the authentication process for RSA Native SecurID Configuring for HTTPS authentication 1. On the Main tab, click Access Policy > AAA Servers. 2. Type a name for the authentication server you are creating. 3. For Auth Type, select Basic/NTLM. 4. In the Start URI field, type your URI resource, in this format: 5. Click Finished to add the new server to the configuration, and return to the main screen. Setting up the access profile using the HTTP agent 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. Add the HTTP agent to your access policy, and make sure to select the virtual HTTP server you created. This is important so that the HTTPS traffic goes through the virtual server. 4. Click Apply Access Policy to save your configuration. Completing the authentication process for HTTP or HTTPS Before you set up your access policies to complete the authentication process, you must have at least one authentication server configured. 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. On the menu bar, click Access Policy. The Access Policy screen opens. 4. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 5. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 6. Select HTTP Auth and click Add item. If you are working with HTTPS, select HTTP auth 7. Select the AAA HTTP server you want to associate to the access policy, and click Save. 8. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overall authentication process. 29

30 Authentication Methods About RSA Native SecurID authentication 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 code 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 card's SEED. Caution: If you use RSA Authentication Manager Version 7 or later, do not set the SecurID token policy's Character Requirements to Require alphabetic PINs. Due to the limitations of the current RSA SDK, the new alphabetic PIN option does not account for alphabetic-only PIN policies. Instead, set the token policy to either Require numeric PINS or Allow alpha-numeric PINs.. Figure 6: How RSA SecurID works 1. The client submits the user name and PIN code to Access Policy Manager. 2. Access Policy Manager sends the user specified inputs to the RSA authentication server. 3. Access Policy Manager then grants or denies access to the client based on the authentication results. Task summary for configuring an external, web-based server for HTTP authentication To set up this configuration, perform the procedures in the task list. You can choose to configure with either HTTP NTLM or HTTP form-based. Task List Configuring an external server for HTTP NTLM method Configuring an external server for HTTP form-based method Completing the authentication process for HTTP or HTTPS Configuring for HTTPS authentication Setting up the access profile using the HTTP agent Completing the authentication process for HTTP or HTTPS Adding Access Policy Manager as an agent host to RSA Native SecurID server Configuring for RSA Native SecurID authentication Completing the authentication process for RSA Native SecurID Adding Access Policy Manager as an agent host to RSA Native SecurID server 1. On the administrative interface of your RSA Native SecurID authentication server, click the Agent Host tab, and select the Add Agent item. 30

31 BIG-IP Access Policy Manager Authentication Configuration Guide 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, and 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. 4. From the Agent Type list, select UNIX agent. 5. For Encryption Type, select DES. 6. Verify that the Node Secret Created check box is cleared. 7. Select the Open to All Locally Known Users check box. 8. Select the Search Other Realms for Known Users check box. 9. Select the Requires Name Lock check box. 10. Clear any selection from the check fields 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. If you want to perform high availability processing with RSA native SecurID, you must create a floating IP address for the Agent host from the RSA server. Also, you need to define the static self-ip addresses of the nodes as secondary nodes. The Configuration file generated on the RSA server contains all three IP addresses, so the originating traffic from any of the subnodes will be accepted Save the agent host configuration file onto your local system, and click OK. 15. Add users who are authorized to use the Access Policy Manager. Refer to the RSA Native SecurID authentication server administrator guide for more information. The Access Policy Manager is now added as an agent host to the RSA Native SecurID server. As a result, the agent host record will identify the Access Policy Manager within the server authentication database, and will include information about communication and encryption. Configuring for RSA Native SecurID authentication To enable communication between the Access Policy Manager and an RSA Native SecurID authentication server, you must first add the Access Policy Manager as an agent host to the Native SecurID authentication server. Then you can configure Access Policy Manager to use RSA Native SecurID for authentication. 1. On the Main tab, click Access Policy > AAA Servers. 2. Scroll down to the type of AAA server you want to create and click the Create (+) button. A New Server General Properties screen opens. 3. Type a name for the authentication server you are creating. 4. In the Configuration area, for the Agent Host IP Address (must match the IP address in SecurID Configuration File) setting, if there is a NAT device in the network path between the Access Policy Manager and the RSA SecurID server, select Other and type the address as translated by the NAT device. Otherwise, select the Select from Self IP List and select from those configured on the Access Policy Manager. Please note that the source IP address of the packets does not change, but only the information with the SecurID packet changes. In other words, only Layer 7 information is changed while Layer 3 source addresses remain unchanged. This is required when authenticating to the RSA Authentication Manager server. 31

32 Authentication Methods 5. For the SecurID Configuration File setting, browse to upload the sdconf.rec file from your authentication server. Consult your RSA Authentication Manager administrator to obtain this file. 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. 6. Click Finished to add the new server to the configuration, and return to the main screen. Your new RSA Native SecurID server is added to the AAA Servers list. Completing the authentication process for RSA Native SecurID Before you set up your access policies to complete the authentication process, you must have at least one authentication server configured. 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 3. On the menu bar, click Access Policy. The Access Policy screen opens. 4. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 5. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 6. From the Authentication list of Predefined Actions, select RSA SecurID and click Add Item. 7. From the AAA Server list, select the RSA Native SecurID server you want to associate to the access policy, and click Save. 8. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overrall authentication process. About OCSP authentication Access Policy Manager supports authenticating and authorizing the client against Online Certificate Status Protocol (OCSP). OCSP is a mechanism used to retrieve the revocation status of an X.509 certificate by sending the certificate information to a remote OCSP responder. This responder maintains up-to-date information about the certificate's revocation status. OCSP ensures that Access Policy Manager always obtains real-time revocation status during the certificate verification process. Attention: Access Policy Manager must include an OCSP server configuration for every OCSP server that exists. Task summary for OCSP authentication To set up this configuration, perform the procedures in the task list. 32

33 BIG-IP Access Policy Manager Authentication Configuration Guide Task List Configuring for CRLDP authentication and authorization Configuring clientssl profile for OCSP Configuring for CRLDP authentication and authorization 1. On the Main tab, click Access Policy > AAA Servers. 2. Scroll down to the type of AAA server you want to create and click the Create (+) button. A New Server General Properties screen opens. 3. Type a name for the authentication server you are creating. 4. Type the URL used to contact the OCSP service on the responder. For information on all other settings, please refer to the online help as they are optional settings. Configuring clientssl profile for OCSP 1. On the Main tab, click Local Traffic > Profiles > SSL > Client. The SSL Client profile list screen opens. 2. In the Name field, type a name for the profile. Names must begin with a letter, and can contain only letters, numbers, and the underscore (_) character. 3. From the Parent Profile list, select a profile from which the new profile inherits properties. 4. From the Client Certificate list, depending on the agent you select when you edit the access policy, select the proper option. Select request if the client cert agent is used in the access policy. Select ignore if the On-Demand Cert Auth agent is used instead. 5. From the Trusted Certificate Authorities list, select a certificate authority. 6. From the Advertised Certificate Authorities list, select the advertised Certificate Authority file for client certificate authentication. 7. Click Finished. Completing the authentication process for OCSP 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. Click Create. The New Profile screen opens. 3. Type a name for the access profile. Names must begin with a letter, and can contain only letters, numbers, and the underscore (_) character. 4. Click Finished. 5. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 6. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 7. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 33

34 Authentication Methods 8. Under Predefined Actions, from the Authentication list, select either Client Cert Authentication or On-Demand Cert Auth, and click Add item. 9. Select CRLDP Auth, and click Add item. 10. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overall authentication process. Policy example for OCSP authentication This is an example of an access policy with all the associated elements needed to authenticate and authorize your users with OCSP authentication. Notice that you must add either the client cert check or On-Demand Cert Auth agent before the CRLDP Auth object in your access policy. One of those agents is required in order to receive the x509 certificate from the user. This is also important since both agents store the user information as well as the issuer certificates in the session variables. This allows the OCSP Auth agent to check the revocation status of the user's certificate. Figure 7: How OCSP works About CRLDP authentication Access Policy Manager supports authenticating and authorizing the client against Certificate Revocation List Distribution Point (CRLDP) servers. CRLDP is a mechanism used to distribute certificate revocation information across a network. Specifically, a distribution point is a Uniform Resource Identifier (URI) or directory name in a certificate that identifies how the server obtains CRL information. You an use distribution points in conjunction with CRLs to configure certificate authorization using any number of LDAP servers. Attention: For every CRLDP server, a CRLDP server configuration must exist on Access Policy Manager. Task summary for CRLDP authentication To set up this configuration, perform the procedures in the task list. Task List Configuring for CRLDP authentication and authorization Configuring clientssl profile for CRLDP 34

35 BIG-IP Access Policy Manager Authentication Configuration Guide Configuring for CRLDP authentication and authorization 1. On the Main tab, click Access Policy > AAA Servers. 2. Type a name for the authentication server you are creating. 3. Select one of the following options: Select Use Pool to set up high availability for the AAA server. Select Direct to set up the AAA server for standalone functionality. 4. Type a name for the AAA server pool if you selected Use Pool. 5. Type in a server address for the AAA server. Or, if you selected Use Pool, type in the IP addresses of the pool members, and click Add. 6. Select a monitor to track the health of the AAA server. This is optional. 7. Type in a CRLDP service port or choose from the list. The default is For Base DN, type a CRLDP base distinguished name for certificates that specify the CRL distribution point in directory name (dirname) format. This is used when the value of the X509v3 attribute crldistributionpoints is of type dirname. In this case, the Access Policy Manager attempts to match the value of the crldistributionpoints attribute to the Base DN value. An example of a Base DN value is cn=lxxx,dc=f5,dc=com. For information on all other settings, please refer to the online help as they are optional settings. Configuring clientssl profile for CRLDP 1. On the Main tab, click Local Traffic > Profiles > SSL > Client. The SSL Client profile list screen opens. 2. In the Name field, type a name for the profile. Names must begin with a letter, and can contain only letters, numbers, and the underscore (_) character. 3. From the Parent Profile list, select a profile from which the new profile inherits properties. 4. From the Client Certificate list, depending on the agent you select when you edit the access policy, select the proper option. Select request if the client cert agent is used in the access policy. Select ignore if the On-Demand Cert Auth agent is used instead. 5. From the Trusted Certificate Authorities list, select a certificate authority. 6. From the Advertised Certificate Authorities list, select the advertised Certificate Authority file for client certificate authentication. 7. Click Finished. Completing the authenticaiton process for CRLDP 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. Click Create. The New Profile screen opens. 3. Type a name for the access profile. Names must begin with a letter, and can contain only letters, numbers, and the underscore (_) character. 35

36 Authentication Methods 4. Click Finished. 5. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 6. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 7. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 8. Select either Client Cert Check or On-Demand Cert Auth, and click Add item. 9. Select CRLDP Auth, and click Add item. 10. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overall authentication process. Access policy example for CRLDP authentication This is an example of an access policy with all the associated elements needed to authenticate and authorize your users with CRLDP authentication. Notice that you must add either the client cert check or On-Demand Cert Auth agent before the CRLDP Auth object in your access policy. One of those agents is required in order to receive the x509 certificate from the user. This is also important since both agents store the user information, as well as the issuer certificates, in the session variables. This allows the CRDLP Auth agent to check the revocation status of the user's certificate. Figure 8: How CRLDP works About TACACS+ authentication and accounting Access Policy Manager supports authenticating and authorizing the client against Terminal Acess Controller Access Control System (TACACS+) servers. TACACS+ is a mechanism used to encrypt the entire body of the authentication packet. If you use TACACS+ authentication, user credentials are authenticated on a remote TACACS+ server. If you use the TACACS+ Accounting feature, the accounting service sends start and stop accounting records to the remote server. Attention: Access Policy Manager must include a TACACS+ server configuration for every TACACS+ server that exists. Task summary for TACACS+ authentication and accounting To set up this configuration, perform the procedures in the task list. 36

37 BIG-IP Access Policy Manager Authentication Configuration Guide Task List Configuring for TACACS+ authentication and authorization Completing the authentication process for TACACS+ Configuring for TACACS+ authentication and authorization 1. On the Main tab, click Access Policy > AAA Servers. 2. Type a name for the authentication server you are creating. 3. Select one of the following options: Select Use Pool to set up high availability for the AAA server. Select Direct to set up the AAA server for standalone functionality. 4. Type a name for the AAA server pool if you selected Use Pool. 5. Type in a server address for the AAA server. Or, if you selected Use Pool, type in the IP addresses of the pool members, and click Add. 6. Select a monitor to track the health of the AAA server. This is optional. 7. Type in a TACACS+ service port or select one from the list. The default is Type in a secret key to use to encrypt and decrypt packets sent or received from the server, and then re-type the secret key to confirm. 9. For the Service setting, select the name of the service that the user is requesting to be authenticated to use. Identifying what the user is asking to be authenticated for enables the TACACS+ server to behave differently for different types of authentication requests. You can use following values: login, slip, ppp, arap, shell, tty-daemon, connection, system, and firewall. For information on all other settings, please refer to the online help as they are optional settings. 10. Click Finished to add the new server to the configuration, and return to the main screen. Completing the authentication process for TACACS+ 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. Click Create. The New Profile screen opens. 3. Type a name for the access profile. Names must begin with a letter, and can contain only letters, numbers, and the underscore (_) character. 4. Click Finished. 5. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 6. Click Edit Access Policy for Profile profile_name. The visual policy editor opens the access policy in a separate window or tab. 7. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 8. Select either Client Cert Check or On-Demand Cert Auth, and click Add item. 9. Select TACACS+ Auth, and click Add item. 10. Optionally select TACACS_Acct if you want to add it as part of your access policy. 37

38 Authentication Methods 11. Click Apply Access Policy to save your configuration. The authentication server is added to the access policy, and completes the overall authentication process. Policy example for TACACS+ authentication and accounting This is an example of an access policy with all the associated elements needed to authenticate and authorize your users with TACACS+ authentication. Note that the server used for authentication can be different from the server used for TACACS+ accounting service. Figure 9: How TACACSPLUS works 38

39 Chapter 3 AAA and Configuring High Availability Topics: Task summary for configuring AAA high availability

40 AAA and Configuring High Availability Task summary for configuring AAA high availability Using AAA high availability with Access Policy Manager, you can configure multiple authentication servers to process requests, so that if one authentication server goes down or loses connectivity, the others can resume authentication requests, and new sessions can be established, as usual. The Access Policy Manager supports the following authentication servers for high availability: RADIUS, LDAP, Active Directory, CRLDP, and TACACS+. With the exception of Active Directory, you can set up any of these for high availability through the AAA Server menu as you create your AAA server objects. Note: Although new authentications will fail if the BIG-IP system loses connectivity to the server, existing sessions are unaffected as long as they do not attempt to re-authenticate. When you use RADIUS as the authentication method for AAA high availability, there are general guidelines that you must follow when you set up your server connections. In a non high availability environment, both the Direct and Use Pool options use the self IP address as a source IP address of the packet reaching the RADIUS server. For this scenario, you just need to add one IP address to the RADIUS allowed IP list to achieve this. In a high availability environment where the Use Pool option is used, the floating self IP address is used as a source IP of the radius packet reaching the back-end. For this scenario, you need to add one self IP address (which is floating self IP address) to the RADIUS allowed IP list because the IP address is used even after a failover occurs. In a high availability environment where the Direct option is used, the self IP address is used as a source IP address of the radius packet reaching the back-end. In this scenario, you need to add the self IP address from both active and standby units to the RADIUS allowed IP list so that when failover occurs, the self IP address from the second box is accepted by the Radius server. To set up this configuration, follow the procedures in the task list. Task List Setting up a AAA server object for high availability Testing AAA high availability for all supported authentication servers Upgrading an Access Policy Manager high availability failover pair Setting up a AAA server object for high availability You can set up high availablity for each authentication server by specifying IP addresses of the pool members that you want to use as part of this feature. However, configuring high availablity through the AAA server menu is currently supported only for RADIUS, LDAP, CRLDP, and TACACS+ server types. 1. On the Main tab, click Access Policy > AAA Servers. 2. Scroll down to the type of AAA server you want to create and click the Create (+) button. A New Server General Properties screen opens. 3. Type a name for the authentication server you are creating. 4. For the Server Connection setting, select Use Pool. 5. Type a name for the server pool. 6. For the Server Addresses setting, type in the IP addresses of the pool members, and click Add. 7. Select a monitor to track the health of the AAA server. 40

41 BIG-IP Access Policy Manager Authentication Configuration Guide This is optional. 8. Specify all settings based on the authentication server that you selected. For Active Directory, you need to add the virtual server name to the Access Policy Manager's /etc/hosts file in order for it to resolve correctly. This should point to the dunmy virtual server IP address, and is used for reverse DNS resolution. Additionally, you should supply the following information to your DNS Server: An address (A) record for the virtual server A reverse-dns (PTR) record for the virtual server Service Location (SRV) records for TCP Service Location (SRV) records for UDP 9. Click Finished to add the new server to the configuration, and return to the main screen. Testing AAA high availability for all supported authentication servers To effectively test that high availability works for your authentication servers, you should have two servers that are accessible, where you can remove one of them from the network. 1. Begin a TCPDump on the Access Policy Manager, using a protocol analyzer, and scanning for packets destined for the specific port for your authentication server. 2. Log in to the virtual server with both servers active. 3. Verify using the TCP dump that the requests are being sent to the higher priority server. 4. Log out of the virtual server. 5. Disable the higher-priority server. 6. Log in to the virtual server again. 7. Verify that the request is being sent to the other 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. Upgrading an Access Policy Manager high availability failover pair To ensure that upgrading a failover pair is successful, make sure that the Local Traffic Manager active/standby units were configured correctly if you are migrating from a previous version. Attention: During the upgrade, all users currently logged on to the system will have to log on again. 1. Connect to a standby unit of a failover pair. 2. Upgrade the standby unit. 3. Press Force offline on the unit to trigger a failover to this newly upgraded unit. The newly upgraded unit will take over as the active unit. 4. Once the upgraded unit takes over as active, restart the upgraded unit. This extra step of additional restart is required to flush out any of the old sessions which may been introduced from the the previously active unit from an older version of the software. 5. Wait for the upgraded unit to come back up. 6. Once the upgraded unit becomes the active unit, bring the other unit back online by pressing Release offline. 41

42 AAA and Configuring High Availability This unit is now the standby unit. 7. Upgrade the standby unit. 42

43 Chapter 4 Configuring Kerberos Authentication with End-User Logons Topics: About basic authentication and Kerberos end-user logon

44 Configuring Kerberos Authentication with End-User Logons About basic authentication and Kerberos end-user logon Access Policy Manager provides an alternative to the current form-based login authentication method. This alternative method uses a browser login box, which is triggered by an HTTP 401 response to collect credentials. The HTTP 401 response is generated by either SPNEGO/kerberos or basic authentication challenges. This option is useful in situations where your user has already logged into the local domain, and you would like to avoid having to submit an APM HTTP form for collecting user credentials. The browser will automatically submit credentials to the server and bypasses the login box to collect the credentials again. Note: Since SPNEGO/Kerberos is a request-based authentication feature, the authentication process is different from other authentication methods, which only occurs during session creation time. SPNEGO/Kerberos authentication, however, could occur at any time during the whole session. The benefits of this feature include: Provides flexible login mechanism instead of restricting you to use only the form-based login method. Eliminates the need for domain users to explicitly type login information again to log in to the Access Policy Manager. Eliminates the need for user password transmission with Kerberos method. Important: Administrator should not turn off the KeepAlive setting on their web server since turning that setting off may interfere with Kerberos authentication. How does end-user login work? This feature provides two methods to retrieve user credentials for login: basic authentication or a Kerberos method. basic authentication Use this method to retrieve user credentials (user name and password) from a browser. You can think of this method as a replacement for form-based authentication used by the standard login screen. If you use basic authentication, the system populates the user name and password session variables, which can then be used by any other authentication actions, such as Active Directory or RADIUS. SPNEGO/Kerberos Use this method to retrieve user credentials through SPNEGO/Kerberos authentication header. With the Kerberos method, the client system must join a domain, and a Kerberos action follows. The Kerberos action does not run immediately; it will only run on requests from clients requesting SPNEGO/Kerberos authentication. The Kerberos authentication not only runs on the first request, but also runs on subsequent requests where the authentication is needed, such as for new connections. The request is validated by confirming that a valid ticket is present. Note: You can achieve multi-domain support for kerberos authentication through multiple virtual servers. Each server must have different access policies along with their own Kerberos configurations. Both methods require an HTTP 401 response action. This particular action selects either one or the other, or both mechanisms. In cases where both are selected, the browser determines which method is performed based upon whether the system has joined a domain. The HTTP 401 response action has two default branches to indicate whether basic authentication or Kerberos method is performed. 44

45 BIG-IP Access Policy Manager Authentication Configuration Guide Figure 10: How SPNEGO/Kerberos end-user login works The end-user login works in the following way: 1. The client becomes a member and connects to the domain. 2. The client then connects to a virtual server on the BIG-IP system. 3. The access policy runs and provides? presents? a 401 HTTP request action. 4. If Kerberos is present, the browser forwards the Kerberos ticket along with the request when it receives the 401 HTTP response. 5. Access Policy Manager validates the Kerberos ticket once the request is received, and determines whether or not to permit the request. Task summary for configuring end-user login support To set up this configuration, perform the procedures in the task list. You can choose to configure with either Basic authentication or Kerberos method. Task List Joining a domain Configuring for Kerberos authentication Completing the configuration for the end-user logon support Joining a domain The client must be joined and connected to a domain if the Kerberos method is used. 1. From the System Properties on a client machine, check to make sure the following parameters are set: domain controller, client machine, and APM vip. 2. Ensure that there is a user account in the domain. 3. Create a keytab file on the domain controller. For example, use ktpass utility to map the user account to service account and generate a keytab file for the service, for example, c:>ktpass -princ HTTP/john.testbed.lab.fp.companynet.com -mapuser john -crypto 45

46 Configuring Kerberos Authentication with End-User Logons rc4-hmac-nt -ptype KRB5_NT_SRV_HST -pass password -out c:\temp\john.keytab You must now create an access policy to include the appropriate agents. Configuring for Kerberos authentication 1. On the Main tab, click Access Policy > AAA Servers. 2. Scroll down to the type of AAA server you want to create and click the Create (+) button. A New Server General Properties screen opens. 3. Type a name for the authentication server you are creating. 4. In the Auth Realm field, type in a Kerberos authentication realm name (administrative name), such as [email protected]. 5. In the Service Name field, type in a service name, such as service name/hostname@kerberosrealm. This is used to verify incoming Kerberos token requests. 6. In the Keytab File field, click Browse to locate your Keytab file. A keytab file contains Kerberos encrypted keys (these are derived from the Kerberos password). You can use this file to log into Kerberos without being prompted for a password. 7. Click Finished to add the new server to the configuration, and return to the main screen. Completing the configuration for the end-user logon support 1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens. 2. Click Create. The New Profile screen opens. 3. Type a name for the access profile. Names must begin with a letter, and can contain only letters, numbers, and the underscore (_) character. 4. Click Finished. 5. On the Access Profiles List screen, click the name of the access profile for which you want to edit the access policy. The Access Profile properties screen opens for the profile you want to edit. 6. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens. 7. Under Predefined Actions, select HTTP 401 Response, and click Add item. The 401 Response Setting window opens. 8. From the HTTP Auth level list, select basic+negotiate, and click Save. The HTTP 401 Response agent is added to the access policy. 9. If you are performing basic authentication, add an authentiation server agent after the basic branch. 10. If you are performing Kerberos authentication method, add the Kerberos Auth agent after the negotiate branch, and specify the Kerberos AAA server. 11. Click Apply Access Policy. Access policy example for end-user logon This is an example of an access policy with all the associated elements needed to successful support the end-user login feature. Notice that separate branches were created to support using either basic authentication or Kerberos method to retrieve user credentials. 46

47 BIG-IP Access Policy Manager Authentication Configuration Guide Note: For basic authentication, the user name and password validation occurs at the session creation time. After the access policy completes, the session cookie is used to validate the session. Note: Kerberos runs not only at the access policy run time but also at any time in the session. Figure 11: Example access policy for end-user login? Figure 12: Example of branch rule for HTTP 401 response action 47

48 Configuring Kerberos Authentication with End-User Logons Figure 13: Example of branch rule for Kerberos method 48

49 Appendix A AAA Session Variables Topics: List of AAA session variables

50 AAA Session Variables List of AAA session variables Refer to these tables for all AAA authentication session variables and attributes. AAA server session variables for access policy rules You can authorize your users with user information provided by your authentication servers in the form of attributes. These attributes, converted into session variables, can be used to create rules. Session variables for RADIUS Session Variable session.radius.last.result Description Provides the result of the RADIUS authentication. The available values are: 0: Failed 1: Passed session.radius.last.attr.$attr_name session.radius.last.errmsg $attr_name is a value that represents the user s 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. Example: c76a50c0.session.radius.last.errmsg 13 Access-Reject Session variables for RSA Native SecurID Session Variable session.securid.last.result session.securid.last.attr.$attr_name Description 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 user s attributes received during RSA Native SecurID authentication. Each attribute is converted to separate session variables. Session variables Active Directory Session Variable session.ad.last.attr.$attr_name Description $attr_name is a value that represents the user s attributes received from the Active Directory. Each attribute is converted to separate session variables. 50

51 BIG-IP Access Policy Manager Authentication Configuration Guide Session Variable session.ad.last.attr.group.$attr_name Description group.$attr_name is a value that represents the user s group attributes received from the Active Directory. Each attribute is converted to separate session variables. Session variables for LDAP Session Variable session.ldap.last.authresult Description Provides the result of the LDAP authentication/query. The available values are: 0: Failed 1: Passed session.securid.last.attr.$attr_name session.ldap.last.errmsg session.ad.last.attr.$attr_name session.ad.last.attr.group.$attr_name $attr_name is a value that represents the user s attributes received during LDAP/query. Each attribute is converted to separate session variables. Useful for troubleshooting, and contains the last error message generated for LDAP. For example $attr_name is a value that represents the user s attributes received from the Active Directory. Each attribute is converted to separate session variables. group.$attr_name is a value that represents the user s group attributes received from the Active Directory. Each attribute is converted to separate session variables. Session variables for CRLDP Session Variable session.ldap.ssl.cert.whole session.ssl.cert.certissuer session.crldp.last.result session.crldp.last.status Description Provides a user certificate in PAM format. Issues a user certificate. Sets the result of the CRLDP authentication.the available values are: 0: Failed 1: Passed Sets the status of the authentication to Failed. Session variables for TACACS+ Session Variable session.logon.last.username; session.logon.last.password session.tacasplus.last.acct.start_date; session.tacasplus.last.acct.start_time Description Provides user credentials. The password string is stored after encrypting, using the system's master key. Provides TACACS+ accounting start time and date set by the accounting agent. 51

52 AAA Session Variables Session Variable session.tacacsplus.last.acctresult session.tacacsplus.last.errmsgs session.tacacsplus.last.result Description Allows the accounting agent to set the available values to either of the following values: 0: Failed 1: Succeeds Contains the error message string when the TACACS+ authentication or accounting fails. Sets to 1 when authentication succeeds, or 0 when it fails. Session variables for OCSP Session Variable session.ssl.cert.whole session.ssl.cert.certissuer session.ocsp.last.result session.ocsp.last.status Description Provides a user certificate in PAM format. Issues a user certificate. Sets the result of the OCSP authentication.the available values are: 0: Failed 1: Passed Sets the status of the authentication to Failed. 52

53 Appendix B AAA Configuration Examples Topics: AAA server configuration examples

54 AAA Configuration Examples AAA server configuration examples This appendix includes AAA configuration examples for all authentcation methods. Example for converting hex attributes The following are examples for converting hex attributes for RADIUS, Active Directory, and LDAP. Handling of binary value attribute for RADIUS For RADIUS authentication, we convert attributes to hex if they have unprintable characters, or they are based on attribute type. We convert class attribute to hex even if it contains only printable values (by attribute type). No other attributes are encoded to hex if they do not contain unprintable characters. Case 1: Handling of attributes with single value 1bf80e04.session.radius.last.attr.class 62 / 0x ac1d423301caa87483dadf Case 2: Handling of attributes with multiple values (mix of binary and non binary values) 243be90d.session.radius.last.attr.class 119 0x / a6b6c6d6e6f a 0x ac1d423301caa87483 / dadf If the attribute type does not require hex encoding, and some of the values are unprintable, then only those value(s) are encoded to hex: 3888eb70.session.radius.last.attr.login-lat-group 37 0x6d7920bda f mygroup1 Handling of binary value attribute for Active Directory For Active Directory, we cannot base the conversion on attribute type. The decision to convert attribute value to hex is made only if the value contains unprintable characters. If the session variable contains several values, and one or more of those values is unprintable, then we convert only those particular values to hex. Case 1: Handling of attributes with single value 7ecc84a2.session.ad.last.attr.objectSid 58 / 0x fe8e97c03cd5b5ad04e2e

55 BIG-IP Access Policy Manager Authentication Configuration Guide Case 2: Handling of attributes with multiple values (mix of binary and non binary values) 7ecc84a2.session.ad.last.attr.memberOf 460 CN=printable group,ou=groups,ou=f5,dc=sherwood,dc=labt,dc=fp,dc=f5net,dc=com 0x434e3d756e e c6520c2bdc2a f75702c4f553d67726f c4f553d66352 / c44433d f6f642c44433d6c c44433d66702c44433d66356e65742c44433d636f6d / CN=Domain Users,CN=Users,DC=sherwood,DC=labt,DC=fp,DC=f5net,DC=com / CN=CERTSVC_DCOM_ACCESS,CN=Users,DC=sherwood,DC=labt,DC=fp,DC=f5net,DC=com / CN=Users,CN=Builtin,DC=sherwood,DC=labt,DC=fp,DC=f5net,DC=com Handling of binary value attribute for LDAP The conversion of attributes to hex for LDAP is identical to Active Directory. Case 1: Handling of attributes with single value 9302eb80.session.ldap.last.attr.objectGUID 34 0xfef232d3039be9409a72bfc60bf2a6d0 Case 2: Handling of attributes with multiple values (mix of binary and non binary values) 29302eb80.session.ldap.last.attr.memberOf 251 CN=printable group,ou=groups,ou=f5,dc=sherwood, / DC=labt,DC=fp,DC=f5net,DC=com / 0x434e3d756e e c6520c2bdc2a f75702c / 4f553d67726f c4f553d66352c / 44433d f6f642c44433d6c c44433d66702 / c44433d66356e65742c44433d636f6d Example of authenticating and authorizing users with Active Directory This is an example of an access policy with all the associated elements that are needed 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. 55

56 AAA Configuration Examples Figure 14: Example of an access policy for AD auth and query Example of LDAP auth and query default rules 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 following figure, the rule for LDAP query was changed from default rule to check for user s group attribute. Figure 15: Example of an access policy for LDAP auth query 56

57 Appendix C Troubleshooting AAA Configurations Topics: List of troubleshooting tips for authentication

58 Troubleshooting AAA Configurations List of troubleshooting tips for authentication Refer to these tables for all AAA server authentication troubleshooting tips. RADIUS authentication and accounting troubleshooting tips You may run into problems with RADIUS authentication and accounting in some instances. Follow these tips to try to resolve any issues you may encounter. RADIUS authentication and accounting access policy action troubleshooting Possible error messages Authentication failed due to timeout Possible explanations and corrective actions 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 server is valid. Check that the user credentials are entered correctly. Additional troubleshooting tips for RADIUS authentication and accounting You should Check to see if your access policy is attempting to perform authentication Steps to take 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 and accounting attempts by the access policy. Note: Make sure that your log level is set to the appropriate level. The default log level is notice Check the RADIUS Server configuration Confirm that the Access Policy Manager is registered as a RADIUS client. 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. Check the RADIUS logs and check for any errors. Confirm network connectivity 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 1812 is not blocked between the Access Policy Manager and the RADIUS server. 58

59 BIG-IP Access Policy Manager Authentication Configuration Guide You should Capture a TCP dump Steps to take Take a TCP dump from the Access Policy Manager when authentication attempts are made. For example, %TCP dump-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 TCP dump, download the TCP dump records to a client system, and use an analyzer to troubleshoot. Important: If you decide to escalate the issue to customer support, you must provide a capture of the TCP dump when you encounter authentication issues that you cannot otherwise resolve on your own. LDAP authentication and query troubleshooting tips You may run into problems with LDAP authentication and query in some instances. Follow these tips to try to resolve any issues you may encounter. LDAP auth and query troubleshooting Possible error messages LDAP auth failed LDAP query failed Possible explanations and corrective actions User name or password does not match records. No LDAP server is associated with the LDAP Auth agent. The target LDAP server host/port information associated with the LDAP Auth agent may be invalid. The target LDAP service may be not accessible. The specified administrative credential is incorrect. If no administrative credential is specified, then the user name or password does not match. No LDAP server is associated with the LDAP query agent. The target LDAP server host/port information associated with the LDAP query agent may be invalid. The target LDAP service may be not accessible. If the LDAP query is successfully, then check whether the LDAP query Rules are properly configured. Additional troubleshooting tips for LDAP authentication You should Check that your access policy is attempting to perform authentication Steps to take 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. 59

60 Troubleshooting AAA Configurations You should Steps to take Note: Make sure that your log level is set to the appropriate level. The default log level is notice Confirm network connectivity 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. Confirm network connectivity 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 1812 is not blocked between the Access Policy Manager and the RADIUS server. Check the LDAP server configuration 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. Capture a TCP dump Take a TCP dump 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 TCP dumps indicate activities between the Access Policy Manager and the authentication server. Run the authentication test. After authentication fails, stop the TCP dump, and download the TCP dump to a client system, and use an analyzer to troubleshoot. Important: If you decide to escalate the issue to customer support, you must provide a capture of the TCP dump when you encounter authentication issues that you cannot otherwise resolve on your own. 60

61 BIG-IP Access Policy Manager Authentication Configuration Guide Active Directory authentication and query troubleshooting tips You may run into problems with Active Directory authentication and query processes? in some instances. Follow these tips to try to resolve any issues you may encounter. Active Directory auth and query troubleshooting Possible error messages Domain controller reply did not match expectations.( ) Possible explanations and corrective actions This error occurs when the principal/domain name does not match the domain controller server s 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: default_realm = SALES SALES = { domain controller = (domain controller server) admin = (admin server) 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 Additional troubleshooting tips for Active Directory authentication You should Check that your access policy is attempting to perform authentication Steps to take 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. Confirm network connectivity 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 box. 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, use NTP to set the correct time on the Access Policy Manager. Capture a TCP dump Take a TCP dump from the Access Policy Manager when authentication attempts are made. For example, %tcpdump-i 1.1 -s /tmp/dump. You 61

62 Troubleshooting AAA Configurations You should Steps to take must first determine what interface the self-ip 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 TCP dump, and download the TCP dump to a client system, and use an analyzer to troubleshoot. Important: If you decide to escalate the issue to customer support, you must provide a capture of the TCP dump when you encounter authentication issues that you cannot otherwise resolve on your own. RSA SecurID on Windows using RADIUS configuration troubleshooting tips You may run into problems with RSA SecurID on Windows using RADIUS configuration. Follow these tips to try to resolve any issues you may encounter. RSA SecurID on Windows using RADIUS configuration troubleshooting Possible error messages The RADIUS server is inactive The SecurID is configured incorrectly for RADIUS authentication No response from the RSA SecurID server Possible explanations and corrective actions 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 ID. 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, you must add an Agent Host recordto the RSA Authentication Manager database. The Agent Host record identifies the Access Policy Manager within its database, and contains information about communication and encryption. To create the Agent Host record, you need the following information. Host name IP addresses for all network interfaces RADIUS secret (Click Assign/Change Encryption Key to enter 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. 62

63 Index Index A AAA configuration examples 54 AAA session variables list of 50 AAA troubleshooting tips list of 58 about 11 accounting attributes descriptions 18 list of 18 Active Directory authentication and query session variables descriptions 50 Active Directory cross-domain rules 26 Active Directory password management about 24 Active Directory troubleshooting tips list of 61 attributes for radius 16 authentication configuring end-user login 45 configuring for external server 27, 28, 30 configuring for LDAP 22 deploying with Access Policy Manager 10 authentication methods for Active Directory 24 for CRLDP 34 for LDAP 20 for LDAPS? 20 for OCSP 32 for RADIUS 15 for RADIUS accounting 17 for RSA Native SecurID 30 for TACACS+ 36 overview 14 B basic authentication and Kerberos end-user logon about 44 C CRLDP about 34 CRLDP access policy example 34, 36 CRLDP session variables descriptions 50 E end-user login how-to 44 end-user logon access policy example 46 external servers about 26 H hex attributes converting 54 hidden parameters about 26 high availability 40 L LDAP auth and query default rules example 55, 56 LDAP authentication and query session variables descriptions 50 LDAP troubleshooting tips list of 59 N nested groups 11 O OCSP about 32 authenticating with 32 OCSP session variables descriptions 50 Q query types for LDAP and Active Directory 11 R RADIUS attributes descriptions 16 list of 16 RADIUS session variables descriptions 50 RADIUS troubleshooting tips list of 58 63

64 Index RSA Native SecurID session variables descriptions 50 RSA SecurID on Windows troubleshooting tips list of 62 S server object setting up for high availability 40 T TACACS+ about 36 TACACS+ access policy example 38 TACACS+ session variables descriptions 50 troubleshooting tips for LDAP 59 64