Applies To:

Show Versions Show Versions

Manual Chapter: Remote Server Authentication
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

12 
A significant feature of BIG-IP® Local Traffic ManagerTM 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, Local Traffic Manager 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.
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.
To configure and manage authentication profiles, log in to the BIG-IP Configuration utility, and on the Main tab, expand Local Traffic, and click Authentication.
Lightweight Directory Access Protocol (LDAP)
Local Traffic Manager 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)
Local Traffic Manager 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+
Local Traffic Manager 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
Local Traffic Manager 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)
Local Traffic Manager 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.
Certificate Revocation List Distribution Point (CRLDP)
Local Traffic Manager can use CRL distribution points to determine revocation status.
Kerberos Delegation
Local Traffic Manager can authenticate application traffic when you are using Microsoft® Windows® Integrated Authentication.
Important: When you create remote authentication objects and profiles, the BIG-IP system places them into your current administrative partition. Note that the default profile always resides in partition Common.
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, Local Traffic Manager 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 users group membership, or it can indicate that the users password has expired. To configure Local Traffic Manager to return specific data in an LDAP response, you can write an iRule, using the commands AUTH::subscribe, AUTH::unsubscribe, and AUTH::response_data. For more information, see Chapter 18, iRules, and the F5 Networks DevCentral web site, http://devcentral.f5.com.
Table 12.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.
Specifies the type of authentication module you want to implement. You must set this value to LDAP.
Lists the addresses of the LDAP servers that the BIG-IP system uses to obtain authentication data.
389 (non-SSL)
636 (SSL-enabled)
Specifies the distinguished name of an account to which to bind, in order to perform searches. The admin account can be used as the search account. If no Administrator 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 and a non-Administrator account is used as the search account, the distinguished name must be in the form of an email address.
Specifies the password for the search account created on the LDAP server. This setting is required if you use a bind DN.
Confirms the password for the bind distinguished name. This setting is optional.
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).
Specifies that the system should check the value or values of the Hosts setting when performing authentication/authorization.
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.
Specifies the name of an SSL CA certificate. Allowed values are: None, Default, and Specify Full Path.
Specifies the name of an SSL client key. Allowed values are: None, Default, and Specify Full Path.
Specifies the name of an SSL client certificate. Allowed values are: None, Default, and Specify Full Path.
Enables or disables SYSLOG debugging information at LOG_DEBUG level. Not recommended for normal use.
Table 12.2 shows the settings and values that make up an LDAP profile.
Specifies the type of authentication module you want to implement. You must set this value to LDAP.
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Specifies the name of an existing authentication iRule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
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. For general information on timeout values, see Chapter 1, Introducing BIG-IP Local Traffic Manager.
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).
When you create a RADIUS server object, you configure some settings. Table 12.3 shows the settings and values that make up a default RADIUS server object.
Specifies a unique name for the RADIUS server object, such as my_radius_object. This setting is required.
Sets the secret key used to encrypt and decrypt packets sent or received from the server. This setting is required.
Confirms the secret key supplied for the Secret setting. This setting is required.
When you create a RADIUS configuration object, you configure a variety of settings. Table 12.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.
Specifies the type of authentication module you want to implement. You must set this value to RADIUS.
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 12.3.
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.
Enables SYSLOG debugging information at LOG_DEBUG level. We do not recommend this for normal use.
Disables validation of the accounting response vector. This option should only be necessary on older servers.
Specifies the number of authentication retries that the BIG-IP system allows before authentication fails.
When you create a RADIUS profile, you configure a variety of settings. Table 12.5 shows the settings and values that make up a RADIUS profile.
Specifies the type of authentication module you want to implement. You must set this value to RADIUS.
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Specifies the name of an existing authentication rule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
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. For general information on timeout values, see Chapter 1, Introducing BIG-IP Local Traffic Manager.
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).
When you create a TACACS+ configuration object, you configure a variety of settings. Table 12.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.
Table 12.6 Settings of a TACACS+ configuration object
Specifies the type of authentication module you want to implement. You must set this value to TACACS+.
Sets the secret key used to encrypt and decrypt packets sent or received from the server. This setting is required.
Confirms the secret key supplied for the Secret setting. This setting is required.
Specifies the name of the service that the user is requesting to be authorized to use (or in the case of ppp, authenticated to use). Identifying what the user is asking to be authorized or authenticated for enables the TACACS+ server to behave differently for different types of authorization or authentication requests. Specifying this setting is required. You can use following values: slip, ppp, arap, shell, tty-daemon, connection, system, and firewall.
Specifies the protocol associated with the value specified in the Service Name setting, which is a subset of the associated service being used for client authorization or system accounting. You can use the following values: lcp, ip, ipx, atalk, vines, lat, xremote, tn3270, telnet, rlogin, pad, vpdn, ftp, http, deccp, osicp, and unknown.
Specifies the process that the system uses when sending authentication requests. Possible values are:
Authenticate to first server: Specifies that the system sends an authentication attempt to the first server in the list. If that fails to authenticate, the authentication is halted at that point. If failing for any other reason, authentication continues on to the next server in the list.
Authenticate to each server until success: Specifies that the system sends an authentication request to each server until authentication succeeds, or until the system has sent a request to all servers in the list.
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.
Enables SYSLOG debugging information at LOG_DEBUG level. Not recommended for normal use.
When you create a TACACS+ profile, you configure a variety of settings. Table 12.7, shows the settings and values that make up a TACACS+ profile.
Specifies the type of authentication module you want to implement. You must set this value to TACACS+.
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Specifies the name of an existing authentication rule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
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. For general information on timeout values, see Chapter 1, Introducing BIG-IP Local Traffic Manager.
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, Local Traffic Manager 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 users group membership, or it can indicate that the users password has expired. To configure Local Traffic Manager to return specific data in an LDAP response, you can write an iRule, using the commands AUTH::subscribe, AUTH::unsubscribe, and AUTH::response_data. For more information, see Chapter 18, iRules, and the F5 Networks DevCentral web site, http://devcentral.f5.com.
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:
With SSL client certificate LDAP authorization, Local Traffic Manager 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.
During the process of authorizing a client, Local Traffic Manager 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 users LDAP profile, access is granted to the user, and the request is granted.
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, Local Traffic Manager 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 Local Traffic Manager 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, Local Traffic Manager searches through the roles assigned to the user and attempts to match that role to a valid role defined by the administrator.
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 12.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.
Specifies the type of authentication module you want to implement. You must set this value to SSL Client Certificate LDAP.
Lists the IP addresses, including port numbers, of the LDAP servers that the BIG-IP system will use to obtain authorization data.
Specifies the certificate-based authorization method that the system uses when searching the LDAP database (described in SSL certificates for LDAP authorization). Possible values are User, Certificate Map, and Certificate.
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.
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.
Specifies a user authentication method. This setting only appears when you set the search type to Certificate.
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.
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.
Causes the system to use the serial number of the client certificate instead of the subject, when you the select Certificate Map search type.
Specifies the maximum size allowed for the SSL session cache. Setting this value to 0 disallows SSL session caching.
Specifies the number of usable lifetime seconds of negotiable SSL session IDs. If this time has expired, a client must negotiate a new session.
Instructs the BIG-IP system to use secure communication (that is, SSL/TLS) between the system and the LDAP server.
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.
Specifies the password for the search account created on the LDAP server.
Confirms the password specified for the search account created on the LDAP server.
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.
Indicates the name of the attribute in the LDAP database that specifies the group name in the group subtree.
Indicates the name of the attribute in the LDAP database that specifies members (DNs) of a group.
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.
Indicates the name of the attribute in the LDAP database that specifies a users authorization roles. This key is used only when using valid roles (as described in the following entry).
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.
When you create an SSL client certificate LDAP profile, you configure a variety of settings. Table 12.10 shows the settings and values that make up an SSL client certificate LDAP profile.
Table 12.10 Settings of an SSL client certificate LDAP profile
Specifies the type of authentication module you want to implement. You must set this value to LDAP (SSL Client Certificate).
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Specifies the name of an existing authentication iRule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
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. For general information on timeout values, see Chapter 1, Introducing BIG-IP Local Traffic Manager.
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.
Local Traffic Manager supports both CRLs and the OCSP protocol. If you want to use CRLs instead of OCSP, you configure an SSL profile.
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.
When presented with a client certificate, Local Traffic Manager 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.
OCSP ensures that Local Traffic Manager 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.
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, Local Traffic Manager rejects the certificate and denies the connection. If the status from the responder shows that the certificate is still valid, Local Traffic Manager 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:
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.
Next, the BIG-IP system queries the first responder, even if the responder does not match the certificate authority that signed the client certificate. However, if the first responder fails with a connection error, the BIG-IP system queries the next responder.
If a match exists, the BIG-IP system checks the target URL within the client certificates 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.
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: Local Traffic Manager 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, Local Traffic Manager cannot obtain status.
Note that 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.
Table 12.11 shows the settings and values that make up an SSL OCSP responder object.
Specifies the name of the file containing trusted CA certificates used to verify the signature on the OCSP response.
Specifies the name of the path containing trusted CA certificates used to verify the signature on the OCSP response.
Specifies the name of the file used to search for an OCSP response signing certificate when the certificate has been omitted from the response.
Instructs the BIG-IP system to trust the certificates specified with the Verify Other setting.
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 responders CA store.
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 the certificate is not specified and the key is specified, then the configuration is considered to be invalid.
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).
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.
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.
Instructs the BIG-IP system to ignore the URL contained in the certificates AIA fields, and to always use the URL that the responder specifies instead.
Specifies that the certificates should be explicitly trusted and no other checks should be performed on them.
Causes the BIG-IP system to verify an OCSP response signature or the nonce values. Used for debugging purposes only.
Causes the BIG-IP system to ignore certificates contained in an OCSP response when searching for the signers certificate. To use this setting, the signers certificate must be specified with either the Verify Other or VA File setting.
Causes the BIG-IP system to check the signature on the OCSP response. Used for testing purposes only.
Causes the BIG-IP system to construct a chain from certificates in the OCSP response.
Causes the BIG-IP system to make additional checks to see if the signers certificate is authorized to provide the necessary status information. Used for testing purposes only
Causes the BIG-IP system to explicitly trust that the OCSP response signers certificate is authorized for OCSP response signing. If the signers certificate does not contain the OCSP signing extension, specification of this setting causes a response to be untrusted.
Table 12.12 lists and describes the settings that you can specify in an SSL OCSP configuration object.
Table 12.12 Settings of an SSL OCSP configuration object
Specifies the type of authentication module you want to implement. You must set this value to SSL OCSP.
Specifies the OCSP responders that you want to use for checking that revocation status of SSL certificates.
Table 12.13 shows the settings and values that make up an SSL OCSP profile.
Table 12.13 Settings of an SSL OCSP profile
Specifies the type of authentication module you want to implement. You must set this value to OCSP.
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Specifies the name of an existing authentication iRule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
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. For general information on timeout values, see Chapter 1, Introducing BIG-IP Local Traffic Manager.
A CRLDP authentication module is a mechanism for authenticating client connections passing through a BIG-IP system. You implement a CRLDP authentication module when you want the BIG-IP system to use CRL distribution points as the mechanism for checking the revocation status of SSL certificates.
This CRLDP authentication feature is based on a technology known as Certificate Revocation List Distribution Points (CRLDP). CRLDP is an industry-standard protocol that offers an alternative method for checking a standard certificate revocation list (CRL) to determine revocation status. CRLDP is also an alternative to using Online Certificate Status Protocol (OCSP).
A CRLDP authentication module uses CRL distribution points to check the revocation status of an SSL certificate, as part of authenticating that certificate. CRL distribution points are a mechanism used to distribute certificate revocation information across a network. More specifically, a distribution point is a Uniform Resource Identifier (URI) or directory name specified in a certificate that identifies how the server obtains CRL information. Distribution points can be used in conjunction with CRLs to configure certificate authorization using any number of LDAP servers.
Table 12.14 shows the settings and values that make up a CRLDP configuration object. Note that this table groups the settings into the same categories that you see on the New Authentication Configuration screen.
Specifies the type of authentication module you want to implement. You must set this value to CRLDP.
Specifies an update interval for CRL distribution points. The update interval for distribution points ensures that CRL status is checked at regular intervals, regardless of the CRL timeout value. This helps to prevent CRL information from becoming outdated before the BIG-IP system checks the status of a certificate.
Indicates whether the CRL distribution point should be extracted from the certificate of the client certificate issuer.
Lists the IP addresses of the CRLDP servers that the BIG-IP system will use to obtain authentication data.
Note that for each server listed, you must create a corresponding CRLDP server definition. A CRLDP server definition specifies the server name, IP address, port number, base DN, and reverse DN.
Table 12.15 shows the settings and values that make up a CRLDP profile.
Specifies the type of authentication module you want to implement. You must set this value to CRLDP.
Specifies whether the profile is enabled or disabled. Possible settings are Enabled and Disabled.
Specifies the name of an existing authentication rule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
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.
A Kerberos Delegation authentication module is a mechanism for authenticating client connections passing through a BIG-IP system. You can use this module when you are using Microsoft® Windows® Integrated Authentication to authenticate application traffic.
The Kerberos Delegation module obtains delegated Kerberos credentials for the client principal, and then retrieves Kerberos credentials for the server-side principal. The Kerberos Delegation module essentially acts as a proxy for Kerberos credentials. That is, when connecting to a server that is inside its domain, the browser client fetches Kerberos credentials. These credentials, known as delegated credentials, are passed to the BIG-IP system, which in turn retrieves credentials for the real server that is on the back end, and passes those credentials back to the client.
Table 12.16 shows the settings and values that make up a Kerberos Delegation configuration object.
Specifies the type of authentication module you want to implement. You must set this value to Kerberos Delegation.
Specifies the name of the client principal, using the format HTTP/<fqdn>, where fqdn is the fully-qualified domain name of the virtual server you create. For more information, see the guide titled BIG-IP® Local Traffic Manager: Implementations.
Specifies the name of the principal of the back-end web server, using the format HTTP/<fqdn>, where fqdn is the fully-qualified domain name of the web server in the pool.
Enables SYSLOG debugging information at LOG_DEBUG level. Not recommended for normal use.
Table 12.17 shows the settings and values that make up a Kerberos Delegation profile.
Specifies the type of authentication module you want to implement. You must set this value to Kerberos Delegation.
Specifies whether the profile is enabled or disabled. Possible settings are Auto, Enabled, and Disabled.
Specifies the name of an existing authentication rule. If you do not specify an iRule, the BIG-IP system uses the corresponding default iRule.
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. For general information on timeout values, see Chapter 1, Introducing BIG-IP Local Traffic Manager.
Specifies an encryption key, in the form of a strong password, for encrypting cookie data. F5 recommends that you change the default value so that attackers who know the default value cannot decrypt cookie data and impersonate trusted users.
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)