Manual Chapter : Authentication and Single Sign-On

Applies To:

Show Versions Show Versions

BIG-IQ Centralized Management

  • 5.4.0
Manual Chapter

About AAA server support

Access in BIG-IQ® Centralized Management interacts with authentication, authorization, and accounting (AAA) servers that contain user information. Access supports the following AAA servers:

  • RADIUS (authentication and accounting)
  • LDAP (authentication and query)
  • Active Directory (authentication and query)
  • SecurID
  • HTTP
  • Oracle Access Manager
  • OCSP Responder
  • CRLDP
  • TACACS+ (authentication and accounting)
  • Kerberos (authentication and authorization)

A typical configuration includes:

  • An AAA server configuration object that specifies information about the external AAA server.
  • An access policy that includes a logon item to obtain credentials and an authentication item that uses the credentials to authenticate against a specific AAA server.
Note: For more information, refer to the BIG-IP Access Policy Manager: Authentication and Single Sign-On guide.

About RADIUS authentication

BIG-IQ® Access supports authenticating and authorizing the client against external RADIUS servers. When a client connects with the user name and password, BIG-IQ Access authenticates against the external server on behalf of the client, and authorizes the client to access resources if the credentials are valid.

Configure a RADIUS AAA server

You create a RADIUS AAA server to authenticate and authorize a client with a valid user name and password.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click RADIUS.
  5. From either RADIUS (Shared) or RADIUS (Device-Specific), click Create.
    The New RADIUS screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific RADIUS server.
  8. For the Mode setting, select Authentication, Accounting, or Authentication & Accounting.
  9. For Authentication Service Port, type the authentication port number of your server. The default is 1812.
  10. For the Server Connection setting, select one of these options:
    • Select Use Pool to set up high availability for the AAA server.
    • Select Direct to set up the AAA server for standalone functionality.
  11. If you selected Use Pool, type a name in the Server Pool Name field.
    You create a pool of servers on this screen.
  12. Provide the addresses required for your server connection:
    • If you selected Direct, type an IP address in the Server Address field.
    • If you selected Use Pool, for each pool member you want to add, type an IP address in the Server Addresses field and click Add.
      Note: When you configure a pool, you have the option to type the server address in route domain format: IPAddress%RouteDomain .
  13. From the Server Pool Monitor dropdown menu, select a monitor to track the health of your AAA RADIUS server.
  14. In the Secret field, type the shared secret password of the server.
  15. In the Confirm Secret field, re-type the shared secret password of the server.
  16. For NAS IP Address, type an an IP address as a RADIUS attribute 4, NAS-IP-address, that you can configure without changing the source IP address in the IP header of the RADIUS packets.
  17. For NAS IPV6 Address, type an IPV6 address as a RADIUS attribute 4, NAS-IP-address, that you can configure without changing the source IP address in the IP header of the RADIUS packets.
  18. For NAS Identifier, type a string that identifies the NAS that originates the Access-Request.
  19. For Timeout, type the interval of time, in seconds, to wait for a response from the RADIUS AAA server before timing out. The default is 5.
  20. For Retries, type the number of times the BIG-IP system tries to make a connection to the RADIUS AAA server after the first attempt fails. The default is 3.
  21. From the Character Set dropdown menu, select the character encoding for the username and password.
    • Windows-1252 - APM RADIUS Auth agent decodes the username and password into CP-1252 before sending it to the RADIUS server. This is the default.
    • UTF-8 - RADIUS Auth sends the username and password unmodified.
  22. From the Service Type dropdown menu, select the type of service used for the RADIUS server. f you retain Default, the service type is set to Authenticate Only.
  23. Click Save.
The new AAA server displays on the RADIUS list.

About LDAP authentication

Use BIG-IQ Access to configure an LDAP AAA server You can use LDAPS in place of LDAP when the authentication messages between BIG-IP APM and the LDAP server must be secured with encryption. However, there are instances where you will not need LDAPS and the security it provides. For example, authentication traffic happens on the internal side of Access, and might not be subject to observation by unauthorized users. Another example of when not to use LDAPS is when authentication is used on separate VLANs to ensure that the traffic cannot be observed by unauthorized users.

LDAPS is achieved by directing LDAP traffic over a virtual server that uses server side SSL to communicate with the LDAP server. Essentially, the system creates an LDAP AAA object that has the address of the virtual server. That virtual server (with server SSL) directs its traffic to a pool, which has as a member that has the address of the LDAP server.

Configure an LDAP AAA server

You create an LDAPS AAA server when you need to encrypt authentication messages between Access and the LDAP server.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click LDAP.
  5. From either LDAP (Shared) or LDAP (Device-Specific), click Create.
    The New LDAP screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific LDAP server.
  8. For the Server Connection setting, select one of these options:
    • Select Use Pool to set up high availability for the AAA server.
    • Select Direct to set up the AAA server for standalone functionality.
  9. If you selected Use Pool, type a name in the Server Pool Name field.
    You create a pool of servers on this screen.
  10. Provide the addresses required for your server connection:
    • If you selected Direct, type an IP address in the Server Address field.
    • If you selected Use Pool, for each pool member you want to add, type an IP address in the Server Addresses field and click Add.
      Note: When you configure a pool, you have the option to type the server address in route domain format: IPAddress%RouteDomain .
  11. From the Server Pool Monitor dropdown menu, select a monitor to track the health of your AAA RADIUS server.
  12. For the Mode setting, select LDAP or LDAPS.
  13. For the Service Port setting, accept the default or type the port number of your AAA server. The default is 389 for LDAP and 636 for LDAPS.
  14. For Base Search DN, type a base distinguished name from which to search.
  15. In the Admin DN field, type the distinguished name (DN) of the user with administrator rights.
    Type the value in this format: CN=administrator,CN=users,DC=sales,DC=mycompany,DC=com.
  16. In the Admin Password field, type the administrative password for the server.
  17. In the Verify Admin Password field, re-type the administrative password for the server.
  18. For Group Cache Lifetime, type the lifetime of a group cache. The default lifetime is 30 days.
  19. For SSL Profile (Server), select your SSL server profile from the list. LDAPS is achieved by directing LDAP traffic over a virtual server that uses a server side SSL to communicate with the LDAP server. This only displays for LDAPS.
  20. For Timeout, type the number of seconds to reach the LDAP server initially. Accept the default (15) or type a number.
  21. To save your changes, click the Save & Close button at the bottom of the screen.
The new AAA server displays on the LDAP servers list.

About Active Directory authentication

Use BIG-IQ Access to configure an Active Directory AAA server. You can authenticate using Active Directory authentication with BIG-IQ Access, which supports using Kerberos-based authentication through Active Directory.

Configure an Active Directory AAA server

You configure an Active Directory AAA server to specify domain controllers for Access to use for authenticating users.

  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click Active Directory.
  5. From either Active Directory (Shared) or Active Directory (Device-Specific), click Create.
    The New Active Directory screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific Active Directory server.
  8. In the Domain Name field, type the name of the Windows domain.
  9. For the Server Connection setting, select one of these options:
    • Select Use Pool to set up high availability for the AAA server.
    • Select Direct to set up the AAA server for standalone functionality.
  10. If you selected Direct, type a name in the Domain Controller field.
  11. If you selected Use Pool, configure the pool:
    1. Type a name in the Domain Controller Pool Name field.
    2. Specify the Domain Controllers in the pool by typing the IP address and host name for each, and clicking the + button.
    3. To monitor the health of the AAA server, you have the option of selecting a health monitor. You can select it from the Server Pool Monitor list.
  12. In the Admin Name field, type a case-sensitive name for an administrator who has Active Directory administrative permissions.
    An administrator name and password are required for an AD Query access policy item to succeed when it includes particular options. Credentials are required when a query includes an option to fetch a primary group (or nested groups), to prompt a user to change password, or to perform a complexity check for password reset.
  13. In the Admin Password field, type the administrator password associated with the Domain Name.
  14. In the Verify Admin Password field, retype the administrator password associated with the Domain Name setting.
  15. In the Group Cache Lifetime field, type the number of days.
    The default lifetime is 30 days.
  16. In the Password Security Object Cache Lifetime field, type the number of days.
    The default lifetime is 30 days.
  17. From the Kerberos Preauthentication Encryption Type list, select an encryption type.
    The default is None. If you specify an encryption type, the BIG-IP® system includes Kerberos preauthentication data within the first authentication service request (AS-REQ) packet.
  18. In the Timeout field, accept the default value or type a number of seconds.
    The timeout specifies the number of seconds to reach the AAA Active Directory server initially. After the connection is made, the timeout for subsequent operations against the AAA Active Directory server is 180 seconds and is not configurable.
  19. Click Save.
The new AAA server displays on the Active Directory servers list.

About SecurID authentication

RSA SecurID is a two-factor authentication mechanism based on a one-time passcode (OTP) that is generated by using a token code provided by a software or hardware authenticator. A token is a one-time authentication code generated every 60 seconds by an authenticator (hardware or software) assigned to the user.

Configure a SecurID AAA server

You create a SecurID server for AAA authentication to request RSA SecurID authentication from an RSA Manager authentication server.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click SecurID.
  5. Click Create.
    The New SecurID screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device.
  8. In the Configuration area, for the Agent Host IP Address (must match the IP address in SecurID Configuration File) setting, select an option as appropriate:
    • Select from Self IP List: Choose this when there is no NAT device between APM and the RSA Authentication Manager. Select an IP from the list of those configured on the BIG-IP® system (in the Network area of the Configuration utility).
    • Other: Choose this when there is a NAT device in the network path between Access Policy Manager and the RSA Authentication Manager server. If selected, type the address as translated by the NAT device.
    Note: This setting does not change the source IP address of the packets that are sent to the RSA SecurID server. (Layer 3 source addresses remain unchanged.) The agent host IP address is used only in Layer 7 (application layer) information that is sent to the RSA SecurID server.
  9. For File Name, browse to upload the configuration file from the RSA SecurID console.
    Consult your RSA Authentication Manager administrator to generate this file for you.
  10. Click Save.
The new AAA server displays on the SecurID servers list.

About HTTP authentication

An HTTP AAA server directs users to an external web-based server to validate credentials. BIG-IQ Access supports these HTTP authentication types:

  • HTTP form-based authentication - Directs users to a form action URL and provides the specified form parameters
  • HTTP basic authentication - Directs users to a URI
  • HTTP NTLM authentication - Directs users to a URI
  • HTTP custom post - Directs users to a POST URL, a submit URL, or a relative URL and provides the specified content
Tip: Use HTTPS instead of HTTP authentication for improved security, because HTTP authentication passes user credentials as clear text.

Configuring an HTTP server for form-based authentication

You create a form-based HTTP AAA configuration to use HTTP form-based authentication from an access policy.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click HTTP.
  5. From either HTTP (Shared) or HTTP (Device-Specific), click Create.
    The New HTTP screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific HTTP server.
  8. For Authentication Type, select Form-Based.
  9. In the Start URI field, type the complete URI that returns the logon form.
    The URI resource must respond with a challenge to a non-authenticated request.
  10. Click Save.
The new HTTP server, configured for form-based authentication, displays on the HTTP servers list.
To put this authentication into effect, add this AAA server to an HTTP Auth action in an access policy.

Configuring an HTTP server for Basic/NTLM authentication

You configure an HTTP AAA server when you want to use Basic/NTLM authentication.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click HTTP.
  5. From either HTTP (Shared) or HTTP (Device-Specific), click Create.
    The New HTTP screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific HTTP server.
  8. For Authentication Type, select Basic/NTLM.
  9. Optional: In the Start URI field, type a URI, for example, http://plum.tree.lab2.sp.companynet.com/.
    This resource must respond with a challenge to a non-authenticated request.
    Note: This field is optional. If you type a URI in this field and you type a relative URL in the Form Action field, Access Policy Manager® (APM®) uses the value of the Start URI as the base URL; APM uses the base URL to resolve the relative URL and produce the final URL for HTTP POST.
  10. From the Form Method list, select either GET or POST.
    If you specify GET, the authentication request converts as HTTP GET.
  11. In the Form Action field, type a URL that specifies where to process the form and perform form-based authentication. If you specified a Start URI, you can type a relative URL, otherwise you must type an absolute URL:
    • relative URL - When specified, form-based authentication is performed after the URL is resolved using the base URL that is specified in the Start URI field.
    • absolute URL -When specified, form-based authentication is performed at this URL.
  12. In the Form Parameter For User Name and Form Parameter For Password fields, type the parameter name and password used by the form to which you are sending the POST request.
  13. In the Hidden Form Parameters/Values field, type the hidden form parameters required by the authentication server logon form at your location.
    You must provide hidden form parameters and values if there are any. When present, these values are required by the authentication server logon form at your location.
    Specify a parameter name, a space, and the parameter value, if any. Start each parameter on a new line. If you use a session variable as a value, format it as shown in this example: %{session.client.platform}.
  14. In the Number Of Redirects To Follow field, type how far from the landing page, in pages, the request should travel before failing.
  15. For the Successful Logon Detection Match Type setting, select the method your authenticating server uses, and type the option definition in the Successful Logon Detection Match Value field.
  16. Click Save.
The new HTTP server, configured for Basic/NTLM authentication, displays on the HTTP servers list.
To put this authentication into effect, add this AAA server to an HTTP Auth action in an access policy.

Configure an HTTP server for custom post authentication

You create a custom post configuration when there is no form and when body encoding is different from form encoding. (This can happen when POST is generated by JavaScript or ActiveX.) Using a custom post, you can specify the entire post body and any non-default HTTP headers.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click HTTP.
  5. From either HTTP (Shared) or HTTP (Device-Specific), click Create.
    The New HTTP screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific HTTP server.
  8. For Authentication Type, select Custom Post.
  9. In the Start URI field, type in a URL resource, for example, http://plum.tree.lab2.sp.companynet.com/.
    If you do not specify a Start URI, Access Policy Manager® will likely detect that the absolute URI based on the Form Action parameter should be used for HTTP POST. If you specify a Start URI, Access Policy Manager uses both the Start URI and the Form Action parameters as the final URL for HTTP POST.
  10. In the Form Action field, type the POST URL, the submit URL, or a relative URL.
  11. For the Successful Logon Detection Match Type setting, select the method that the authenticating server uses.
  12. For the Successful Logon Detection Match Value, type a value depending on the Successful Logon Detection Match Type that you selected:
    • By Resulting Redirect URL - Specify a URL if you selected this type.
    • By Presence of Specific String in Cookie - Specify a single string if you selected this type.
      Note: With this option, when APM® receives a duplicate cookie, it adds it to the existing cookie list. As a result, multiple cookies with the same name, domain, and path can exist and can be searched.
    • By Presence of Cookie That Exactly Matches - Specify the exact key fields (name, path, and domain) that are present in the HTTP response cookie if you select this type. Failure to supply the exact number of keys and the exact values for the HTTP response cookie results in a No matching cookie found error.
      Note: This option supports cookie merge functionality. When APM receives a cookie that has the same name, domain, and path as an existing cookie, it merges it into the existing cookie.
    • By Specific String in Response - Specify a string if you select this option.
  13. In the Number Of Redirects To Follow field, type how far from the landing page, in pages, the request should travel before failing.
  14. From the Content Type list, select an encoding for the HTTP custom post.
    The default setting is XML UTF-8.
    Note: If you select None, you must add a header in the Custom Headers setting and you must apply your own encoding through an iRule.
  15. In the Custom Body field, specify the body for the HTTP custom post.
  16. For Custom Headers, specify names and values for header content to insert in the HTTP custom post.
  17. Click Save.
The new HTTP server, configured for custom post authentication, displays on the HTTPs servers list.
To put this authentication into effect, add this AAA server to an HTTP Auth action in an access policy.

About Oracle Access Manager integration with Access

You can configure only one AAA Oracle Access Manager (OAM) server, but it can support multiple AccessGates from the same Access server. When you create a AAA OAM server, its transport security mode must match the setting in the OAM access server.

Configure an OAM AAA server

You create an OAM server for AAA authentication to deploy Access in place of OAM 10g WebGates.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click Oracle Access Manager.
  5. From either Oracle Access Manager (Shared) or Oracle Access Manager (Device-Specific), click Create.
    The New Oracle Access Manager screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific Oracle Access Manager server.
  8. For Access Server Name, type the name that was configured in Oracle Access System for the access server.
    For the access server name, open the OAM Access System Console and select Access system configuration > Access Server Configuration .
  9. For Access Server Hostname, type the fully qualified DNS host name for the access server system.
  10. For Access Server Port, accept the default 6021, or type the port number.
    For earlier versions of OAM, the default server port is 6021. For later versions, the default server port is 5575.
  11. For Admin Id, type the admin ID.
    Admin Id and Admin Password are the credentials that are used to retrieve host identifier information from OAM. Usually, these are the credentials for the administrator account of both Oracle Access Manager and Oracle Identity Manager.
  12. For Admin Password, type the admin password.
  13. For Verify Password, retype the password.
  14. For Retry Count, accept the default 0, or enter the number of times an AccessGate should attempt to contact the access server.
  15. For Transport Security Mode, select the mode (open, simple, or cert) that is configured for the access server in Oracle Access System.
  16. If Transport Security Mode is set to simple, type and re-type a Global Access Protocol Passphrase; it must match the global passphrase that is configured for the access server in OAM.
  17. For AccessGate Name, type the name of an AccessGate; it must match the name of an AccessGate that is configured on the OAM access server.
  18. For AccessGate Password and Verify Password, type the password; it must match the password that is configured for it on the OAM access server.
  19. If transport security mode is set to cert, select the Certificate, Key, and CA Certificate that you imported for this particular AccessGate.
  20. If transport security mode is set to cert and if a sign key passphrase is needed, type a Sign Key Passphrase and re-type it to verify it.
  21. Click Save.
This adds the new AAA server to the AAA Servers list.
Add any other AccessGates that are configured for the OAM access server to this Oracle Access Manager AAA server. Then, for each AccessGate, configure a virtual server and enable OAM support on it for native integration with OAM.

About OCSP authentication

BIG-IQ Centralized Management supports authenticating a client using Online Certificate Status Protocol (OCSP). OCSP is a mechanism used to retrieve the revocation status of an X.509 certificate by sending machine or user certificate information to a remote OCSP responder. This responder maintains up-to-date information about the certificate's revocation status. OCSP ensures that the BIG-IQ system always obtains real-time revocation status during the certificate verification process.

Configure an OCSP responder

You create an OCSP responder for AAA authentication when you want to obtain revocation status for a user or machine certificate as part of your access control strategy.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click OCSP Responder .
  5. From either OCSP Responder (Shared) or OCSP Responder (Device-Specific), click Create.
    The New OCSP Responder screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific OCSP Responder server.
  8. From the Configuration list, select Basic or Advanced.
  9. In the URL field, type the URL used to contact the OCSP service on the responder.
    You can skip this step if you did not select the Ignore AIA check box and all users have certificates with the correct AIA structure. (The Ignore AIA option is available when you select Advanced from the Configuration list; it is disabled by default.)
  10. Optional: From the Certificate Authority File list, select an SSL certificate.
  11. If you selected Advanced from the Configuration list, do the following steps.
  12. From the Verify Other list, select the name of the file to use to search for an OCSP response signing certificate when the certificate has been omitted from the response.
  13. From the VA File list, select the name of the file that contains explicitly-trusted responder certificates.
    This parameter is required in the event that the responder is not covered by the certificates already loaded into the responder's CA store.
  14. From the Signer list, select the name of the certificate used to sign an OCSP request and then from the Sign Key list, select the key used to sign an OCSP request, and, in the Sign Key Pass Phrase and Verify Sign Key Pass Phrase fields, type the key used to sign an OCSP request.
    If you specify a certificate, but not a key, the system reads the private key from the same file as the certificate. However, if you specify neither the certificate nor the key, then the request is not signed. Lastly, if you do not specify the certificate and you specify the key, then the configuration is considered to be invalid.
  15. From the CertID Digest list select an algorithm to use to convert the client certificate and its issuer certificate to an OCSP cert ID.
    The cert ID is added to the OCSP request.
  16. Click Save.
  17. In the Validity Period field, type the number of seconds for the BIG-IP system to use in specifying an acceptable error range.
    The BIG-IP system uses this setting when the OCSP responder clock and a client clock are not synchronized to prevent a certificate status check from failing.
  18. In the Status Age field, type the number of seconds to compare to the notBefore field of a status response.
    The system uses this parameter when the status response does not include the notAfter field.
  19. To save your changes, click the Save & Close button at the bottom of the screen.
This adds the new OCSP responder to the OCSP list.
You can select this OCSP responder from an OCSP Auth access policy item.

About CRLDP authentication

BIG-IQ Centralized Management supports retrieving Certificate Revocation Lists (CRLs) from network locations (distribution points). A Certificate Revocation List Distribution Point (CRLDP) AAA server defines how to access a CRL file from a distribution point. A distribution point is either an LDAP Uniform Resource Identifier (URI), a directory path that identifies the location where the CRLs are published, or a fully qualified HTTP URL.

Configure a CRLDP AAA server

You create a CRLDP server for AAA authentication to determine how to access certificate revocation lists (CRLs).
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click CRLDP.
  5. From either CRLDP (Shared) or CRLDP (Device-Specific), click Create.
    The New CRLDP screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific CRLDP server.
  8. For the Server Connection setting, select one of these options:
    • Select Use Pool to set up high availability for the AAA server.
    • Select Direct to set up the AAA server for standalone functionality.
    • Select No Server to use a fully qualified HTTP URL as the CRL location.
      Note: The ®BIG-IP system uses the URI from the user's certificate.
    Note: When you select No Server, the screen updates to omit the fields that are not necessary, such as Server Addresses, Server Port, and so on.
  9. If you selected Use Pool, type a name in the Server Pool Name field.
    You create a pool of servers on this screen.
  10. Provide the addresses required for your server connection:
    • If you selected Direct, type an IP address in the Server Address field.
    • If you selected Use Pool, for each pool member you want to add, type an IP address in the Server Addresses field and click Add.
      Note: When you configure a pool, you have the option to type the server address in route domain format: IPAddress%RouteDomain .
  11. If you selected Use Pool, you have the option to select a Server Pool Monitor to track the health of the server pool.
  12. If you specified Use Pool or Direct for the server connection, the Base DN field displays; type a CRLDP base distinguished name into it.
    This setting applies for certificates that specify the CRL distribution point in directory name (dirName) format. Access Policy Manager® uses the Base DN when the value of the X509v3 attribute, crlDistributionPoints, is of type dirName. In this case, Access Policy Manager tries to match the value of the crlDistributionPoints attribute to the Base DN value. An example of a Base DN value is cn=lxxx,dc=f5,dc=com.
    Note: If the client certificate includes the distribution point extension in LDAP URI format, the IP address, Base DN, and Reverse DN settings configured on the agent are ignored; they are specific to directory-based CRLDP. All other settings are applicable to both LDAP URI and directory-based CRL DPs.
  13. Click Save.
This adds the new CRLDP server to the CRLDP Servers list.
A CRLDP AAA server is available for use in a CRLDP Auth agent in an access policy.

About TACACS+ authentication

BIG-IQ Centralized Management supports authenticating and authorizing the client against Terminal Access Controller Access Control System (TACACS+) servers. TACACS+ is a mechanism used to encrypt the entire body of the authentication packet. If you use TACACS+ authentication, user credentials are authenticated on a remote TACACS+ server. If you use the TACACS+ Accounting feature, the accounting service sends start and stop accounting records to the remote server.

The Access feature of BIG-IQ supports TACACS+ authentication with the TACACS+ Auth access policy item and supports TACACS+ accounting with the TACACS+ Acct access policy item.

Note: The BIG-IQ system must include a TACACS+ server configuration for every TACACS+ server that exists.

Configure a TACACS+ AAA server

You create a TACACS+ AAA server to authenticate user credentials on a remote TACACS+ server.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click TACACS+.
  5. From either TACACS+ (Shared) or TACACS+ (Device-Specific), click Create.
    The New TACACS+ screen displays
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device. This only displays when you create a device-specific TACACS+ server.
  8. For the Server Connection setting, select one of these options:
    • Select Use Pool to set up high availability for the AAA server.
    • Select Direct to set up the AAA server for standalone functionality.
  9. If you selected Use Pool, type a name in the Server Pool Name field.
    You create a pool of servers on this screen.
  10. Provide the addresses required for your server connection:
    • If you selected Direct, type an IP address in the Server Address field.
    • If you selected Use Pool, for each pool member you want to add, type an IP address in the Server Addresses field and click Add.
      Note: When you configure a pool, you have the option to type the server address in route domain format: IPAddress%RouteDomain .
  11. If you selected Use Pool, you have the option to select a Server Pool Monitor to track the health of the server pool.
  12. In the Service Port field, type a TACACS+ service port or select one from the list. The default is 49.
  13. In the Secret field, type a secret key to use to encrypt and decrypt packets sent or received from the server, and then re-type the secret key in the Confirm Secret field.
  14. For the Service setting, select the name of the service for the user who is being authenticated to use.
    Identifying the service enables the TACACS+ server to behave differently for different types of authentication requests.
  15. From the Protocol list, select the protocol associated with the value in the Service setting.
  16. From the Privilege Level list, select the level of privilege to request.
  17. From the Authentication Type and Authentication Service lists, select from the provided values.
  18. To save your changes, click the Save & Close button at the bottom of the screen.
This adds the new TACACS+ server to the TACACS+ list.

About Kerberos authentication

BIG-IQ® Centralized Management® provides an alternative to the form-based login authentication method. Instead, an HTTP 401 (unauthorized) or HTTP 407 (proxy authentication required) response triggers a browser login screen to collect credentials.

This option is useful when a user is already logged in to the local domain and you want to avoid submitting an HTTP form for collecting user credentials. The browser automatically submits credentials to the server and bypasses the login box to collect the credentials again.

Note: Because SPNEGO/Kerberos is a request-based authentication feature, the authentication process is different from other authentication methods, which run at session creation time. SPNEGO/Kerberos authentication can occur at any time during the session.

The benefits of this feature include:

  • Provides flexible login mechanism instead of restricting you to use only the form-based login method.
  • Eliminates the need for domain users to explicitly type login information again to log in to BIG-IQ.
  • Eliminates the need for user password transmission with Kerberos method.
Important: Administrators should not turn off the KeepAlive setting on the web server because turning that setting off might interfere with Kerberos authentication.

Configure a Kerberos AAA server

Configure a Kerberos AAA server so that you can add it to a Kerberos authentication action in an access policy.

.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click Kerberos.
  5. Click Create.
    The New Kerberos screen opens.
  6. In the Name field, type a unique name for the authentication server.
  7. From Device, select the associated BIG-IP device.
  8. In the Auth Realm field, type a Kerberos authentication realm name (administrative name), such as LAB.COMANYNET.
    Type the realm name all uppercase; it is case-sensitive.
  9. In the Service Name field, type a service name; for example, HTTP.
  10. In the File name area, click Choose File to locate and upload a keytab file.
    A keytab file contains Kerberos encryption keys (these are derived from the Kerberos password).
  11. To save your changes, click the Save & Close button at the bottom of the screen.
The new AAA server displays on the Kerberos list.

About SSO profiles

SAML 2.0 in BIG-IQ® Centralized Management® specifies an SSO profile that involves exchanging information among an identity provider (IdP), a service provider (SP), and a user. The IdP can be any SSO service offering SAML authentication services

Configure an SSO profile

Configure an SSO profile to configure the BIG-IQ system for single sign-on.

.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Single Sign-On and click SSO Profiles.
  5. Click Create.
    The New Profile screen opens.
  6. In the Name field, type a name for this SSO profile. You cannot change the name if you are editing an exising profile.
  7. From the Scope list, select the scope that is applicable for this SSO profile.
  8. From the SSO Configuration list, select an existing SSO configuration.
  9. Under Log Settings, move log settings from the Available list to the Active list.
  10. To save your changes, click the Save & Close button at the bottom of the screen.
The new SSO profile displays.

Configure BIG-IQ for device posture checks with endpoint management systems

When you check the device posture of a mobile device from your endpoint management system, before allowing access to the corporate network, you can configure BIG-IQ Centralized Management to verify the mobile device posture. The verification comes from the endpoint management system before allowing access from the access policy. An endpoint management system also controls the corporate data on mobile devices. Edge Client establishes a VPN connection with BIG-IP® APM® and an endpoint management system (Airwatch, Maas360, or Microsoft Intune ) manages and sends device details to APM.

Configure an endpoint management system

You can create an endpoint management system on BIG-IP APM with either Airwatch, MaaS360, or Microsoft Intune.
An endpoint system management system connector object on BIG-IQ Centralized Managemetn is an object that stores information about the device management server, such as IP addresses and API credentials. You can configure more than one endpoint management system profile on the same system.
  1. Log in to the BIG-IQ system with your user name and password.
  2. At the top of the screen, select Configuration, then on the left side of the screen, click ACCESS > Access Groups .
  3. Click the name of the Access group that interests you.
    A new screen displays the group's properties.
  4. Expand Authentication and click Endpoint Management Systems.
  5. From either Endpoint Management Systems (Shared) or Endpoint Management Systems (Device-Specific), click Create.
    The New Endpoint Management Systems screen opens.
  6. For Name, type the name for the endpoint management system. You cannot change the name if you are editing an existing configuration.
  7. For Type, select AirWatch,IBM Maas360, or Microsoft Intune.
  8. From Server SSL Profile, select a profile.
  9. For Update Interval (minutes) type a number.
    This is the number of minutes between the start of periodic polling that APM performs to obtain enrollment and compliance information from the endpoint management system.

To set up API credentials for an Airwatch endpoint management system, do these steps.

  1. In the Username and Password fields, type the user name for the administrator of the endpoint management system and the password that the administrator uses to log in.
  2. For API Token, type the API token of the application.

To set up API credentials for an IBM Mass360 endpoint management system, do these steps.

  1. In the Username and Password fields, type the user name for the administrator of the endpoint management system and the password that the administrator uses to log in.
  2. For Billing ID, type the billing ID for the user's IBM Maas360 account.
  3. For Application ID, type the application ID that you got from IBM Maas360.
  4. For Access Key, type the access key that you got from IBM Maas360.
  5. For Platform, type the platform version of the IBM Maas360 console.
  6. For App Version, type the current version number of the application that corresponds to the account.

To set up API credentials for a Microsoft Intune endpoint management system, do these steps.

  1. For Tenant Id, type the tenant ID that comes with a Microsoft Intune subscription, the domain name for the logon name.
  2. For Client Id, type the client ID that becomes available after creating a web application
  3. For Client Secret, type the client secret that becomes available after creating a web application.
  4. To save your changes, click the Save & Close button at the bottom of the screen.
You have configured an endpoint management system.