Access Policy Manager(APM) interacts with authentication, authorization, and accounting (AAA) servers that contain user information. APM supports these AAA servers: RADIUS (authentication and accounting), Active Directory (authentication and query), LDAP (authentication and query), CRLDP, OCSP Responder, TACACS+ (authentication and accounting), SecurID, Kerberos, and HTTP.

A typical configuration includes:

• An APM AAA server configuration object that specifies information about the external AAA server.
• An access policy that includes a logon item to obtain credentials and an authentication item that uses the credentials to authenticate against a specific AAA server.

Using AAA high availability with Access Policy Manager (APM), 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. APM supports these AAA servers for high availability: RADIUS, Active Directory, LDAP, CRLDP, and TACACS+.

A typical configuration includes:

• An APM AAA server configuration object that specifies a pool of external AAA servers.
• An access policy that includes a logon item to obtain credentials and an authentication item that uses the credentials to authenticate against one of the servers in the pool.

When an AAA server supports high availability, you can configure a pool for it in the AAA configuration itself. An AAA server does not load balance over a pool that is attached to a virtual server.

To use route domains for AAA authentication traffic, you must use the pool option in the AAA server configuration. When Use Pool is the selected Server Connection option, the server address field can take an IP address with route domain (IPAddress%RouteDomain) format. The route domain value is ignored when the AAA server is configured to connect directly to a single server.

You can add multiple authentication types to an access policy. For example, a user who fails Active Directory authentication might then attempt RADIUS authentication. Or, you might require authentication using a client certificate and then an AAA server.

You can add an authentication item anywhere in the access policy. Typically, you place authentication items somewhere after a logon item.

Access Policy Manager (APM) supports these types of certificate authentication.

SSL handshake verification and certificate revocation status

APM supports verifying the SSL handshake that occurs at the start of a session or renegotiating the SSL handshake and checking it on demand. A typical configuration includes:

• An access policy that includes a certificate-related access policy item, either Client Cert Inspection or On-Demand Cert Auth.
• A client SSL profile configured per the requirements of Client Cert Inspection or On-Demand Cert Auth.

Note: If the client SSL profile specifies a certificate revocation list, the access policy item verifies against it.

Certificate revocation status with OCSP or CRLDP

APM also supports verifying client certificate revocation status with an Online Certificate Status Protocol (OCSP) AAA server or with a Certificate Revocation List Distribution Point (CRLDP) AAA server. A typical configuration includes:

• An AAA server configured to point to an external server (OCSP Responder or CRLDP).
• An access policy that includes either a Client Cert Inspection or an On-Demand Cert Auth access policy item and the appropriate authentication item (OCSP Auth or CRLDP Auth).
• A client SSL profile configured per the requirements of Client Cert Inspection or an On-Demand Cert Auth.

Before systems on a network can authenticate one another using SSL, you must install one or more SSL certificates on the BIG-IP system. An SSL certificate is a certificate that a BIG-IP system device presents to another device on the network, for authentication purposes. An SSL certificate can be either a self-signed certificate or a trusted CA certificate.

When you install BIG-IP software, the application includes a self-signed SSL certificate named Default. A self-signed certificate is an authentication mechanism that is created and authenticated by the system on which it resides.

If your network includes one or more certificate authority (CA) servers, you can replace the self-signed certificate on each BIG-IP system with a trusted CA certificate, that is, a certificate that is signed by a third party. Authenticating BIG-IP systems using trusted CA certificates is more secure than using self-signed certificates.

To ease the task of creating certificate requests and sending them to certificate authorities for signature, the BIG-IP system provides a set of certificate management screens within the BIG-IP Configuration utility.

Access Policy Manager (APM) supports authentication against a database that you create on the BIG-IP system using the Configuration utility. You can employ a local user database for on-box authentication or to control access to external AAA servers.

A typical configuration includes:

• A local user database that you create and populate using the Configuration utility.
• An access policy that includes a local user database authentication item.

Access Policy Manager (APM) supports guest access with one-time password generation and verification. A typical configuration includes:

• An SMTP server for sending email or an HTTP AAA server for sending a text message.
• An access policy that includes items to generate a one-time password (OTP), send the generated password to a user, enable the user to log on, and verify the OTP that the user enters.

Access Policy Manager (APM) supports NTLM and HTTP basic authentication for Microsoft Exchange clients and for this support requires an Exchange profile, created in the Configuration utility. Configuration requirements for NTLM and HTTP basic authentication for Microsoft Exchange clients are otherwise distinct.

You can access all of the following APM documentation from the AskF5 Knowledge Base located at http://support.f5.com/.