Bypass Azure Login Page with OAuth login_hint on F5 BIG-IP APM
Overview This article demonstrates how to enhance the user experience between F5 BIG-IP APM (OAuth Client) and Azure AD (OAuth Authorization Server) by implementing the login_hint parameter. This approach eliminates the need for users to enter their credentials twice, once on the F5 login page and again on the Azure login page. Problem Statement When users access applications protected by F5 APM that authenticate against Azure AD using OAuth/OIDC, they often encounter a suboptimal experience: User enters credentials on the F5 login page (often using their familiar sAMAccountName) F5 redirects to Azure AD for OAuth authentication Azure AD presents another login page asking for the same credentials (expecting UPN/email format) This creates additional friction because users may not know their User Principal Name (UPN) and typically use their sAMAccountName for domain authentication. The login_hint parameter solves this by allowing F5 APM to translate the user's sAMAccountName to their UPN and pre-populate the Azure login page, effectively bypassing the redundant login prompt. Alternative approach The same functionality can be achieved using SAML, as described here. However, I find the OAuth approach cleaner, as it eliminates the need for an iRule and also allows you to include the prompt parameter. This can be useful when you want to force authentication in Azure instead of relying on an existing session. See herefor details. Prerequisites F5 BIG-IP with APM Azure AD tenant with application registration Basic OAuth/OIDC configuration between F5 and Azure AD (as outlined in https://my.f5.com/manage/s/article/K53313351) Implementation Steps Step 1: Complete Basic OAuth Setup Follow the standard F5 APM OAuth configuration with Azure AD: Configure OAuth Server Object Navigate to Access ›› Federation ›› OAuth Client/Resource Server ›› OAuth Server Create a new OAuth server configuration for Azure AD Set the provider type to "Microsoft Identity Platform 2.0" Configure Access Profile Create an access profile with OAuth Client agent Configure authentication redirect and token requests Step 2: Create Custom Authentication Redirect Request The key modification involves creating a custom authentication redirect request that includes the login_hint parameter: Navigate to Request Configuration Access ›› Federation ›› OAuth Client/Resource Server ›› Request Clone the Default Request Find the existing /Common/MSIdentityPlatform2.0AuthRedirectRequest Create a copy Name it something descriptive like MSIdentityPlatform2.0AuthRedirectRequest_LoginHint and the same parameters as /Common/MSIdentityPlatform2.0AuthRedirectRequest Add login_hint Parameter Parameter Name: login_hint Parameter Type: custom Parameter Value: %{session.ad.last.attr.userPrincipalName} or any other variable containing user’s UPN based on your environment and Authentication configuration In the Parameters section, click Add Configure the new parameter: Step 3: Update VPE OAuth Configuration Access the Visual Policy Editor Go to Access ›› Profiles/Policies ›› Access Profiles (Per-Session Policies) Edit your access profile Click Edit to open the VPE Modify OAuth Client Agent Locate the OAuth Client agent in your policy Edit the OAuth Client agent properties In the Authentication Redirect Request dropdown, select your new custom request: MSIdentityPlatform2.0AuthRedirectRequest_LoginHint Apply Access Policy Click Apply Access Policy to save changes Step 4: Session Variable Configuration and UPN Translation The key to successful login_hint implementation is ensuring the proper session variable is populated with a UPN-formatted email address. F5 APM can automatically translate sAMAccountName to UPN during AD authentication. Complete Policy Flow Example Start ↓ Logon Page (user enters: DOMAIN\john.doe or john.doe) ↓ AD Auth (authenticate and populate session variables) ↓ AD Query (to fetch user attributes) ↓ OAuth Client (with custom redirect request including login_hint=john.doe@company.com) ↓ Azure AD (pre-populated with UPN, bypasses login prompt) ↓ Application Access Troubleshooting Common Issues login_hint Parameter Not Working Verify the session variable contains a valid email address Check that the custom request is selected in the OAuth Client agent Ensure the parameter type is set to "custom" Session Variable Empty or Wrong Format Verify AD authentication and query occurs before OAuth redirect Check AD attribute mapping configuration Confirm the userPrincipalName attribute exists in your AD schema Ensure domain suffix matches Azure AD tenant domain Azure AD Still Prompts for Login Verify the email format matches Azure AD expectations Check Azure AD application configuration for login_hint support Ensure the user exists in the Azure AD tenant Debugging Tips Enable APM debug logging: tmsh modify sys db log.apm.level value debug Use browser developer tools to inspect the OAuth redirect URL Verify session variables using Variable Assign agents in VPE Security Considerations The login_hint parameter only pre-populates the username field; users still must provide valid credentials This is a user experience enhancement, not a security bypass Ensure session variables don't contain sensitive information beyond the username/email Conclusion Implementing login_hint with OAuth on F5 BIG-IP APM significantly improves user experience by eliminating redundant login prompts. The key advantage is that F5 APM can seamlessly translate users' familiar sAMAccountName credentials to the UPN format required by Azure AD, allowing users to authenticate once with their domain credentials while Azure AD receives the properly formatted UPN for the login_hint. This approach maintains security while providing a seamless user experience, particularly beneficial in environments where: Users are more familiar with their sAMAccountName than their UPN Organizations want to minimize authentication friction Azure itself is also federated to another IDP and you want transparent rederiction The solution leverages F5 APM's AD integration capabilities to handle the username format translation automatically, making it transparent to end users.
Verify your own domain's in Azure with ease
Problem this snippet solves: In case you want to verify your domain ownership in a fast and easy way you can do this with your BIG-IP directly! This example shows it for Azure but the code of course can be modified for other clouds like GCP etc. as well. How to use this snippet: Just simply add a new iRule with following code to your virtual server that serves the corresponding FQDN for the domain to verified. Tested with TMOS 15.x as well. Just take your application ID form Azure from your "Application Registration" and replace the part <AZURE Application (client) ID> with it. What about verifying 1000nds of domains? (googled: azure api call domain verification) https://docs.microsoft.com/en-us/graph/api/domain-verify?view=graph-rest-1.0&tabs=http So, you could easily spin-off virtual servers via API calls for each domain to verify them each automatically with parameters for the corresponding iRule as well. Code : when HTTP_REQUEST { if { [HTTP::uri] contains ".well-known/microsoft-identity-association.json" } { HTTP::respond 200 content { { "associatedApplications": [ { "applicationId": " " } ] } } "Content-Type" "application/json" } } Tested this on version: 13.0IPSec Tunnel Endpoint iApp
Problem this snippet solves: This iAPP template creates a complete configuration for establishing an IPSec tunnel between a Windows Azure virtual network and your F5 protected corporate network. Additionally, this iApp may be utilized for establishing site-2-site VPN between any compatible IPSec device. The BIG-IP supports both policy and route-based VPNs. Contributed by: Gregory Coward, Solution Architect Code : 75380 Tested this on version: 12.0Checksums for F5 Supported Cloud templates on GitHub
Problem this snippet solves: Checksums for F5 supported cloud templates F5 Networks provides checksums for all of our supported Amazon Web Services CloudFormation, Microsoft Azure ARM, Google Deployment Manager, and OpenStack Heat Orchestration templates. See the README files on GitHub for information on individual templates. You can find the templates in the appropriate supported directory on GitHub: Amazon CloudFormation templates: https://github.com/F5Networks/f5-aws-cloudformation/tree/master/supported Microsoft ARM Templates: https://github.com/F5Networks/f5-azure-arm-templates/tree/master/supported Google Templates: https://github.com/F5Networks/f5-google-gdm-templates VMware vCenter Templates: https://github.com/F5Networks/f5-vmware-vcenter-templates OpenStack Heat Orchestration Templates: https://github.com/F5Networks/f5-openstack-hot F5 Ansible Modules: http://docs.ansible.com/ansible/latest/list_of_network_modules.html#f5 Because this page was getting much too long to host all the checksums for all Cloud platforms, we now have individual pages for the checksums: Amazon AWS checksums Microsoft Azure checksums Google Cloud checksums VMware vCenter checksums OpenStack Heat Orchestration checksums F5 Ansible Module checksums Code : You can get a checksum for a particular template by running one of the following commands depending on your operating system: * **Linux**: `sha512sum ` * **Windows using CertUtil**: `CertUtil –hashfile SHA512`
