How to Configure BIG-IP F5 for NTLM and SSH?

Part 1: Configuring NTLM Authentication with BIG-IP APM

BIG-IP’s Access Policy Manager (APM) can function as an NTLM SSO authority, bridging domain-joined Windows clients into backend web apps or file shares.

1.1 Prerequisites

• Licensed BIG-IP with LTM and APM provisioned at Nominal or Full.
• Network reachability to Active Directory domain controllers (TCP/UDP 389/636, 88).
• A service account in AD with permissions to create and manage computer accounts.
• Clients must be joined to the same AD domain you configure in APM.

1.2 Join BIG-IP to the AD Domain (Machine Account)

1. Log in to the BIG-IP GUI as admin.
2. Navigate to Access → Authentication → NTLM → Machine Account.
3. Click Create, then enter:
   • Name: e.g. ntlm-machine.
   • Domain FQDN: corp.example.com.
   • Domain Controller FQDN: e.g. dc01.corp.example.com.
   • Admin User/Password: credentials of your AD service account.
4. Click Join. After a moment, the NetBIOS Domain Name should auto-populate and APM will create a computer account in AD.

1.3 Create an NTLM Authentication Configuration

1. Go to Access → Authentication → NTLM → NTLM Auth Configuration.
2. Click Create and specify:
   • Name: e.g. ntlm-auth.
   • Machine Account Name: select your ntlm-machine.
   • Domain Controllers: add one or more FQDNs for redundancy.
3. Click Finished.

This tells APM which DCs to contact when performing NTLM handshakes.

1.4 Configure NTLM SSO for Web Applications

1. Navigate to Access → Single Sign-On → NTLM/Kerberos → NTLM SSO.
2. Click Create and enter:
   • Name: ntlm-sso.
   • NTLM Auth Config: select ntlm-auth.
   • NTLM SSO Type: choose Domain Name or Workstation Name (Domain Name for browser-based).
3. Define any URL or Hostname patterns if you want to restrict which sites use NTLM.
4. Save the profile.

1.5 Build an Access Policy

1. Go to Access → Profiles/Policies → Access Profiles and Create a new profile (type: Web Access, Portal Access, or Native Web).
2. Edit the Access Policy:
   • Start with an AD Auth or Logon Page item if you need a fallback.
   • Insert an NTLM Auth item and bind your ntlm-auth configuration.
   • Insert an SSO Credential Mapping item pointing to ntlm-sso.
3. Save and Publish the policy.

1.6 Associate with a Virtual Server

1. In Local Traffic → Virtual Servers, create or edit your web VIP.
2. Under Access Policy, select your newly created Access Profile.
3. Optionally assign HTTP profiles (e.g., http, http-redirect).
4. Apply changes and test:
   • From a domain-joined Windows client using IE or Edge, browse to the VIP.
   • If all is correct, the browser will seamlessly negotiate NTLM and present you as an authenticated user to the backend.

Part 2: Setting Up BIG-IP as an SSH Jump Server

By extending APM’s Portal Access and WebSSH features, BIG-IP can proxy SSH connections—effectively acting as a bastion or jump host.

2.1 Prerequisites

• BIG-IP licensed & provisioned for LTM, APM, and iRules LX (for advanced scripting).
• WebSSH package installed on BIG-IP (version 13.x+).
• Internal SSH servers reachable from the BIG-IP data VLAN.
• Authentication backend (LDAP/RADIUS/SAML) configured in APM, or Smart-Card/CAC PKI if required.

2.2 Create Portal Access List

1. Navigate to Access → Connectivity/VPN → Portal Access.
2. Click Portal Access List, then Create.
3. Name: e.g. ssh-jump-portal.
4. Virtual Server: select or create an APM-terminated VIP (e.g., ssh-jump-vip:443).
5. Portals:
   • Type: Webtop (browser portal).
   • Resource Type: WebSSH.
   • Name: SSH-Console.
   • Connection Information: hostname/IP and port of the internal SSH server.
6. Save and Apply.

2.3 Build an Access Policy for SSH

1. Under Access → Profiles/Policies → Access Profiles, Create or Edit your SSH portal profile.
2. In the Access Policy editor:
   • Logon Page or LDAP Auth for primary user authentication.
   • Multi-Factor Auth (optional).
   • Branch item to direct traffic to the ssh-jump-portal Webtop on success.
   • Allow the WebSSH download and proxy.
3. Save and Publish your policy.

2.4 Enable WebSSH Client

• Ensure WebSSH is installed:

tmsh show sys software

• If missing, install via F5 support mirror or iControl REST.
• On your ssh-jump-vip, under HTTP Profile, confirm that WebSSH is enabled in the HTML/UA passthrough settings.

When a user connects to https://ssh-jump.example.com in a browser:

• They authenticate via the APM policy.
• They land on a Webtop showing the SSH-Console resource.
• Clicking it launches an in-browser SSH terminal (WebSSH) to the internal host—no client install needed.

2.5 Advanced: Smart-Card Authentication & iRules LX

For FIPS-level strong authentication and audit logging:

1. Configure Smart-Card authentication under Access → Authentication → Remote-ClientCert.
2. Import your PKI CA and CRLs, and bind certificates to APM login.
3. Use an iRule LX to inject SSH session logging headers or implement per-user authorization.
4. Monitor logs in /var/log/apm and via Analytics to audit SSH sessions.

Best Practices & Troubleshooting

• Clock Skew: NTLM and Smart-Card auth depend on time sync—ensure NTP is configured and accurate.
• DNS Reliability: Both NTLM machine-account joins and SSH jump host lookups rely on DNS—use redundant resolvers.
• Session Timeout: Define inactivity timeouts in your APM access profile to drop orphaned SSH sessions.
• High Availability: In HA pairs, sync your Machine Account and Access Policy configurations, and ensure Smart-Card middleware is installed identically on both units.
• Client Compatibility: NTLM SSO works best with Internet Explorer/Edge and Chrome on Windows; Firefox may require explicit security zone settings.
• WebSSH Performance: Web-based SSH can lag under high latency—consider TCP optimization profiles or using the native SSH proxy method (iRules LX) for heavier use

Please follow and like us: