Applies To:

Show Versions Show Versions

Manual Chapter: Configuration Guide for BIG-IP Local Traffic Management: 10 - Authenticating Application Traffic
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


10

Authenticating Application Traffic


Introducing remote authentication

A significant feature of the BIG-IP® local traffic management system is its ability to support Pluggable Authentication Module (PAM) technology. PAM technology allows you to choose from a number of different authentication and authorization schemes to use to authenticate or authorize network traffic.

The goal of PAM technology is to separate an application, such as the BIG-IP system, from its underlying authentication technology. This means that you can dictate the particular authentication/authorization technology that you want the BIG-IP system to use to authenticate application traffic coming into the BIG-IP system.

To this end, the BIG-IP system offers several authentication schemes, known as authentication modules. These authentication modules allow you to use a remote system to authenticate or authorize application requests that pass through the BIG-IP system.

To implement an authentication module, you use the Configuration utility to access the profile screens within the Local Traffic section of the utility. Using these screens, you can configure settings for the type of authentication module you want to implement.

Note

The BIG-IP system normally routes remote authentication traffic through a Traffic Management Microkernel (TMM) switch interface (that is, an interface associated with a VLAN and a self IP address), rather than through the management interface. Therefore, if the TMM service has been stopped for any reason, remote authentication is not available until the service is running again. For more information on routing traffic through BIG-IP interfaces, see the BIG-IP® Network and System Management Guide.

BIG-IP system authentication modules

The BIG-IP system modules that you can implement for remote authentication are:

  • Lightweight Directory Access Protocol (LDAP)
    The BIG-IP system can authenticate or authorize network traffic using data stored on a remote LDAP server or a Microsoft® Windows® Active Directory® server. Client credentials are based on basic HTTP authentication (user name and password).
  • Remote Authentication Dial-In User Service (RADIUS)
    The BIG-IP system can authenticate network traffic using data stored on a remote RADIUS server. Client credentials are based on basic HTTP authentication (user name and password).
  • TACACS+
    The BIG-IP system can authenticate network traffic using data stored on a remote TACACS+ server. Client credentials are based on basic HTTP authentication (user name and password).
  • SSL client certificate LDAP
    The BIG-IP system can authorize network traffic using data stored on a remote LDAP server. Client credentials are based on SSL certificates, as well as defined user groups and roles.
  • Online Certificate Status Protocol (OCSP)
    The BIG-IP system can check on the revocation status of a client certificate using data stored on a remote OCSP server. Client credentials are based on SSL certificates.

Implementing authentication modules

Using the BIG-IP system, you can implement any of the available authentication modules listed in the previous section. Implementing an authentication module requires you to create or configure the following objects:

  • A RADIUS server or SSL OCSP responder object
    This is required for RADIUS and SSL OCSP authentication modules only. Server objects and responder objects consist of settings pertaining to remote RADIUS servers or OCSP responders.
  • A configuration object
    It is the configuration object that controls the authentication module, through a group of configurable settings. Examples of configuration object settings are Hosts, Service Port, and Search Time Limit.
  • An authentication profile
    An authentication profile is an object that specifies the type of authentication module you want to implement, a parent profile, and the configuration object. You can either use the default profile that the BIG-IP system provides for each type of authentication module, or create a custom profile. For background information on profiles, see Chapter 5, Understanding Profiles .
  • An authentication iRule
    For any type of PAM module that you want to implement, the BIG-IP system provides a corresponding default authentication iRule that you must associate with your profile and your virtual server. An authentication iRule is a TCL-based script that performs the authentication/authorization action, according to the settings of the corresponding profile and configuration objects.
  • In most cases, you can use the default iRule, rather than creating a custom one. Creating custom iRulesTM is necessary when you want to implement multiple authentication modules of the same type, such as multiple LDAP authentication modules, each with different configuration object and profile settings. For information on creating custom iRules, see Chapter 15, Writing iRules .

The process you use to implement an authentication module is a simple one. For example, to implement an LDAP authentication module, which uses a remote LDAP server to authentication client traffic using user name and password credentials, you perform the following tasks. Note that this example creates a custom profile and uses the default iRule that the BIG-IP system provides.

To implement an authentication module

  1. Create an authentication configuration object named my_ldap_config. For information on creating an LDAP authentication configuration object, see Creating an LDAP configuration object .
  2. Create a custom authentication profile named my_ldap_profile, in which you specify the authentication module type as LDAP, specify a parent profile (either the default ldap profile or another custom profile that you created), and reference the configuration object my_ldap_config. For information on creating an LDAP profile, see Creating an LDAP profile .
  3. Configure the virtual server to reference both the custom profile my_ldap_profile and the default authentication iRule auth_ldap. For information on how to configure virtual server settings, see Chapter 2, Configuring Virtual Servers .

Implementing an LDAP authentication module

An LDAP authentication module is a mechanism for authenticating or authorizing client connections passing through a BIG-IP system. This module is useful when your authentication or authorization data is stored on a remote LDAP server or a Microsoft Windows Active Directory server, and you want the client credentials to be based on basic HTTP authentication (that is, user name and password).

With the LDAP authentication module, the BIG-IP system can indicate that the authentication was a success or failure, or that the LDAP server needs a credential of some sort.

Additionally, the system can take some action based on certain information that the server returns in the LDAP query response. For example, LDAP response information can indicate the user's group membership, or it can indicate that the user's password has expired. To configure the BIG-IP system to return specific data in an LDAP response, you can write an iRule, using the commands AUTH::subscribe, AUTH::unsubscribe, and AUTH::result-data. For more information, see Chapter 15, Writing iRules , and the F5 Networks DevCentral web site, http://devcentral.f5.com.

To implement an LDAP authentication module, you must configure the BIG-IP system to access data on a remote LDAP server. To do this, you must create:

  • An LDAP configuration object
  • An LDAP profile

After you create these objects, you must then assign the LDAP profile to a virtual server.

Creating an LDAP configuration object

When you create an LDAP configuration object, you configure a variety of settings. Table 10.1 shows the settings and values that you configure for an LDAP configuration object. Note that this table groups the settings into the same categories that you see on the New Authentication Configuration screen. For the detailed procedure on how to create this object, see To create an LDAP configuration object .

 

Table 10.1 Settings of an LDAP configuration object
Setting
Description
Default Value
General Properties
Name
Specifies a unique name for the configuration object. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to LDAP.
No default value
Configuration
Remote LDAP Tree
Specifies the search base distinguished name.
No default value
Hosts
Lists the addresses of the LDAP servers that the BIG-IP system uses to obtain authentication data.
No default value
Service Port
Specifies the port number for the LDAP service.
389 (non-SSL)
636 (SSL-enabled)
LDAP Version
Specifies the version number of the LDAP application.
3
Bind DN
Specifies the distinguished name of an account to which to bind, in order to perform searches. This search account is a read-only account used to do searches. The admin account can be used as the search account. If no admin DN is specified, then no bind is attempted. This setting is only required when a site does not allow anonymous searches.
If the remote server is a Microsoft Windows Active Directory server, the distinguished name must be in the form of an email address.
No default value
Bind Password
Specifies the password for the search account created on the LDAP server. This setting is required if you use a bind DN.
No default value
Confirm Bind Password
Confirms the password for the bind distinguished name. This setting is optional.
No default value
Search Time Limit
Specifies a time limit for a search.
30
Bind Time Limit
Specifies a Bind time limit.
30
Filter
Specifies a filter. This setting is used for authorizing client traffic.
No default value
Login Attribute
Specifies a login attribute. Normally, the value for this setting is uid; however, if the server is a Microsoft Windows Active Directory server, the value must be the account name sAMAccountName (case-insensitive).
No default value
Group DN
Specifies the group distinguished name. This setting is used for authorizing client traffic.
No default value
Group Member Attribute
Specifies an group member attribute. This setting is used for authorizing client traffic.
No default value
SSL
Allowed values are: Enabled, Disabled, and Start TLS. Note that when enabled, the BIG-IP system changes the service port number from 389 to 636.
Disabled
Check SSL Peer
When enabled, checks an SSL peer.
Disabled
SSL CA Certificate
Specifies the name of an SSL CA certificate. Allowed values are: None, Default, and Specify Full Path.
None
SSL Client Key
Specifies the name of an SSL client key. Allowed values are: None, Default, and Specify Full Path.
None
SSL Client Certificate
Specifies the name of an SSL client certificate. Allowed values are: None, Default, and Specify Full Path.
None
SSL Ciphers
Specifies SSL ciphers.
No default value
Ignore Unknown User
When enabled, causes the BIG-IP system to ignore unknown users.
Disabled
Warning Logging
Enables or disables warning messages.
Enabled
Debug Logging
Enables or disables SYSLOG debugging information at LOG_DEBUG level. Not recommended for normal use.
Disabled

 

To create an LDAP configuration object

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Configurations.
  3. In the upper right corner of the screen, click Create.
    This displays the New Configuration screen.
  4. For the Name setting, type a unique name for the configuration object, such as my_ldap_config.
  5. For the Type setting, select LDAP.
    The screen expands to show several settings.
  6. Modify or retain values for all settings shown.
    (To configure advanced settings, locate the Configuration heading and select Advanced.)
  7. Click Finished.

Creating an LDAP profile

Once you have created an LDAP configuration object, you must create or configure an LDAP profile. You do this by modifying the default ldap profile or by creating a custom profile that inherits the default profile settings. An important function of the authentication profile is to reference an existing configuration object that you have created.

In most cases, the default profile should suit your needs. However, even if you use the default profile, you must still modify it to specify the corresponding configuration object that you created.

If you choose to create a custom profile, you must specify a parent profile (either a custom profile or the default profile) that contains the values that you want the new profile to inherit.

When you create an LDAP profile, you configure some settings. Table 10.2 shows the settings and values that make up an LDAP profile. For the detailed procedure on creating an LDAP profile, see To modify the default LDAP profile , following, or To create a custom LDAP profile .

Table 10.2 Settings of an LDAP profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to LDAP.
No default value
Parent Profile
Specifies the profile from which you want to inherit values.
ldap
Mode
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Enabled
Configuration
Specifies an existing LDAP configuration object. This setting is required.
No default value
Rule
Specifies the name of an existing authentication iRule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
auth_ldap
Idle Timeout
Specifies the duration in seconds that an authentication or authorization request is idle before timing out. You can use the default value, specify a different value, or select Indefinite.
300

 

To modify the default LDAP profile

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
    This displays the list of default authentication profiles.
  3. In the Name column, click ldap.
  4. For the Mode setting, select Enabled or Auto.
  5. For the Configuration setting, select a configuration object from the list. Note that None is not an allowed value.
  6. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_ldap, leave the setting as is.
    • If you do not want to use the default iRule auth_ldap, select the name of an existing iRule that you have created.
  7. Click Finished.

To create a custom LDAP profile

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
  3. In the upper right corner of the screen, click Create.
    This displays the New Profile screen.
  4. For the Name setting, type a unique name for the profile, such as my_ldap_profile.
  5. For the Type setting, select LDAP.
    The screen expands to show additional settings.
  6. For the Parent Profile setting:
    • If you want to use the default profile ldap for the parent profile, leave the setting as is.
    • If you want to use a custom profile for the parent profile, select a custom profile name from the list.
  7. For the Mode setting, select Enabled or Auto.
  8. For the Configuration setting, select a configuration object from the list.
  9. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_ldap, leave the setting as is.
    • If you do not want to use the default iRule auth_ldap, select the name of an existing iRule that you have created.
  10. Click Finished.

After you have created an LDAP configuration object and an LDAP profile, you must assign the profile to the virtual server by configuring the virtual server's Authentication Profile setting. For information on how to configure virtual server settings, see Chapter 2, Configuring Virtual Servers .

Implementing a RADIUS authentication module

A RADIUS authentication module is a mechanism for authenticating client connections passing through a BIG-IP system. You use this module when your authentication data is stored on a remote RADIUS server. In this case, client credentials are based on basic HTTP authentication (that is, user name and password).

To implement a RADIUS authentication module, you must configure the BIG-IP system to access data on a remote RADIUS server. To do this, you must create:

  • One or more high-level RADIUS server objects
  • A RADIUS configuration object
  • A RADIUS profile

After you create these objects, you must then assign the RADIUS profile to a virtual server.

Creating a RADIUS server object

When you create a RADIUS server object, you configure some settings. Table 10.3 shows the settings and values that make up a default RADIUS server object. For the detailed procedure on creating a server object, see To create a RADIUS server object , following.

Table 10.3 Settings of a RADIUS sever definition
Setting
Description
Default Value
Name
Specifies a unique name for the RADIUS server object, such as my_radius_object. This setting is required.
No default value
Host
Specifies a host name or IP address for the RADIUS server. This setting is required.
No default value
Service Port
Specifies the port for RADIUS authentication traffic.
1812
Secret
Sets the secret key used to encrypt and decrypt packets sent or received from the server. This setting is required.
No default value
Confirm Secret
Confirms the secret key supplied for the Secret setting. This setting is required.
No default value
Timeout
Specifies a timeout value.
3

 

To create a RADIUS server object

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose RADIUS Servers.
    This displays the RADIUS Server List screen.
  3. In the upper right corner of the screen, click Create.
  4. For the Name setting, type a unique name for the RADIUS server object, such as my_radius_server.
  5. For the Host setting, type a host name or IP address for the remote RADIUS server.
  6. For the Secret and Confirm Secret settings, type the RADIUS secret.
  7. Retain or modify all other settings.
  8. Click Finished.
  9. For redundant RADIUS servers, repeat these steps to create additional server objects.

Creating a RADIUS configuration object

When you create a RADIUS configuration object, you configure a variety of settings. Table 10.4 shows the settings and values that make up a RADIUS configuration object. Note that this table groups the settings into the same categories that you see on the New Authentication Configuration screen. For the detailed procedure on how to create this configuration object, see To create a RADIUS configuration object .

Table 10.4 Settings of a RADIUS configuration object
Setting
Description
Default Value
Name
Specifies a unique name for the configuration object. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to RADIUS.
No default value
RADIUS Servers
Lists the IP addresses of the RADUIS servers that the BIG-IP system will use to obtain authentication data.
Note that for each server listed, you must create a corresponding RADIUS server definition. A RADIUS server definition specifies the server name, port number, RADIUS secret, and timeout value. For more information, see Table 10.3 .
No default value
Client ID
Sends a NAS-Identifier RADIUS attribute with string bar. If you do not specify a value for the Client ID setting, the PAM service type is used instead. This feature can be disabled by specifying a blank client ID.
No default value
Debug Logging
Enables SYSLOG debugging information at LOG_DEBUG level. We do not recommend this for normal use.
Disable
Accounting Bug
Disables validation of the accounting response vector. This option should only be necessary on older servers.
Disable
Retries
Specifies the number of authentication retries that the BIG-IP system allows before authentication fails.
3

 

To create a RADIUS configuration object

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Configurations.
  3. In the upper right corner of the screen, click Create.
    This displays the New Configuration screen.
  4. For the Name setting, specify a unique name for the configuration object, such as my_radius_config.
  5. For the Type setting, select RADIUS.
    The screen expands to show several settings.
  6. Modify or retain values for all settings shown.
    (To configure advanced settings, locate the Configuration heading and select Advanced.)
  7. Click Finished.

Creating a RADIUS profile

Once you have created a RADIUS configuration object, you must create or configure a RADIUS profile. You do this by modifying the default radius profile or by creating a custom profile that inherits the default profile settings. An important function of the authentication profile is to reference an existing configuration object.

In most cases, the default profile should suit your needs. However, even if you use the default profile, you must still modify it to specify the corresponding configuration object that you created.

If you choose to create a custom profile, you must specify a parent profile (either a custom profile or the default profile) that contains the values that you want the new profile to inherit.

When you create a RADIUS profile, you configure a variety of settings. Table 10.5 shows the settings and values that make up a RADIUS profile. For the detailed procedure on creating a RADIUS profile, see To modify the default RADIUS profile , following, or To create a custom RADIUS profile .

Table 10.5 Settings of a RADIUS profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to RADIUS.
No default value
Parent Profile
Specifies the profile from which you want to inherit values.
radius
Mode
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Enabled
Configuration
Specifies an existing RADIUS configuration object.
No default value
Rule
Specifies the name of an existing authentication rule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
auth_radius
Idle Timeout
Specifies the duration in seconds that an authentication or authorization request is idle before timing out. You can use the default value, specify a different value, or select Indefinite.
300

 

To modify the default RADIUS profile

  1. On the Main tab, expand Local Traffic, click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
    This displays the list of default authentication profiles.
  3. In the Name column, click radius.
  4. For the Mode setting, select Enabled or Auto.
  5. For the Configuration setting, select a configuration object from the list. Note that None is not an allowed setting.
  6. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_radius, leave the setting as is.
    • If you do not want to use the default iRule auth_radius, select the name of an existing iRule that you have created.
  7. Click Finished.

To create a custom RADIUS profile

  1. On the Main tab, expand Local Traffic, click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
  3. In the upper right corner of the screen, click Create.
    This displays the New Profile screen.
  4. In the Name setting, type a unique name for the RADIUS profile, such as my_radius_profile.
  5. In the Type setting, select RADIUS.
    The screen expands to show additional settings
  6. For the Parent Profile setting:
    • If you want to use the default profile radius for the parent profile, leave the setting as is.
    • If you want to use a custom profile for the parent profile, select a custom profile name from the list.
  7. In the Mode setting, select Enabled or Auto.
  8. In the Configuration setting, select a configuration object from the list.
  9. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_radius, leave the setting as is.
    • If you do not want to use the default iRule auth_radius, select the name of an existing iRule that you have created.
  10. Click Finished.

After you have created a RADIUS server object, a RADIUS configuration object, and a RADIUS profile, you must assign the profile to the virtual server by configuring the virtual server's Authentication Profile setting.

For information on how to configure virtual server settings, see Chapter 2, Configuring Virtual Servers .

Implementing a TACACS+ authentication module

A TACACS+ authentication module is a mechanism for authenticating client connections passing through a BIG-IP system. You use this module when your authentication data is stored on a remote TACACS+ server. In this case, client credentials are based on basic HTTP authentication (that is, user name and password).

To implement the TACACS+ authentication module, you must configure the BIG-IP system to access data on a remote TACACS+ server. To do this, you must create:

  • A TACACS+ configuration object
  • A TACACS+ profile

After you create these objects, you must then assign the TACACS+ profile to a virtual server.

Creating a TACACS+ configuration object

When you create a TACACS+ configuration object, you configure a variety of settings. Table 10.6 shows the settings and values that make up a TACACS+ configuration object. Note that this table groups the settings into the same categories that you see on the New Authentication Configuration screen. For the detailed procedure on how to create this object, see To create a TACACS+ configuration object .

Table 10.6 Settings of a TACACS+ configuration object
Setting
Description
Default Value
Name
Specifies a unique name for the configuration object. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to TACACS+.
No default value
Servers
Specifies a host name or IP address for the TACACS++ server. This setting is required.
No default value
Secret
Sets the secret key used to encrypt and decrypt packets sent or received from the server. This setting is required.
No default value
Confirm Secret
Confirms the secret key supplied for the Secret setting. This setting is required.
No default value
Encryption
Enables or disables encryption of TACACS+ packets. Recommended for normal use.
Enabled
Service Name
Specifies the TACACS+ server's listening device, such as ppp.
No default value
Protocol Name
Specifies the TACACS+ server's listening device, such as lcp.
No default value
Authentication
Specifies authentication options. Possible values are Authenticate to first server and Authenticate to each server until success.
Authenticate to first server
Accounting Information
If multiple TACACS+ servers are defined and PAM session accounting is enabled, sends accounting start and stop packets to the first available server or to all servers. Possible values are Send to first available server and Send to all servers.
Send to first available server
Debug Logging
Enables SYSLOG debugging information at LOG_DEBUG level. Not recommended for normal use.
Disable

 

To create a TACACS+ configuration object

  1. On the Main tab, expand Local Traffic, click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Configurations.
  3. In the upper right corner of the screen, click Create.
    This displays the New Configuration screen.
  4. For the Name setting, specify a unique name for the configuration object, such as my_tacacs_config.
  5. For the Type setting, select TACACS+.
    The screen expands to show several settings.
  6. Modify or retain values for all settings shown.
    (To configure advanced settings, locate the Configuration heading and select Advanced.)
  7. Click Finished.

Creating a TACACS+ profile

Once you have created a TACACS+ configuration object, you must create or configure a TACACS+ profile. You do this by modifying the default tacacs+ profile or by creating a custom profile that inherits the default profile settings. An important function of the authentication profile is to reference an existing configuration object.

In most cases, the default profile should suit your needs. However, even if you use the default profile, you must still modify it to specify the corresponding configuration object that you created.

If you choose to create a custom profile, you must specify a parent profile (either a custom profile or the default profile) that contains the values that you want the new profile to inherit.

When you create a TACACS+ profile, you configure a variety of settings. Table 10.7 shows the settings and values that make up a TACACS+ profile. For the detailed procedure on creating a TACACS+ profile, see To modify the default TACACS+ profile , following, or To create a custom TACACS+ profile .

Table 10.7 Settings of a TACACS+ profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to TACACS+.
No default value
Parent Profile
Specifies the profile from which you want to inherit values.
tacacs+
Mode
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Enabled
Configuration
Specifies an existing TACACS+ configuration object.
No default value
Rule
Specifies the name of an existing authentication rule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
auth_tacacs+
Idle Timeout
Specifies the duration in seconds that an authentication or authorization request is idle before timing out. You can use the default value, specify a different value, or select Indefinite.
300

 

To modify the default TACACS+ profile

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
    This displays the list of default authentication profiles.
  3. In the Name column, click tacacs+.
  4. For the Mode setting, select Enabled or Auto.
  5. For the Configuration setting, select a configuration object from the list. Note that None is not an allowed setting.
  6. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_tacacs, leave the setting as is.
    • If you do not want to use the default iRule auth_tacacs, select the name of an existing iRule that you have created.
  7. Click Finished.

To create a custom TACACS+ profile

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
  3. In the upper right corner of the screen, click Create.
    This displays the New Profile screen.
  4. For the Name setting, specify a unique name for the profile.
  5. For the Type setting, select TACACS+.
  6. For the Parent Profile setting:
    • If you want to use the default profile tacacs for the parent profile, leave the setting as is.
    • If you want to use a custom profile for the parent profile, select a custom profile name from the list.
  7. For the Mode setting, select Enabled or Auto.
  8. For the Configuration setting, select a configuration object from the list.
  9. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_tacacs, leave the setting as is.
    • If you do not want to use the default iRule auth_tacacs, select the name of an existing iRule that you have created.
  10. Click Finished.

After you have created a TACACS+ configuration object and a TACACS+ profile, you must assign the profile to the virtual server by configuring the virtual server's Authentication Profile setting.

For information on how to configure virtual server settings, see Chapter 2, Configuring Virtual Servers .

Implementing an SSL client certificate LDAP authentication module

An SSL client certificate LDAP authentication module is a mechanism for authorizing client connections passing through a BIG-IP system. With the SSL Client Certificate LDAP authentication module, you can use a remote LDAP server to impose access control on application traffic. The module bases this access control on SSL certificates, as well as user groups and roles that you specify.

With the SSL client certificate LDAP authentication module, the BIG-IP system can indicate that the authorization was a success or failure, or that the LDAP server needs a credential of some sort.

Additionally, the system can take some action based on certain information that the server returns in the LDAP query response. For example, LDAP response information can indicate the user's group membership, or it can indicate that the user's password has expired. To configure the BIG-IP system to return specific data in an LDAP response, you can write an iRule, using the commands AUTH::subscribe, AUTH::unsubscribe, and AUTH::result-data. For more information, see Chapter 15, Writing iRules , and the F5 Networks DevCentral web site, http://devcentral.f5.com.

Important

Prior to implementing an SSL client certificate LDAP authentication module, you must configure and implement a Client SSL profile. When you configure a Client SSL profile, we recommend that you set the Client Certificate property to either Require or Auto. Setting this property to Ignore or Request could cause SSL connections to terminate. For a description of the Client Certificate setting, see Chapter 9, Managing SSL Traffic .

Understanding SSL client certificate authorization

With SSL client certificate LDAP authorization, the BIG-IP system can authorize clients based on signed client certificates issued by trusted CAs. Then, to further enhance the ability of the system to authorize client requests, you can also specify groups and roles. Basing authorization on certificates as well as groups and roles provides the flexibility you need to control client access to system resources.

Before you can implement an SSL client certificate LDAP module, you must understand the two different types of credentials that the BIG-IP system uses to authorize application traffic using data on a remote LDAP server. These two types of credentials are:

  • SSL certificates
  • Groups and roles

Using SSL certificates for LDAP authorization

During the process of authorizing a client, the BIG-IP system must search the LDAP database. When using certificate-based authorization, the system can search the LDAP database in three ways:

  • User
    If certificates are not stored in the LDAP database, you can configure the system to extract a user name from the certificate presented as part of the incoming client request. The system then checks to see if an entry for the user exists in the LDAP database. This scenario is a good choice for a company that acts as its own Certificate Authority, where the company is assured that if the certificate is verified, then the user is authorized.
  • Certificate Map
    If you create an object and class that map certificates to users in the LDAP database, you can then configure the system to search for a certificate in the map, and retrieve a user from that map. The system then checks to ensure that the user in the LDAP database is a valid user.
  • Certificate
    Many LDAP server environments already incorporate certificates into the user information stored in the LDAP database. One way of configuring authorization in LDAP server environments is to configure the system to compare an incoming certificate to the certificate stored in the LDAP database for the user associated with the client request. If the certificate is found in the user's LDAP profile, access is granted to the user, and the request is granted.

Regardless of the type of certificate-based authorization being performed, the process yields the results shown in Table 10.8 .

Table 10.8 Search results and corresponding authorization status
Result of search
Authorization status
No records match
Authorization fails
One record matches
Authorization succeeds and is subject to groups and roles
Two or more records match
Authorization fails, due to invalid database entries

 

Using groups and roles for LDAP authorization

In addition to enabling certificate-based authorization, you can also configure authorization based on groups and roles.

  • Groups
    Because LDAP servers already have the concept and structure of groups built into them, the BIG-IP system can include groups in its authorization feature. To enable the use of groups for authorization purposes, you must indicate the base and scope under which the system will search for groups in the LDAP database. Also, you must specify setting values for a group name and a member name. Once you have completed these tasks, the system can search through the list of valid groups until a group is found that has the current user as a member.
  • Roles
    Unlike a group, a role is a setting directly associated with a user. Any role-based authorization that the BIG-IP system performs depends on the LDAP database having the concept of roles built into it. To determine if a user should be granted access to a resource, the BIG-IP system searches through the roles assigned to the user and attempts to match that role to a valid role defined by the administrator.

To implement SSL client certificate LDAP authorization, you must configure the BIG-IP system to access data on a remote LDAP server. To do this, you must create:

  • An SSL client certificate LDAP configuration object
  • An SSL client certificate LDAP profile

After you create these objects, you must then assign the SSL client certificate LDAP profile to a virtual server.

Creating an SSL client certificate LDAP configuration object

The SSL client certificate LDAP configuration object consists of a set of data and instructions that the corresponding external LDAP server needs when servicing an authorization request from the BIG-IP system.

When you create an SSL client certificate LDAP configuration object, you configure a variety of settings. Table 10.9 lists and describes the settings that you can specify in this configuration object. Note that this table groups the settings into the same categories that you see on the New Authentication Configuration screen. For the detailed procedure on how to configure this object, see To create an SSL client certificate LDAP configuration object .

 

Table 10.9 Settings of an SSL client certificate LDAP configuration object
Setting
Description
Default value
Name
Specifies a unique name for the configuration object. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to SSL Client Certificate LDAP.
No default value
Hosts
Lists the IP addresses, including port numbers, of the LDAP servers that the BIG-IP system will use to obtain authorization data.
No default value
Search Type
Specifies the certificate-based authorization method that the system uses when searching the LDAP database (described in Using SSL certificates for LDAP authorization ). Possible values are User, Certificate Map, and Certificate.
User
User Base DN
Specifies the search base for the subtree used by the User and Certificate search types.
A typical search base is: ou=people,dc=company,dc=com. This setting is required. For more information, see the Search Type setting.
No default value
User Key
Specifies the name of the attribute in the LDAP database that specifies a user ID. Used by the User and Certificate search type. A typical example of a user key value is uid. This setting is required. For more information, see the Search Type setting.
No default value
Object Class
Specifies a user authentication method. This setting only appears when you set the search type to Certificate.
StrongAuthenticationUser
Certificate Map Base DN
Specifies the search base for the subtree used by the Certificate Map search types.
A typical search base is: ou=people,dc=company,dc=com. This setting is required. For more information, see the Search Type setting.
No default value
Certificate Map Key
Specifies the name of the attribute in the LDAP database that specifies a user ID. Used by the Certificate Map search type. A typical example of a user key value is uid. This setting is required. For more information, see the Search Type setting.
No default value
Use Serial Certificate Map
Causes the system to use the serial number of the client certificate instead of the subject, when you the select Certificate Map search type.
Disabled
Cache Size
Specifies the maximum size allowed for the SSL session cache. Setting this value to 0 disallows SSL session caching.
20000
Cache Timeout
Specifies the number of usable lifetime seconds of negotiable SSL session IDs. If this time has expired, a client must negotiate a new session.
300
Secure
Instructs the BIG-IP system to use secure communication (that is, SSL/TLS) between the system and the LDAP server.
Disabled
Admin DN
Specifies the distinguished name of an account to which to bind, in order to perform searches. This search account is a read-only account used to do searches. The admin account can be used as the search account. If no admin DN is specified, then no bind is attempted. This setting is required only when a site does not allow anonymous searches.
No default value
Admin Password
Specifies the password for the search account created on the LDAP server.
No default value
Confirm Admin Password
Confirms the password specified for the search account created on the LDAP server.
No default value
Group Base DN
Specifies the search base for the subtree used by group searches. This parameter is only used when specifying valid groups. A typical search base would be similar to the following: ou=people,dc=company,dc=com.
No default value
Group Key
Indicates the name of the attribute in the LDAP database that specifies the group name in the group subtree.
No default value
Group Member Key
Indicates the name of the attribute in the LDAP database that specifies members (DNs) of a group.
No default value
Valid Groups
Specifies a list of groups to which a user must belong in order to be authorized. This option may be specified more than once. To be authorized, a client need only be a member of a single group specified in the string.
No default value
Role Key
Indicates the name of the attribute in the LDAP database that specifies a user's authorization roles. This key is used only when using valid roles (as described in the following entry).
No default value
Valid Roles
Specifies a list of roles. A user must be assigned to one of these roles in order to be authorized. Valid roles in this list are delimited by a space. This option may be specified more than once. To be authorized, a client need only be a member of a single role specified in the string.
No default value

 

To create an SSL client certificate LDAP configuration object

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Configurations.
  3. In the upper right corner of the screen, click Create.
    This displays the New Configuration screen.
  4. For the Name setting, specify a unique name for the configuration object.
  5. For the Type setting, select SSL Client Certificate LDAP.
  6. Modify or retain values for all other settings. (To configure advanced settings, locate the Configuration heading and select Advanced.)
  7. Click Finished.

Creating an SSL client certificate LDAP authorization profile

Once you have created an SSL client certificate LDAP configuration object, you must create or configure a corresponding profile. You do this by modifying the default ssl_cc_ldap profile or by creating a custom profile that inherits the default profile settings. An important function of the authentication profile is to reference an existing configuration object.

In most cases, the default profile should suit your needs. However, even if you use the default profile, you must still modify it to specify the corresponding configuration object that you created.

If you choose to create a custom profile, you must specify a parent profile (either a custom profile or the default profile) that contains the values that you want the new profile to inherit.

When you create an SSL client certificate LDAP profile, you configure a variety of settings. Table 10.10 shows the settings and values that make up an SSL client certificate LDAP profile. For the detailed procedure on creating this type of profile, see To modify the default SSL client certificate LDAP profile , following, or To create a custom SSL client certificate LDAP profile .

Table 10.10 Settings of an SSL client certificate LDAP profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to LDAP (SSL Client Certificate).
No default value
Parent Profile
Specifies the profile from which you want to inherit values.
ssl_cc_ldap
Mode
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Enabled
Configuration
Specifies an existing SSL client certificate LDAP configuration object.
No default value
Rule
Specifies the name of an existing authentication iRule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
auth_ssl_cc_ldap
Idle Timeout
Specifies the duration in seconds that an authorization request is idle before timing out. You can use the default value, specify a different value, or select Indefinite.
300

 

To modify the default SSL client certificate LDAP profile

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
    This displays the list of default authentication profiles.
  3. In the Name column, click ssl_cc_ldap.
  4. For the Mode setting, select Enabled or Auto.
  5. For the Configuration setting, select a configuration object from the list. Note that None is not an allowed setting.
  6. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_ssl_cc_ldap, leave the setting as is.
    • If you do not want to use the default iRule auth_ssl_cc_ldap, select the name of an existing iRule that you have created.
  7. Click Finished.

To create a custom SSL client certificate LDAP profile

  1. On the Main tab, expand Local Traffic.
  2. Click Profiles.
    The Profiles screen opens.
  3. From the Authentication menu, choose Profiles.
  4. In the upper right corner of the screen, click Create.
    This displays the New Profile screen.
  5. For the Name setting, specify a unique name for the profile.
  6. For the Type setting, select SSL Client Certificate LDAP.
  7. For the Parent Profile setting:
    • If you want to use the default profile ssl_cc_ldap for the parent profile, leave the setting as is.
    • If you want to use a custom profile for the parent profile, select a custom profile name from the list.
  8. For the Mode setting, click the Custom box on the right side of the screen, and select Enabled or Auto.
  9. For the Configuration setting, click the Custom box on the right side of the screen, and select a configuration object from the list.
  10. For the Rule setting, click the Custom box on the right side of the screen, and specify an authentication iRule:
    • If you want to use the default iRule auth_ssl_cc_ldap, leave the setting as is.
    • If you do not want to use the default iRule auth_ssl_cc_ldap, select the name of an existing iRule that you have created.
  11. Click Finished.

After you have created an SSL Client Certificate LDAP configuration object and an SSL Client Certificate LDAP profile, you must assign the profile to the virtual server by configuring the virtual server's Authentication Profile setting.

Implementing an SSL OCSP authentication module

An SSL OCSP authentication module is a mechanism for authenticating client connections passing through a BIG-IP system. More specifically, an SSL OCSP authentication module checks the revocation status of an SSL certificate, as part of authenticating that certificate.

Online Certificate Status Protocol (OCSP) is a third-party software application and industry-standard protocol that offers an alternative to a certificate revocation list (CRL) when using public-key technology. A CRL is a list of revoked client certificates, which a server system can check during the process of verifying a client certificate.

You implement an SSL OCSP authentication module when you want to use OCSP instead of a CRL as the mechanism for checking the revocation status of SSL certificates.

The BIG-IP system supports both CRLs and the OCSP protocol. If you want to use CRLs instead of OCSP, you configure an SSL profile. For more information on CRLs, see Chapter 9, Managing SSL Traffic .

For more information on OCSP, see RFC 2560 at URL http://www.ietf.org.

Understanding OCSP

Using OCSP to check on the revocation status of client certificates offers distinct advantages over the use of a CRL. The following sections describe the differences between CRLs and OCSP, as well as the way that OCSP operates.

The limitations of CRLs

When presented with a client certificate, the BIG-IP system sometimes needs to assess the revocation state of that certificate before accepting the certificate and forwarding the connection to a target server. The standard method of assessing revocation status is a CRL, which is stored in a separate CRL file on each machine in your configuration. Although CRLs are considered to be a standard way of checking revocation status of SSL certificates, a CRL is updated only at fixed intervals, thus presenting a risk that the information in the CRL is outdated at the time that the status check occurs.

Also, having to store a separate CRL file on each machine presents other limitations:

  • All CRL files must be kept in sync.
  • Having a separate CRL file on each machine poses a security risk.
  • Multiple CRL files cannot be administered from a central location.

The benefits of OCSP

OCSP ensures that the BIG-IP system always obtains real-time revocation status during the certificate verification process.

OCSP is based on a client/server model, where a client system requests revocation status of a certificate, and a server system sends the response. Thus, when you implement the SSL OCSP authentication module, the BIG-IP system acts as the OCSP client, and an external system, known as an OCSP responder, acts as the OCSP server. An OCSP responder is therefore an external server that sends certificate revocation status, upon request, to the BIG-IP system.

How does OCSP work?

In general, after receiving an SSL certificate from a client application, the BIG-IP system (acting as an OCSP client) requests certificate revocation status from an OCSP responder, and then blocks the connection until it receives status from that responder. If the status from the responder shows that the certificate has been revoked, the BIG-IP system rejects the certificate and denies the connection. If the status from the responder shows that the certificate is still valid, the BIG-IP system continues with its normal certificate verification process to authenticate the client application.

More specifically, when an application client sends a certificate for authentication, the BIG-IP system follows this process:

  • First, the BIG-IP system checks that the signer of the certificate is listed in the trusted CAs file.
  • If the certificate is listed, the BIG-IP system then checks to see if the certificate has been revoked. Without OCSP, if the CRL option is configured on the BIG-IP system, the BIG-IP system checks revocation status by reading the certificate revocation list (CRL). With OCSP, however, the BIG-IP system bypasses the CRL and prepares to send a revocation status request to the appropriate OCSP responder.
  • The BIG-IP system then chooses the OCSP responder by checking the CA specified in the Issuer field of the original client certificate.
  • Next, the BIG-IP system attempts to match that CA with a CA listed in an SSL OCSP profile.
  • If a match exists, the BIG-IP system checks the target URL within the client certificate's AuthorityInfoAccess (AIA) field (if the field exists), and uses that URL to send the request for certificate revocation status to the OCSP responder.
  • If the Ignore AIA parameter is enabled within the SSL OCSP profile, then the BIG-IP system instead uses the URL specified in the url parameter of the matching SSL OCSP profile to send the request for certificate revocation status.
  • If no match exists, the BIG-IP system checks the calist setting of another SSL OCSP profile defined on the system. If all SSL OCSP profiles are checked and no match is found, the certificate verification fails, and the BIG-IP system denies the original client request.
  • Once the BIG-IP system has received certificate revocation status from a responder, the BIG-IP system, when configured to do so, inserts a certificate status header into the original client request. The name of the certificate status header is SSLClientCertificateStatus. For more information on this header, see Prerequisite BIG-IP system profiles , following.

To implement the SSL OCSP authentication module, you must configure the BIG-IP system to access data on a remote OCSP server. To do this, you must create:

  • An SSL OCSP responder object
  • An SSL OCSP configuration object
  • An SSL OCSP profile

After you create these objects, you must then assign the OCSP profile to a virtual server.

A single SSL OCSP profile can target a specific responder, or multiple SSL OCSP profiles can target the same responder. Each responder itself is associated with a certificate authority (CA), and multiple responders can be associated with the same CA.

Note

The BIG-IP system allows you to enable both the CRL and the OCSP options. Most users need to enable either one or the other, but not both. However, in the rare case that you want to enable both options, be aware that both the search of the CRL file, and the connection to the responder must be successful. Otherwise, the BIG-IP system cannot obtain status.

Prerequisite BIG-IP system profiles

Configuring an SSL OCSP authentication module not only requires the creation of an OCSP responder object and SSL OCSP profile, but also the creation of two other profiles: HTTP and Client SSL.

When you create a Client SSL profile, we recommend that you configure the profile to request, but not require, certificates. This optimizes the BIG-IP system's use of the SSLClientCertificateStatus header. Note that the BIG-IP system only inserts this header when previously configured to insert headers into client requests (either through an HTTP profile or through an iRule).

The following sections describe how to create an OCSP responder object, an SSL OCSP configuration object, and an SSL OCSP profile.

Creating an OCSP responder object

An OCSP responder object is an object that you create that includes a URL for an external OCSP responder. You must create a separate OCSP responder object for each external OCSP responder.

When you subsequently create an OCSP configuration object, the configuration object contains a reference to any OCSP responder objects that you have created.

When you create an OCSP responder object, you configure some settings. Table 10.11 shows the settings and values that make up an SSL OCSP responder object. For the detailed procedure on how to create this object, see To create an OCSP responder object .

Table 10.11 Settings of an OCSP responder
Setting
Description
Default Value
Name
Specifies a unique name for the configuration object. This setting is required.
No default value
URL
Specifies the URL used to contact the OCSP service on the responder.
No default value
Certificate Authority File
Specifies the name of the file containing trusted CA certificates used to verify the signature on the OCSP response.
No default value
Certificate Authority Path
Specifies the name of the path containing trusted CA certificates used to verify the signature on the OCSP response.
No default value
Verify Other
Specifies the name of the file used to search for an OCSP response signing certificate when the certificate has been omitted from the response.
No default value
Trust Other
Instructs the BIG-IP system to trust the certificates specified with the Verify Other setting.
Disable
VA File
Specifies the name of the file containing explicitly-trusted responder certificates. This parameter is needed in the event that the responder is not covered by the certificates already loaded into the responder's CA store.
No default value
Signer
Specifies the certificate used to sign an OCSP request.
Special meanings:
If the certificate is specified but the key is not specified, then the private key is read from the same file as the certificate.
If neither the certificate nor the key is specified, then the request is not signed.
If the certificate is not specified and the key is specified, then the configuration is considered to be invalid.
No default value
Signing Key
Specifies a key used to sign an OCSP request.
No default value
Sign Other
Lists additional certificates to add to an OCSP request.
No default value
Sign Digest
Specifies the algorithm for signing the request, using the signing certificate and key.
Special meanings:
This parameter has no meaning if request signing is not in effect (that is, both the request signing certificate and request signing key parameters are empty).
This parameter is required only when request signing is in effect.
Sha1
Validity Period
Specifies the number of seconds that the BIG-IP system should use to specify an acceptable error range. This setting is used when the OCSP responder clock and a client clock are not synchronized, which could cause a certificate status check to fail. This value must be a positive number. This parameter is required.
300
Status Age
Specifies a time in seconds to compare to the notBefore field of a status response. Used when the status response does not include the notAfter field.
0
Ignore AIA
Instructs the BIG-IP system to ignore the URL contained in the certificate's AIA fields, and to always use the URL that the responder specifies instead.
Disabled
Trust Other
Specifies that the certificates should be explicitly trusted and no other checks should be performed on them.
Disabled
Allow Certificates
Allows the addition of certificates to an OCSP request.
Enabled
Verify
Causes the BIG-IP system to verify an OCSP response signature or the nonce values. Used for debugging purposes only.
Enabled
Intern
Causes the BIG-IP system to ignore certificates contained in an OCSP response when searching for the signer's certificate. To use this setting, the signer's certificate must be specified with either the Verify Other or VA File setting.
Enabled
Verify Signature
Causes the BIG-IP system to check the signature on the OCSP response. Used for testing purposes only.
Enabled
Verify Certificate
Causes the BIG-IP system to verify the certificate in the OCSP response.
Enabled
Certificate Chain
Causes the BIG-IP system to construct a chain from certificates in the OCSP response.
Enabled
Check Certificates
Causes the BIG-IP system to make additional checks to see if the signer's certificate is authorized to provide the necessary status information. Used for testing purposes only
Enabled
Explicit OCSP
Causes the BIG-IP system to explicitly trust that the OCSP response signer's certificate is authorized for OCSP response signing. If the signer's certificate does not contain the OCSP signing extension, specification of this setting causes a response to be untrusted.
Enabled

 

To create an OCSP responder object

  1. On the Main tab, expand Local Traffic, and click Profiles.
  2. From the Authentication menu, choose OCSP Responders.
  3. In the upper right corner of the screen, click Create.
  4. For the Name setting, type a unique name for the responder object, such as my_ocsp_responder.
  5. For the URL setting, type a URL for the external responder.
  6. Modify or retain values for all other settings. (To configure advanced settings, locate the Configuration heading and select Advanced).
  7. Click Finished.

Creating an SSL OCSP configuration object

The SSL OCSP configuration object is an object that references one or more OCSP responder objects.

When you create an OCSP configuration object, you configure a variety of settings. Table 10.12 lists and describes the settings that you can specify in an SSL OCSP configuration object. For the detailed procedure on how to configure this object, see To create an SSL OCSP configuration object , following.

Table 10.12 Settings of an SSL OCSP configuration object
Setting
Description
Default Value
Name
Specifies a unique name for the configuration object. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to SSL OCSP.
No default value
Responders
Specifies the OCSP responders that you want to use for checking that revocation status of SSL certificates.
No default value

 

To create an SSL OCSP configuration object

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Configurations.
  3. In the upper right corner of the screen, click Create.
    This displays the New Configuration screen.
  4. For the Name setting, specify a unique name for the configuration object, such as my_ocsp_config.
  5. For the Type setting, select SSL OCSP.
  6. For the Responders setting, specify all responder objects.
  7. Click Finished.

Creating an SSL OCSP profile

Once you have created an SSL OCSP configuration object, you must create or configure an SSL OCSP profile. You do this by modifying the default ssl_ocsp profile or by creating a custom profile that inherits the default profile settings. An important function of the authentication profile is to reference an existing configuration object.

In most cases, the default profile should suit your needs. However, even if you use the default profile, you must still modify it to specify the corresponding configuration object that you created.

If you choose to create a custom profile, you must specify a parent profile (either a custom profile or the default profile) that contains the values that you want the new profile to inherit.

When you create an OCSP profile, you configure a variety of settings. Table 10.13 shows the settings and values that make up an SSL OCSP profile. For the detailed procedure on creating an OCSP profile, see To modify the default SSL OCSP profile , or To create a custom SSL OCSP profile .

Table 10.13 Settings of an SSL OCSP profile
Setting
Description
Default Value
Name
Specifies a unique name for the profile. This setting is required.
No default value
Type
Specifies the type of authentication module you want to implement. You must set this value to OCSP.
No default value
Parent Profile
Specifies the profile from which you want to inherit values.
ssl_ocsp
Mode
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Enabled
Configuration
Specifies the name of an existing OCSP configuration object. This setting is required.
No default value
Rule
Specifies the name of an existing authentication iRule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
auth_ssl_ocsp
Idle Timeout
Specifies the duration in seconds that an authentication request is idle before timing out. You can use the default value, specify a different value, or select Indefinite.
300

 

To modify the default SSL OCSP profile

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
    This displays the list of default authentication profiles.
  3. In the Name column, click ssl_ocsp.
  4. For the Mode setting, select Enabled or Auto.
  5. For the Configuration setting, select a configuration object from the list. Note that None is not an allowed setting.
  6. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_ocsp, leave the setting as is.
    • If you do not want to use the default iRule auth_ocsp, select the name of an existing iRule that you have created.
  7. Click Finished.

To create a custom SSL OCSP profile

  1. On the Main tab, expand Local Traffic, and click Profiles.
    The Profiles screen opens.
  2. From the Authentication menu, choose Profiles.
  3. In the upper right corner of the screen, click Create.
    This displays the New Profile screen.
  4. For the Name setting, specify a unique name for the profile.
  5. For the Type setting, select SSL OCSP.
  6. For the Parent Profile setting:
    • If you want to use the default profile ssl_ocsp for the parent profile, leave the setting as is.
    • If you want to use a custom profile for the parent profile, select a custom profile name from the list.
  7. For the Mode setting, click the Custom box on the right side of the screen, and select Enabled or Auto.
  8. For the Configuration setting, click the Custom box on the right side of the screen, and select a configuration object from the list.
  9. For the Rule setting, specify an authentication iRule:
    • If you want to use the default iRule auth_ocsp, leave the setting as is.
    • If you do not want to use the default iRule auth_ocsp, select the name of an existing iRule that you have created.
  10. Click Finished.

After you have created an SSL OCSP responder object, an SSL OCSP configuration object, and an SSL OCSP profile, you must assign the profile to the virtual server by configuring the virtual server's Authentication Profile setting.

For information on how to configure virtual server settings, see Chapter 2, Configuring Virtual Servers .




Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



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

Additional Comments (optional)