| My Support

Applies To:

Show Versions Show Versions
Manual Chapter: Authentication Methods
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

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 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.

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.

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.

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 server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile in a separate window or tab.
  3. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window 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 executes 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 server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile in a separate window or tab.
  3. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window 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 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.

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.

Configuring for LDAP authentication and authorization

  1. On the Main tab, click Access Policy > AAA Servers . The AAA server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  5. For Server Connection, 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. If you selected Use Pool, for the Mode setting, select LDAP.
  10. In the Service Port field, type the port number of the server. The default is 389 for LDAP, and 636 for LDAPS.
  11. 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.
  12. In the Admin Password field, type the administrative password for the server.
  13. In the Verify Admin Password field, re-type the administrative password for the 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 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.
  15. Click Finished to add the new server to the configuration, and return to the main screen.
This adds a new LDAP 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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile in a separate window or tab.
  3. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window 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.

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. On the Main tab, click Access Policy > AAA Servers . The AAA server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  5. Select Use Pool even if you have only one pool member.
  6. Type a name for the AAA server pool.
  7. Type the IP addresses of pool members and click Add.
  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.
  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 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.
  15. 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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile in a separate window or tab.
  3. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window 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.

Configuring for Active Directory authentication and authorization

  1. On the Main tab, click Access Policy > AAA Servers . The AAA server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  5. In the Domain Name field, type the name of the Windows Domain.
  6. For Server Connection, 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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile in a separate window or tab.
  3. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. Under Authentication, 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. Select the AAA Active Directory server you want to associate with the agent, and click Save.
  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 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. On the Main tab, click Access Policy > AAA Servers . The AAA server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  5. For Authentication Type, select Basic/NTLM.
  6. In the Start URI field, type the complete URI that returns the login form. The URI resource must respond with a challenge to a non-authenticated request.
  7. Click Finished to add the new server to the configuration, and return to the main screen.

Configuring for HTTP form-based authentication method

  1. On the Main tab, click Access Policy > AAA Servers . The AAA server list screen opens.
  2. Click Create. The New Profile screen opens.
  3. Type a name for the authentication server you are creating.
  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 login 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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile in a separate window or tab.
  3. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window 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

  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 startURLs will remain the same; for example, http://plumtree.lab2.sp.companynet.com.
  3. Use the IP address of the layered virtual server in the startURL, that is, http://IP address of layered virtual server
  4. On the Main tab, click Access Policy > AAA Servers . The AAA server list screen opens.
  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. Click Create. A New Server General Properties screen opens for that type of server.
  7. Type a name for the authentication server you are creating.
  8. For Authentication Type, select Basic/NTLM.
  9. 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.
  10. 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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile in a separate window or tab.
  3. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window 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 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 or password and code generated by an authenticator that is provided to the user.

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

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.
How RSA SecurID works 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 RSA Native SecurID authentication

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

Task list

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 Add Agent Host.
  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 boxes Enable Offline Authentication, Enable Windows Password Integration, and Create Verifiable Authentication.
  11. Click OK.
  12. Click the Agent Host tab, and select the Generate Configuration Files item. The Generate Configuration File screen opens.
  13. Select One Agent Host , 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. You also 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 sub-nodes will be accepted.
  14. 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.
This adds the Access Policy Manager as an agent host to the RSA Native SecurID server. As a result, the agent host record can 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 . The AAA server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  5. 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 option, and select from the list of those configured on the Access Policy Manager. The source IP address of the packets does not change, but 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.
  6. 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.
  7. Click Finished to add the new server to the configuration, and return to the main screen.
This adds your new RSA Native SecurID server 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. In the Access Policy column, click the Edit link for the profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile in a separate window or tab.
  3. Click the [+] sign anywhere in your access profile to add your new policy action item. An Add Item window opens, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  4. Under Authentication, select RSA SecurID and click Add Item.
  5. On the properties popup, select the RSA Native SecurID 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 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 CRLDP authentication and authorization

  1. On the Main tab, click Access Policy > AAA Servers . The AAA server 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. 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 Client profile list screen opens.
  2. In the Name field, type a name for the profile.
  3. From the Parent Profile list, select a profile from which the new profile inherits properties.
  4. From the Client 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.
  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.
  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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile 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, 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 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 can 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

  1. On the Main tab, click Access Policy > AAA Servers . The AAA server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  5. For Server Connection, 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 CRLDP service port or choose one from the list. The default is 389 .
  10. 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 . All other settings are optional; for information on them, please refer to the online help.

Configuring clientssl profile for CRLDP

  1. On the Main tab, click Local Traffic > Profiles > SSL > Client . The Client profile list screen opens.
  2. On the Main tab, click Local Traffic > Profiles > SSL > Client . The Client profile list screen opens.
  3. In the Name field, type a name for the profile.
  4. From the Parent Profile list, select a profile from which the new profile inherits properties.
  5. From the Client 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.
  6. From the Trusted Certificate Authorities list, select a certificate authority.
  7. From the Advertised Certificate Authorities list, select the advertised Certificate Authority file for client certificate authentication.
  8. Click Finished.
Completing the authentication 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.
  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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile 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, listing Predefined Actions that are grouped by General Purpose, Authentication, and so on.
  8. Select either Client Cert Inspection or On-Demand Cert Auth and click Add item.
  9. Select CRLDP Auth,click Add item, and configure the CRLDP server setting in the agent.
  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 Inspection agent 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 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 CRDLP Auth agent to check the revocation status of the user's certificate.

How CRLDP works How CRLDP works

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 server 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. A New Server General Properties screen opens for that type of server.
  4. Type a name for the authentication server you are creating.
  5. For Server Connection, 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 profile you want to configure to launch the visual policy editor. The visual policy editor opens the access profile 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, 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
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.

Additional Comments (optional)

About F5

Education

F5 Sites

Support Tasks

Connect with us

© Copyright 2018 by F5 Networks, Inc. | Policies | Privacy | Trademarks