F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP Access Policy Manager: Privileged User Access
  3. Securing Privileged User Access
Manual Chapter : Securing Privileged User Access

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
Manual Chapter

Securing Privileged User Access

Overview: Using ephemeral authentication to secure privileged user access

Security breaches are a constant threat to companies, government agencies, information systems, and all organizations accessible from the Internet. These breaches can result in the unauthorized access of data, applications, services, networks, and devices. Malicious actors persistently attack by circumventing the security mechanisms particularly those in place for privileged users, such as system and network administrators. As a result, traditional user name and password access to administrative resources is a major security vulnerability in our networks today.
Access Policy Manager (APM) provides Privileged User Access so that you can add CAC authentication (Common Access Card), Personal Identity Verification (PIV), or other strong authentication method to network infrastructure for enhanced security. This solution integrates directly into DoD PKI systems and works cooperatively with existing RADIUS, TACACS, Active Directory, and a variety of third-party authentication databases.
Deployment of Privileged User Access requires a license and involves the configuration of an Ephemeral Authentication server. In addition, using iRule iLX components are needed to deploy a WebSSH proxy and a RADIUS and LDAP virtual server.
Professional Services has developed a script that configures many of the components needed for Privileged User Access. F5 highly recommends using the script. Contact Professional Services for details about acquiring the script and additional documentation.
This example describes only the APM configuration in case you want to change the settings applied by the script. The script does most of the work.

About ephemeral authentication

The Privileged User Access licence lets you create an
Ephemeral Authentication server
 that generates and manages temporary or ephemeral passwords. Access Policy Manager (APM) acts as the Ephemeral Authentication server to ensure a secure end-to-end encrypted connection while eliminating the possibility of credential reuse. The Ephemeral Authentication server includes the access profile/policy that authenticates the end user and contains the webtop resources for ephemeral authentication (so the server also acts as a
webtop proxy
).
The Ephemeral Authentication server can also extend APM Single Sign On (SSO) functionality to forward ephemeral passwords while clients are accessing a resource.
Ephemeral authentication uses a temporary password that may authenticate using only a username and password. The technology exists on the BIG-IP system working with APM to provide a secure end-to-end connection. The BIG-IP system becomes an authentication server for legacy systems.
The administrator or client never sees the ephemeral password. This allows APM to provide multi-factor authentication or CAC to any system including those which require a user name and password for authentication.

Ephemeral authentication workflow

Here is an example of how ephemeral authentication works if you choose to have the BIG-IP system authenticate users with WebSSH.
  1. User logs into the APM virtual server using a Smartcard or other credential. (The APM virtual server is the one that acts as the Ephemeral Authentication server on which the APM access profile/policy is configured.)
  2. The APM access policy checks provided credentials and retrieves AD/LDAP group membership information and returns a webtop showing backend resources.
  3. When the user clicks on a resource, APM generates an ephemeral password, and saves the username and password.
  4. Using SSO, APM signs the user on to the WebSSH virtual server with their ephemeral authentication credentials. At this point, portal access could be used instead.
  5. WebSSH makes an SSH connection (or HTTPS) to the router/server still using the ephemeral authentication credentials.
  6. The router makes an authentication request to the RADIUS or LDAP virtual server.
  7. The RADIUS or LDAP virtual server verifies the ephemeral password.
  8. The RADIUS or LDAP virtual server returns a Successful or Failure response.
  9. The SSH (or HTTPS) session is established or denied.

What is an endpoint for privileged user access?

In privileged user access, an
endpoint
 is a resource on the network that the administrator can manage. It is a unique entity and could be any networking device. For example, an administrator may be responsible for remotely managing multiple endpoints, such as a Cisco router and switch. On the BIG-IP system, that endpoint can be identified as a Portal resource, a Webtop link, or a Web SSH resource.

Ephemeral authentication prerequisites

Before you can run the script to implement privileged user access using ephemeral authentication, the BIG-IP system needs to be installed with the following configured:
  • Initial configuration using the Setup utility is complete
  • Access Policy Manager and iRule LX are licensed and provisioned
  • Active Privileged User Access license
  • VLANs configured
  • Self-IP addresses configured
  • From 1 to 4 IP addresses for use by the script

Privileged user access requirements

These elements, required for privileged user access, are automatically created and configured when you run the script provided by Professional Services.
Privileged user access depends upon the following:
  • Virtual servers (Ephemeral Authentication server, WebSSH Proxy virtual server, LDAP[S] virtual server, RADIUS virtual server)
  • Ephemeral Authentication: Authentication Configuration
  • Ephemeral Authentication: Access Configuration
  • Access Configuration associated with the virtual servers
  • If using SSO (Basic Authentication or Form-Based SSO only), Authentication Configuration is associated with the SSO configuration
  • Access profile/policy (the access profile is the one associated with the virtual server serving as the Ephemeral Authentication server)
  • Webtop
  • Portal access
The access profile/policy must include the following:
  • Log on mechanism using Smartcard or other credential
  • Authentication method (for example, Active Directory, LDAP, RADIUS, Federation)
  • Advanced Resource Assign agent
  • Webtop
  • Portal Access and/or Webtop link that represents resources protected with ephemeral passwords.
The webtop is required. Configure Portal Access, Webtop, and Webtop link resources in the Advanced Resource Assign agent.

Creating an Authentication Configuration for ephemeral authentication

Before you set up ephemeral authentication, make sure that basic system configuration is complete including configuring network interfaces, routes, VLANs, self IPs, DNS, and NTP.
You create an ephemeral Authentication Configuration to specify the accepted protocols and ephemeral password usage for privileged user access. If you ran the privileged user access script, the PUA-Auth configuration has already been created, and you do not need to complete this task. You can use the task to understand the Authentication Configuration that was created.
The script also creates an Authentication Configuration for RADIUS Authentication, and sets a RADIUS secret that needs to be entered on the backend systems. Refer to the
Privileged User Access Deployment Guide
.
  1. On the Main tab, click
    Access
    Ephemeral Authentication
    Authentication Configuration
    .
  2. Click
    Create
    .
  3. For
    Name
    , type a name for the ephemeral authentication configuration.
  4. From the
    Authentication Method
     list, select the authentication method or methods (LDAP, RADIUS, or both) to use for ephemeral authentication.
    Enable only one authentication type (LDAP or RADIUS) if associating this Authentication Configuration with an SSO configuration (HTTP Basic or Form Based supported).
  5. Select
    One Time Only
     to enable one-time authentication using the ephemeral password.
    If not selected, the ephemeral password can be used multiple times until it expires.
  6. For
    Expiration in Minutes
    , type the number of minutes after which the ephemeral password expires.
  7. Click
    Save
    .
Access Policy Manager creates an Authentication Configuration and adds it to the list. You can use this in one or more Access Configurations or in an SSO configuration (HTTP Basic or Form Based supported).
Next, you need an Access Configuration for ephemeral authentication.

Creating an Access Configuration for ephemeral authentication

Before you set up an Access Configuration, you need to have created an Authentication Configuration.
You create an ephemeral authentication Access Configuration to specify the generic password settings for privileged user access. If you ran the privileged user access script, this configuration has already been created, and you do not need to complete this task. You can use it to understand what was created.
  1. On the Main tab, click
    Access
    Ephemeral Authentication
    Access Configuration
    .
  2. Click
    Create
    .
  3. For
    Name
    , type a name for the ephemeral authentication Access Configuration.
  4. If using LDAP on the backend, for
    User LDAP DN
    , type the session variable or name (in distinguished name or DN format) that represents the username of the user who initiated the LDAP authentication request; for example,
    %{session.ldap.last.attr.dn}
    .
    If specifying a session variable, the access policy needs to ensure that the variable is set using either an LDAP Query variable or Variable Assign agent.
    When the LDAP virtual server receives an LDAP authorization request, the username is in DN format (for example: CN=myuser, OU=marketing, DC=mydomain, DC=com). For verification to succeed, the username must be in DN format so it can be associated with the ephemeral password.
    This field is required (1) when the associated Authentication Configuration uses LDAP; (2) when an Authentication Configuration that uses LDAP is associated with an SSO configuration in an access policy; or (3) when an Authentication Configuration that uses LDAP is associated with an SSO configuration as part of portal access in an access policy.
  5. For
    Authentication Configuration
    , select the name of the Authentication Configuration that defines password usage and authentication protocol.
  6. Define the ephemeral password settings for the system.
    1. For
      Minimum Length
      , type the minimum number of characters that are required in a password (no less than 8 characters).
    2. For
      Maximum Length
      , type the maximum number of characters that are required in a password (up to 32 characters).
    3. For
      Minimum Digits
      , type the minimum number of numbers that are required in a password.
    4. For
      Minimum Special Characters
      , type the minimum number of special characters that are required in a password.
    5. For
      Special Characters
      , specify the special characters that are permitted in a password. Not required if Minimum Special Characters is 0. Allowed special characters:
      ~`!@#$%^&*()_-+={}[]:;"<>',.?/|\
    6. For
      Minimum Uppercase Characters
      , type the minimum number of uppercase characters that are required in a password.
    7. For
      Minimum Lowercase Characters
      , type the minimum number of uppercase characters that are required in a password.
    The system uses these settings when developing ephemeral passwords. No one sees these passwords.
  7. Click
    Save
    .
Access Policy Manager creates an Access Configuration and adds it to the list. You need to associate the same Access Configuration with the virtual server acting as the Ephemeral Authentication server, and the RADIUS and/or LDAP virtual server. For example, the script creates four virtual servers to support ephemeral authentication and assigns the same Access Configuration to all of them.
Next, associate the ephemeral authentication Access Configuration with the virtual servers that enforce privileged user access. Also, if using LDAP on the backend system, additional configuration is required as described in the
Privileged User Access Deployment Guide
.

Linking ephemeral authentication with an SSO configuration

The Ephemeral Authentication server can extend APM Single Sign On (SSO) functionality to forward ephemeral passwords while clients are accessing a resource. The script creates an HTTP Basic SSO Configuration called
basic_ephemeral
 and associates the Authentication Configuration
PUA-Auth
with it. Ephemeral authentication also supports Form Based SSO configuration.
This task explains how to link an ephemeral Authentication Configuration with an HTTP Basic SSO configuration. You only need to do this if portal access resources need to override the Authentication Configuration specified in the Ephemeral Authentication: Access Configuration.
  1. On the Main tab, click
    Access
    Single Sign-On
    HTTP Basic
    .
    The HTTP Basic screen opens.
  2. Click the name of the SSO configuration for which you want to specify a unique ephemeral authentication (for example, basic_ephemeral).
  3. In the Ephemeral Authentication area, for
    Authentication Configuration
    , select the configuration to override the one specified in the Access Configuration.
    The script specifies PUA-Auth in this field by default, but you can change this if needed to support portal access resources.
  4. Click
    Update
    .
The Authentication Configuration you selected is associated with this SSO configuration.

Associating an Ephemeral Access Configuration with virtual servers

Before you begin, you need to have created the Ephemeral Access Configuration that you want to associate with a virtual server for privileged user access.
The Privileged User Authentication script provided by Professional Services creates four virtual servers and associates an Access Configuration with each of them. The virtual servers provide the following services:
  • LDAP proxy for the LDAP Ephemeral Authentication Service on port 389
  • LDAPS proxy for the Secure LDAP (SSL) Ephemeral Authentication Service on port 636
  • RADIUS proxy for the RADIUS Ephemeral Authentication Service on port 1812
  • Ephemeral Authentication Server on port 443 (This server includes the access profile/policy that contains the AAA agent to authenticate the end user and the webtop resources for ephemeral authentication.)
This task describes the settings in the virtual servers that are required for ephemeral authentication.
  1. On the Main tab, click
    Local Traffic
    Virtual Servers
    .
    The Virtual Server List screen opens.
  2. Click the name of the virtual server you want to modify.
  3. The
    Source Address
    ,
    Destination Address
    , and
    Service Port
     fields are required and are already specified in the virtual servers created.
    All four virtual servers can use the same Destination Address as long as they use different service ports.
  4. The LDAPS and Webtop proxies are configured with default client SSL profiles in the SSL Profile (Client).
    After testing, you should change them to use legitimate certificates.
  5. Source Address Translation
     is set to
    Auto Map
    .
    If using a WebSSH proxy, it may not work with SNAT. If you change this option be sure to institute a selective disable option (iRule) when connecting to the WebSSH proxy as a portal resource.
  6. If you are creating an Ephemeral Authentication virtual server to use with portal access resources in addition to remote desktops, from the
    Rewrite Profile
     list, select the default
    rewrite
     profile, or another rewrite profile you created.
  7. In the Access Policy area, the Privileged User Access Webtop virtual server specifies an
    Access Profile
     (pua) and
    Connectivity Profile
     (pua-connectivity).
    You will need to build the pua access profile to support the webtop.
  8. In the Ephemeral Authentication area,
    Access Configuration
     specifies PUA-Access (created by the script), or select the name of the Ephemeral Authentication Access Configuration created for ephemeral authentication.
  9. Click
    Update
    .
The virtual servers are set up for ephemeral authentication.

Missing privileged user access license

If a user attempts to access a virtual server webtop that permits only privileged user access and the BIG-IP system does not have a valid Privileged User Access license, the access policy still provides a logon page seeming to allow the user to log on. In this case, the virtual server specifies an Ephemeral Authentication Access Configuration but it is not valid without a license. Here is the log message that appears in the APM log file /var/log/apm:
Following rule 'Out' from item 'Admin Access' to ending 'Allow'
Next, APM determines that the Privileged User Access license is not installed, and deletes the session. The following log messages can be seen in the log file:
Ephemeral Authentication is denied due to: ephemeral authentication not licensed.
Session deleted (license_limit).

Next steps for ephemeral authentication

After you have configured the BIG-IP system using the privileged user access deployment script, you can test ephemeral authentication using the simple access policy that is created (see figure).
You can examine and edit the policy (named
pua
) to make sure it is suited to your environment. For example, you may want to make changes to the following:
  • Logon page
  • Advanced Resource Assign objects like portal access, webtop links, webtop
  • SSO (HTTP basic is configured; need Form Based?)
  • WebSSH proxy (installed using a separate plugin, if needed)
By consolidating access control for administrators, you can further configure the BIG-IP system to take advantage of additional authentication and control capabilities. You can enforce the use of TLS encryption standards across untrusted networks.
Access Policy Manager supports authentication federation models, SAML, and can facilitate the adoption cloud technology. F5 provides strong authentication for applications, devices, management interfaces, and systems within your environment, in the cloud, or wherever they may reside in the future.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information