Applies To:

Show Versions Show Versions

Manual Chapter: Authentication Concepts
Manual Chapter
Table of Contents   |   Next Chapter >>

Authentication in Access Policy Manager

Access Policy Manager® provides several benefits when it comes to authenticating and authorizing users.

Benefit Description
Policy component Administrators can add various types of supported authentication methods as basic components to an access policy.
Flexibility Administrators can combine multiple authentication mechanisms in an arbitrary manner in a single access policy.
Performance Administrators should see high optimization (approximately 250 logins/sec.).
Extensible Administrators can configure an access policy to retrieve user credentials from multiple sources (for example, client certificate fields) as input to an authentication subsystem.
Customizable input Administrators can customize login page input and add the customized login page to an access policy.
Generic output Administrators can use the results from an authentication subsystem as input for various other functionality, for instance, resource assignments.

These illustrations depict the use of authentication as an access policy component. They also show 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.

How does authentication work? Create a AAA server object
How to create an access policy for authentication Create an access policy

Supported authentication methods

Access Policy Manager® uses the concept of access policies to authenticate and authorize users on the system. You can add authentication to an access policy using AAA servers (Authentication, Authorization, and Accounting) or client certificates. 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 the scheme at your site.
Authentication method Description
RADIUS Uses the server at your site that supports using the RADIUS protocol.
LDAP Uses the server at your site that supports authentication using LDAP.
Microsoft Active Directory 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 832017 under sections such as:
  • Kerberos Distribution Center
  • Group Policy
  • DNS Server
HTTP Uses external web-based authentication servers to validate user credentials, and to control user access to specific network resources. This method includes HTTP basic, HTTP NTLM, and HTTP form-based methods.
Note: For HTTP Auth, NTLMv2 is currently not supported.
RSA SecurID over RADIUS Uses the RADIUS protocol for authentication. To use this authentication method, you must select RADIUS as the authentication method.
RSA Native SecurID Uses the RSA Native SecurID protocol for authentication. You must have an authentication server set up and select SecurID as the authentication method.
Oracle Access Manager Uses the Oracle Access Manager (OAM) server for authentication and authorization to eliminate the need to deploy a WebGate proxy in front of each application.
CRLDP Distributes certificate revocation information across a network that identifies how the server obtains CRL information.
Online Certificate Status Protocol (OCSP) Retrieves the revocation status of the X.509 certificate to ensure the Access Policy Manager obtains real-time revocation status during the certificate verification process.
Terminal Access Controller Access Control System (TACAS+) Encrypts the entire body of the authentication packet. The system collects user credentials using the login screen agent in the access policy, and stores the collected credentials in the session.logon.last.username and session.logon.last.password session variables.
SAML Obtains assertions from an external SAML Identity Provider (IdP). Use this method when you configure a BIG-IP system as a SAML service provider.

How do I add authentication to an access policy?

You can add authentication to any access policy or any branch in an access policy. Typically, you add a Logon Page action and then add an authentication action, requiring users to authenticate using a client certificate or an AAA (Authentication, Authorization, and Accounting) server.

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

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.

How RADIUS works How RADIUS works
  • The client requests access to network resources through Access Policy Manager.
  • Access Policy Manager then issues a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access.
  • The RADIUS server then processes the request, and issues one of three responses to Access Policy Manager: Access Accept, Access Challenge, or Access Reject.

About AAA traffic and route domains

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 in direct option.

Configuring for RADIUS authentication and authorization

The Access Policy Manager ®is a NAS (Network Access Server), that operates as a client of the server configured here.
  1. On the Main tab, click Access Policy > AAA Servers. The AAA Servers list screen opens.
  2. From the AAA Servers by Type menu, choose the server type you want to create. A screen listing existing servers of that type opens.
  3. Click Create. The New Server properties screen opens.
  4. In the Name field, type a unique name for the authentication server.
  5. For the Mode setting, select the Authentication option.
  6. If you selected Use Pool, type a name for the AAA server pool.
  7. Provide the address required for your server connection:
    • If you selected Direct, type in a server address for the AAA server.
    • If you selected Use Pool, type in the IP addresses of the pool members and click Add. (When Use Pool is selected, you have the option to type the server address in route domain format: (IPAddress%RouteDomain).
  8. If you selected Use Pool, you have the option to select a Server Pool Monitor to track the health of the AAA server.
  9. In the Secret field, type the shared secret password of the server.
  10. In the Confirm Secret field, re-type the shared secret password of the server.
  11. 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 can also use 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.
  12. 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.
  13. 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 a 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. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. For Predefined Actions, under Authentication, select RADIUS Auth and click Add Item.
  5. On the properties popup, select the AAA RADIUS server you want to associate to the agent, and click Save.
  6. Click Apply Access Policy to save your configuration.
This adds the authentication server to the access policy, and completes the overall authentication process.

RADIUS attributes

The following table lists the specific RADIUS attributes that Access Policy Manager® sends with RADIUS requests.

Attribute Purpose
User-Name Indicates the name of the authenticated user.
User-Password Indicates the password of the authenticated user.
NAS-IP-Address Indicates the identifying IP Address of the NAS.
NAS-IPv6-Address Indicates the identifying IPv6 Address of the NAS.
NAS-Identifier Indicates the identifying name of the NAS .
Service-Type Indicates the type of service the user has requested.
NAS-Port Indicates the physical port number of the NAS that is authenticating the user.

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.

How does RADIUS accounting work?
  1. After RADIUS accounting runs successfully in an access policy, Access Policy Manager® 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. When the session is destroyed, 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 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.

Configuring RADIUS Accounting

  1. On the Main tab, click Access Policy > AAA Servers. The AAA Servers list screen opens.
  2. From the AAA Servers by Type menu, choose the server type you want to create. A screen listing existing servers of that type opens.
  3. Click Create. The New Server properties screen opens.
  4. In the Name field, type a unique name for the authentication server.
  5. For the Mode setting, select Accounting.
  6. If you selected Use Pool, type a name for the AAA server pool.
  7. Provide the address required for your server connection:
    • If you selected Direct, type in a server address for the AAA server.
    • If you selected Use Pool, type in the IP addresses of the pool members and click Add. (When Use Pool is selected, you have the option to type the server address in route domain format: (IPAddress%RouteDomain).
  8. If you selected Use Pool, you have the option to select a Server Pool Monitor to track the health of the AAA server.
  9. In the Accounting Service Port field, type the service port for your accounting server. The default is 1813.
  10. In the Secret field, type the shared secret password of the server.
  11. In the Confirm Secret field, re-type the shared secret password of the server.
  12. 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 can also use 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.
  13. 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.
  14. 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 a 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. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. Under Authentication, select RADIUS Acct and click Add item.
  5. On the properties popup, select the AAA RADIUS accounting server you want to associate to the agent, click Save.
  6. Click Apply Access Policy to save your configuration.
This adds the authentication server to the access policy, and completes the overall authentication process.

RADIUS accounting attributes

These tables list specific RADIUS accounting attributes that Access Policy Manager sends for RADIUS Accounting-Request start messages and RADIUS Accounting-Request stop messages.

RADIUS attributes for RADIUS Accounting start messages
Attribute Purpose
User-Name Indicates the name of the authenticated user.
Acct-Session-Id 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.
Acct-Status-Type Indicates whether the accounting-request marks the beginning of the user service (Start) or the end (Stop).
Acct-Authentic Indicates how the user was authenticated, whether by RADIUS, the NAS itself, or by another remote authentication protocol.
Service-Type Indicates the type of service the user has requested.
Nas-IP-Address 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.
NAS-IPv6-Address Indicates the identifying IPv6 Address of the NAS.
NAS-Identifier Indicates the identifying name of the NAS.
NAS-Port The physical port number of the NAS that is authenticating the user. It is always set to 0.
Tunnel-Client-Endpoint Contains the IP address of the initiator end of the tunnel.
Class Administrators can make resource assignments using this attribute.
RADIUS attributes for RADIUS Accounting stop messages
Attribute Purpose
Acct-Terminate-Cause Indicates how the session was terminated. Access Policy Manager supports three values for this attribute: User Request, Session Timeout, Admin Reset.
Acct-Session-Id 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.
Acct-Status-Type Indicates whether the accounting-request marks the beginning of the user service (Start) or the end (Stop).
Acct-Session-Time Indicates the number of seconds the user has received service for.
Service-Type Indicates the type of service the user has requested.
Framed-IP-Address Indicates the address configured for the user.
NAS-IPv6-Address Indicates the identifying IPv6 Address of the NAS.
NAS-Identifier Indicates the identifying name of the NAS .
Acct-Input-Octets Indicates the number of octets received from the port over the course of the service provided.
Acct-Output-Octets

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 sessions start and end information in its database, and sends them to the RADIUS accounting server.

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 Access Policy Manager, and might 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.

How LDAP works 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.

How LDAPS works How LDAPS works

About the 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 access policy item is authentication only. In this case, the Access Policy Manager® just verifies the user's credentials against an external server.
  • The query type access policy item causes the Access Policy Manager to query the external server for additional information about the user. The query type does not authenticate user credentials; to do so, add the auth type to your access policy.

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.

Attention: If you use 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. (If you use AD query, you can use the information in the Fetch Primary Group attribute.)

What are nested groups?

The nested group feature is used to identify groups to which the user belongs. Access Policy Manager® stores such groups in the memberOf session variable.

For example, if user1 is a member of group1 and group2, and group1 is a member of group3 and group4, then user1 belongs to all four of these groups. In addition, group3 and group4 privileges are nested by user1 through group1.

This is true, however, provided that the nested group feature is enabled on Access Policy Manager. The contents of the memberOf session variable differs depending on whether the nested group feature is enabled or disabled.

  • Enabled - The memberOf session variable contains all groups to which the user belongs. As in the example, this includes group1, group2, group3, and group4.
  • Disabled - The memberOf session variable contains groups to which the user belongs directly. Based on the example, this would be group1 and group2.
Note: The nested groups feature works slightly differently for LDAP than for Active Directory. For an Active Directory query, you can use nested groups in conjunction with, or independently from, the Fetch Primary Group option.

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

  1. Select Access Policy > AAA Servers > LDAP. The LDAP Servers screen displays.
  2. Click Create. The New Server properties screen opens.
  3. In the Name field, type a unique name for the authentication server.
  4. Select Use Pool even if you have only one pool member.
  5. Type a name for the AAA server pool.
  6. Populate the Server Addresses field by typing the IP address of a pool member and clicking Add. If you have more than one pool member, repeat this step.
  7. For the Mode setting, select LDAPS.
  8. In the Service Port field, type the port number of the server. The default is 389 for LDAP, and 636 for LDAPS.
  9. 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.
  10. In the Admin Password field, type the administrative password for the server.
  11. In the Verify Admin Password field, re-type the administrative password for the server.
  12. 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.
  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 can also use 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.
This adds the new LDAPS server to the AAA Server List.

Completing the authentication process for LDAP and LDAPS

Before you can 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. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. Under Authentication, select either LDAP Auth or LDAP Query and click Add item.
  5. Select the AAA LDAP server you want to associate to the agent, and click Save.
  6. For LDAP Quth and LDAP Query, specify the SearchDN, and SearchFilter settings. SearchDN is the base DN from which the search is done. Certain fields are relevant and specific to the agent that you select. For example, for LDAP Auth agent, UserDN is applicable, while for LDAP Query agent, Fetch Nested Group is available. For more information on the available fields for each agent, refer to the online help.
  7. Click Apply Access Policy to save your configuration.
This adds the authentication server to the access policy, and completes the overall authentication process.
Attention: If you use 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

Before starting this procedure, make sure that 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 verification 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 a server-side SSL profile. 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 636.
  5. Review the log messages in Access Policy Manager® reports.
  6. Make sure to set the Access Policy log level to Debug. To set log levels, see System > Logs > Configurations > Options > .
  7. Review the log for LDAP messages and locate and confirm that the bind and search operation succeeds.

About Active Directory authentication

You can authenticate using Active Directory authentication with Access Policy Manager. We 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. However, when using an access policy for Citrix Reciever client access, you must set max logon attempt to 1.

Configuring for Active Directory authentication and authorization

  1. On the Main tab, click Access Policy > AAA Servers. The AAA Servers list screen opens.
  2. From the AAA Servers by Type menu, choose the server type you want to create. A screen listing existing servers of that type opens.
  3. Click Create. The New Server properties screen opens.
  4. In the Name field, type a unique name for the authentication server.
  5. In the Domain Name field, type the name of the Windows Domain.
  6. For the Server Connection setting, select one of these options:
    • Select Use Pool to set up high availability for the AAA server.
    • Select Direct to set up the AAA server for standalone functionality.
  7. If you selected Direct, type a name in the Domain Controller field.
  8. If you selected Use Pool, configure the pool as follows.
    1. Type a name in the Domain Controller Pool Name field.
    2. Specify the Domain Controllers in the pool by typing the IP address and hostname for each one and clicking the Add button.
    3. To monitor the health of the AAA server, you have the option to select a health monitor. Only the gateway_icmp monitor is appropriate in this case; you can select it from the Server Pool Monitor list.
  9. In the Admin Name field, type an administrator name that has Active Directory administrative permissions. The administrator name is case-sensitive.
  10. In the Admin Password field, type the administrative password for the server.
  11. In the Verify Admin Password field, re-type the administrative password for the server.
  12. In the Timeout field, type a timeout interval (in seconds) for the AAA server. This setting is optional.
  13. Click Finished to add the new server to the configuration, and return to the main screen.
This adds the new Active Directory server 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.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. In the Authentication area, select AD Auth or AD Query, and click Add Item.
  5. If you are adding AD Query, you can set these options.
    Option Description
    SearchFilter Enter a search filter; otherwise if left empty, the policy uses the default filter, sAMAccountName=%{session.logon.last.username}.
    Fetch Primary Group Enable this setting to populate the user's primary group in the session variables. This setting is optional.
    Cross Domain Support Specifies whether AD cross domain authentication support is enabled for AD Auth agent. This setting is optional.
    Fetch Nested Groups Enable to populate the user's membership in the session variables. This setting is optional.
    Prompt user to change password before expiration Set (N days) to prompt user to change the password before it expires. The default is none (disabled). This setting is optional.
  6. If you are adding AD Auth, you can set these options.
    Option Description
    Cross Domain Support Specifies whether AD cross domain authentication support is enabled for AD Auth agent.
    Complexity check for Password Reset Specifies whether Access Policy Manager performs a password policy check.
    Note: Enabling this option increases overall authentication traffic significantly because Access Policy Manager must retrieve additional information. Because this option might require administrative privileges, if you enable it you should specify the administrator name and password on the AAA Active Directory server configuration page.
    Show Extended Error When enabled, displays the comprehensive error messages generated by the authentication server to show on the user's Logon page. This setting is intended for use in testing only in a production or debugging environment. If you enable this setting in a live environment, your system might be vulnerable to malicious attacks
    Max Logon Attempts Allowed Specifies the number of user authentication logon attempts to allow.
    Note: To use this access policy for Citrix Receiver client access, set the value to 1.
    Max Password Reset Attempts Allowed Specifies the number of times that Access Policy Manager allows the user to try to change password.
  7. Select the AAA Active Directory server to associate with the agent, and click Save.
  8. Click Apply Access Policy to save your configuration.
This adds the authentication server to the access policy, and completes the overall 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.

Active Directory's cross-domain support rules

Active Directory's cross-domain rules

Rules Explanation
Cross-domain support and split domain from username are both enabled. If you enable cross domain support, and enable split domain username at the login page, and then the user enters his user name, such as user@domain.com, Access Policy Manager® uses the user@domain.com as the user principal name to authenticate the user against USERNAME.COM domain.
Cross-domain support is enabled but split domain from username is disabled Access Policy Manager handles the user's input as a simple user name and escape "@" and "\" chars. In other words, Access Policy Manager uses user\@userdomain.com@DEFAULTREALM.COM to authenticate the user, where DEFAULTREALM.COM is the domain name that was configured on the AAA AD Server configuration page.
If user does not specify a user's domain Regardless of whether split domain from username option is enabled or disabled, Access Policy Manager uses user@defaultrealm.com to authenticate the user.

About using HTTP for authentication

HTTP authentication methods use external web-based servers to validate user credentials. Access Policy Manager®supports the following HTTP authentication methods:

  • HTTP basic authentication
  • HTTP NTLM authentication
  • HTTP form-based authentication
Tip: Use HTTPS instead of HTTP authentication for better security, because HTTP authentication passes user credentials as clear text. Note that to support HTTPS authentication, you must also set up and configure Access Policy Manager through a layered virtual server.

What are hidden parameters?

If you choose to use HTTP form-based authentication, you must provide hidden form parameters and values if there are any. When present, these values are required by the authentication server login form at your location.

Task summary for HTTP authentication

To set up this configuration, perform the procedures in the task list. You can choose to configure with HTTP Basic, HTTP NTLM, or HTTP form-based.

Task list

Configuring for HTTP Basic/NTLM authentication

  1. Select Access Policy > AAA Servers > HTTP. The HTTP Servers screen displays.
  2. Click Create. The New Server properties screen opens.
  3. In the Name field, type a unique name for the authentication server.
  4. For Authentication Type, select Basic/NTLM.
  5. 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.
  6. Click Finished to add the new server to the configuration, and return to the main screen.

Configuring for HTTP form-based authentication

You create a form-based HTTP AAA configuration to use HTTP form-based authentication from an access policy.
  1. Select Access Policy > AAA Servers > HTTP. The HTTP Servers screen displays.
  2. Click Create. The New Profile screen opens.
  3. In the Name field, type a unique name for the authentication server.
  4. For Authentication Type, select Form Based.
  5. In the Start URI field, type in a URL resource, for example, http://plum.tree.lab2.sp.companynet.com/. This resource must respond with a challenge to a non-authenticated request. While this field is mandatory for the Basic/NTLM setting, it is optional for Form Based. Using the Start URI field differs slightly for each authentication type. For example, if you select Form Based, typing a URL resource is optional, since the form action field specifies either an absolute URL or relative URL resource. However, if you select Form Based and choose to specify both the Start URI and Form Action, then Access Policy Manager® uses both start URI and form action parameters as the final URL for HTTP POST. If you do not specify a start URI, Access Policy Manager is likely to detect that the absolute URI based on the form action parameter should be used for HTTP POST.
  6. From the Form Method list, select either GET or POST. If you specify GET , the authentication request converts as HTTP GET.
  7. 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 required. If you do not specify a form action, then Access Policy Manager uses the URI from the request to perform HTTP form-based authentication.
  8. In the Form Parameter For User Name and Form Parameter For Password fields, type the parameter name and password used by the form to which you are sending the POST request.
  9. In the Hidden Form Parameters/Values field, type the hidden form parameters required by the authentication server logon form at your location.
  10. In the Number Of Redirects To Follow field, type how far from the landing page, in pages, the request should travel before failing.
  11. For the Successful Logon Detection Match Type setting, select the method your authenticating server uses, and specify the option definition.
  12. 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 can 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. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. Under Authentication, select HTTP Auth and click Add item. If you are working with HTTPS, select HTTPS Auth. The serverssl profile for the virtual server should be set if you select HTTPS.
  5. On the properties popup, select the AAA HTTP server you want to associate to the agent and click Save.
  6. Click Apply Access Policy to save your configuration.
This adds the authentication server to the access policy, and completes the overall authentication process.

Task summary for configuring HTTPS authentication

To set up this configuration, perform the procedures in the task list.

Task list

Configuring for HTTPS authentication

You create an AAA HTTPS configuration to authenticate users using HTTPS.
  1. Configure a layered Local Traffic Manager® virtual server that converts HTTP to HTTPS.
  2. Patch the DNS to send HTTP Auth traffic to the external HTTP server through the layered virtual server. The start URLs will remain the same; for example, http://plumtree.lab2.sp.companynet.com.
  3. Use the IP address of the layered virtual server in the start URL, that is, http://IP address of layered virtual server.
  4. Select Access Policy > AAA Servers > HTTP. The HTTP Servers screen displays.
  5. From the AAA Servers by Type menu, choose the server type you want to create. A screen listing existing servers of that type opens.
  6. In the Name field, type a unique name for the authentication server.
  7. For Authentication Type, select Basic/NTLM.
  8. In the Start URI field, type the IP address of the layered virtual server that you created in step 1. Use this format: http:IP address.
  9. 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. 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 can 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. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. Under Authentication, select HTTP Auth and click Add item. If you are working with HTTPS, select HTTPS Auth. The serverssl profile for the virtual server should be set if you select HTTPS.
  5. On the properties popup, select the AAA HTTP server you want to associate to the agent and click Save.
  6. Click Apply Access Policy to save your configuration.
This adds the authentication server to the access policy, and completes the overall authentication process.

About RSA SecurID authentication

RSA SecurID is a two-factor authentication mechanism based on a user PIN or password and code that an authenticator generates and provides to the user.

A token is an authentication code generated every 60 seconds by an authenticator (hardware or software) assigned to the user.

How RSA SecurID works How Access Policy Manager works with RSA SecurID
  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. Based on the authentication results, Access Policy Manager grants or denies access to the client.

About RSA SecurID configuration requirements for APM AAA

Before you can use a SecurID AAA server in Access Policy Manager, you need to meet specific requirements for configuration elements and settings on RSA SecurID, as described here.

Authentication agent

To provide RSA SecurID authentication for APM, the RSA Authentication Manager requires an authentication agent for APM in its database.

To create an authentication agent from the RSA Security Console, you need:

  • Hostname
  • IP addresses for all network interfaces
  • Agent Type (set to Standard Agent)

RADIUS client

To provide RSA SecurID authentication for APM, RSA Authentication Manager requires a RADIUS client that corresponds to the authentication agent for APM.

To create a RADIUS client from the RSA Security Console, you need:

  • Hostname
  • IP addresses for all network interface
  • RADIUS secret (this RADIUS secret must match the corresponding RADIUS secret on the APM system).

Character requirements setting in a SecurID token policy

To avoid a problem in the RSA SDK with alphabetic-only PIN policies, do not use them. When you set up a SecurID token policy, set the character requirements to one of these values:

  • Require numeric PINs
  • Allow alpha-numeric PINs

Task summary for RSA SecurID authentication

Task list

Configuring a SecurID AAA server in APM

Configure a SecurID AAA server for Access Policy Manager® to request RSA SecurID authentication from an RSA Manager authentication server.
  1. On the Main tab, click Access Policy > AAA Servers. The AAA Servers list screen opens.
  2. On the menu bar, click AAA Servers By Type, and select SecurID. The SecurID screen opens and displays the servers list.
  3. Click Create. The New Server properties screen opens.
  4. In the Name field, type a unique name for the authentication server.
  5. In the Configuration area, for the Agent Host IP Address (must match the IP address in SecurID Configuration File) setting, select an option as appropriate:
    • Select from Self IP List: Choose this when there is no NAT device between APM and the RSA Authentication Manager. Select an IP from the list of those configured in Access Policy Manager.
    • Other: Choose this when there is a NAT device in the network path between Access Policy Manager and the RSA Authentication Manager server. If selected, type the address as translated by the NAT device.
  6. For the SecurID Configuration File setting, browse to upload the sdconf.rec file. Consult your RSA Authentication Manager administrator to generate this file for you. If the generated file has any other name than sdconf.rec, you must rename it before uploading.
  7. Click Finished to add the new server to the configuration, and return to the main screen.
This adds a new RSA SecurID server to the AAA Servers list.

Adding RSA SecurID authentication to an access policy

Before you add RSA SecurID authentication to an access policy, you must have at least one AAA SecurID server configured in Access Policy Manager®.
You add RSA SecurID authentication to an access policy so that APM can request RSA SecurID authentication using the AAA SecurID server that you specify.
  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. Under Authentication, select RSA SecurID and click Add Item. A properties popup screen opens.
  5. From the AAA Server list in the properties popup screen, select the SecurID AAA server that you want to associate to the agent.
  6. Set Max Logon Attempts to a value from from 1 to 5.
    Note: To use this access policy for Citrix Receiver client access, you must set Max Logon Attempts to 1.
  7. Click Save.
  8. Click Apply Access Policy to save your configuration.
This adds RSA SecurID AAA authentication server to the access policy.

About TACACS+ authentication and accounting

Access Policy Manager® supports authenticating and authorizing the client against Terminal Access 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.

Task list

Configuring for TACACS+ authentication and authorization

  1. On the Main tab, click Access Policy > AAA Servers. The AAA Servers list screen opens.
  2. From the AAA Servers by Type menu, choose the server type you want to create. A screen listing existing servers of that type opens.
  3. Click Create. The New Server properties screen opens.
  4. In the Name field, type a unique name for the authentication server.
  5. For the Server Connection setting, select one of these options:
    • Select Use Pool to set up high availability for the AAA server.
    • Select Direct to set up the AAA server for standalone functionality.
  6. If you selected Use Pool, type a name for the AAA server pool.
  7. Provide the address required for your server connection:
    • If you selected Direct, type in a server address for the AAA server.
    • If you selected Use Pool, type in the IP addresses of the pool members and click Add. (When Use Pool is selected, you have the option to type the server address in route domain format: (IPAddress%RouteDomain).
  8. If you selected Use Pool, you have the option to select a Server Pool Monitor to track the health of the AAA server.
  9. Type in a TACACS+ service port or select one from the list. The default is 49.
  10. 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.
  11. 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 select from the following options: login, ARAP, Connection, Firewall, Last, PPP, Shell, SLIP, System, TTY-Daemon For information on all the other settings, which are optional, please refer to the online help.
  12. 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.
  4. In the Language Settings area, add and remove accepted languages, and set the default language. A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
  5. Click Finished.
  6. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  7. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  8. Select TACACS+ Auth, and click Add item.
  9. Optionally, select TACACS_Acct if you want to add it as part of your access policy.
  10. Click Apply Access Policy to save your configuration.
This adds the authentication server 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 users with TACACS+ authentication. Note that the server used for authentication can be different from the server used for TACACS+ accounting service.

How TACACS+ worksHow TACACS Plus works

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 responder configuration for every OCSP responder that exists.

Task summary for OCSP authentication

To set up this configuration, perform the procedures in the task list.

Task list

Configuring for OCSP authentication and authorization

  1. On the Main tab, click Access Policy > AAA Servers. The AAA Servers list screen opens.
  2. From the AAA Servers by Type menu, choose the server type you want to create. A screen listing existing servers of that type opens.
  3. In the Name field, type a unique name for the authentication server.
  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 a clientssl profile for OCSP

You need a clientssl profile to use OCSP authentication from an access policy.
  1. On the Main tab, click Local Traffic > Profiles > SSL > Client. The Client profile list screen opens.
  2. Click Create. The New Client SSL Profile screen opens.
  3. In the Name field, type a unique name for the profile.
  4. From the Parent Profile list, select a profile from which the new profile inherits properties.
  5. Select the Custom check box for Client Authentication. The settings become available.
  6. From the Certificate list, select the option that is applicable to the agent you selected when you edited the access policy.
    • Select request if the Client Cert Inspection agent is used in the access policy.
    • Select ignore if the On-Demand Cert Auth agent is used.
  7. From the Trusted Certificate Authorities list, select the Certificate Authority that issues the user certificates.
  8. From the Advertised Certificate Authorities list, select the advertised Certificate Authority file for client certificate authentication.
  9. 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.
  4. In the Language Settings area, add and remove accepted languages, and set the default language. A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
  5. Click Finished.
  6. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  7. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  8. Under Authentication, select either Client Cert Inspection or On-Demand Cert Auth, and click Add item.
  9. Select OSCP Auth, and click Add item.
  10. Click Apply Access Policy to save your configuration.
This adds the authentication server to the access policy.
After adding the OCSP Auth agent to the access policy, update the agent to include a proper OCSP responder.

Policy example for OCSP authentication

This is an example of an access policy with all the associated elements needed to authenticate and authorize users with OCSP authentication. Notice that you must add either the Client Cert Inspection agent or the On-Demand Cert Auth agent before the OCSP Auth object in your access policy. One of those agents is required in order to receive the X.509 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.

How OCSP works How OCSP works

About CRLDP configuration

Access Policy Manager® supports retrieving Certificate Revocation Lists (CRLs) from network locations (distribution points). Certificate Revocation List Distribution Point (CRLDP) AAA defines how to access a CRL file from a distribution point. A distribution point is either an LDAP Uniform Resource Identifier (URI) or a directory path that identifies the location where the CRLs are published.

Task summary for CRLDP configuration

To set up this configuration, perform the procedures in the task list.

Task list

Configuring an AAA server for CRLDP

Create a CRLDP AAA configuration to specify how to access CRLs.
  1. On the Main tab, click Access Policy > AAA Servers/CRLDP. The CRLDP Servers list screen opens.
  2. Click Create. The New Server properties screen opens.
  3. In the Name field, type a unique name for the authentication server.
  4. For the Server Connection setting, select one of these 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. If you selected Use Pool, type a name for the AAA server pool.
  6. Provide the address required for your server connection:
    • If you selected Direct, type in a server address for the AAA server.
    • If you selected Use Pool, type in the IP addresses of the pool members and click Add. (When Use Pool is selected, you have the option to type the server address in route domain format: (IPAddress%RouteDomain).
  7. If you selected Use Pool, you have the option to select a Server Pool Monitor to track the health of the AAA server.
  8. In the Service Port field, type a CRLDP service port or choose one from the list. The default is 389 .
  9. For Base DN, type a CRLDP base distinguished name. This setting applies for certificates that specify the CRL distribution point in directory name (dirName) format. Acess Policy Manager uses the Base DN when the value of the X509v3 attribute, crlDistributionPoints, is of type dirName. In this case, Access Policy Manager tries 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.
    Note: If the client certificate includes the distribution point extension in LDAP URI format, the IP address, Base DN and Reverse DN settings configured on the agent are ignored; they are specific to directory-based CRLDP. All other settings are applicable to both LDAP URI and directory-based CRL DPs.
  10. Click Finished to add the new server to the configuration, and return to the main screen.
An CRLDP AAA server is available for use in a CRLDP Auth agent in an access policy.

Configuring a clientssl profile for CRLDP

  1. On the Main tab, click Local Traffic > Profiles > SSL > Client. The Client profile list screen opens.
  2. Click Create. The New Client SSL Profile screen opens.
  3. In the Name field, type a unique name for the profile.
  4. From the Parent Profile list, select a profile from which the new profile inherits properties.
  5. Select the Custom check box for Configuration. The settings become available.
  6. From the Certificate list, select the option that is applicable to the agent you selected when you edited the access policy.
    • Select request if the Client Cert Inspection agent is used in the access policy.
    • Select ignore if the On-Demand Cert Auth agent is used.
  7. From the Trusted Certificate Authorities list, select the Certificate Authority that issues the user certificates.
  8. Optional: From the Advertised Certificate Authorities list, select the Certificate Authority that issues the user certificates.
  9. Click Finished.
A new clientSSL profile is available.

Creating an access profile with default settings

You create an access profile to provide the access policy configuration for a virtual server that establishes a secured session.
  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.
  4. In the Language Settings area, add and remove accepted languages, and set the default language. A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
  5. Click Finished.
The access profile now shows up in the Access Profiles List.

Configuring an access policy that uses the CRLDP agent

  1. On the Main tab, click Access Policy > Access Profiles. The Access Profiles List screen opens.
  2. In the Access Policy column, click the Edit link for the access profile you want to configure to launch the visual policy editor. The visual policy editor opens the access policy in a separate screen.
  3. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. From Authentication, select either Client Cert Inspection or On-Demand Cert Auth and click Add item. A properties screen displays.
  5. Click Save. The properties screen closes.
  6. Click the (+) sign anywhere in the access policy to add a new action item. An Add Item screen opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  7. From Authentication, select CRLDP Auth, click Add item and configure the CRLDP server setting in the properties screen.
  8. Click Save. The properties screen closes.
  9. Configure the appropriate endings on the branches.
  10. Click Apply Access Policy to save your configuration.
The access policy is complete.
To put the access policy into effect, attach the access profile to a virtual server.

Access policy example for CRLDP agent

This is an example of an access policy with all the associated elements needed to retrieve CRLs using CRLDP. Notice that you must add either the Client Cert Inspection agent or On-Demand Cert Auth agent before the CRLDP object in your access policy. One of those agents is required in order to receive the X.509 certificate from the user. This is also important because 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.

How CRLDP works How CRLDP works
Table of Contents   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)