APM with EntraID as idP / request signed
Hi experts. I need your help to solve an issue. I'm configuring a new enviroment with BIG-IP version 15.1.8.2 Build 0.0.17 Point Release 2. I have the APM works fine with SSO using EntraID (AzureAD) as idP. Now, I need to enable the request signed (Enforce signed SAML authentication requests - Microsoft Entra ID | Microsoft Learn). I generated the self signed certificate and import it on my app at Azure and my BIG-IP. I changed my config in Access > Federation > SAML Identity Provider and assigned my self signed certificate (pk included) to assign the request. But, I've received the below error by EntraID: Sign-in error code: 76021 Failure reason: The request sent by client is not signed while the application requires signed requests All attemps was made by browser (SSL VPN). Thank you.
APM Cookbook: Single Sign On (SSO) using Kerberos
To get the APM Cookbook series moving along, I’ve decided to help out by documenting the common APM solutions I help customers and partners with on a regular basis. Kerberos SSO is nothing new, but seems to stump people who have never used Kerberos before. Getting Kerberos SSO to work with APM is straight forward once you have the Active Directory components configured. Overview I have a pre-configured web service (IIS 7.5/Sharepoint 2010) that is configured for Windows Authentication, which will send a “Negotiate” in the header of the “401 Request for Authorization”. Make sure the web service is configured to send the correct header before starting the APM configuration by accessing the website directly and viewing the headers using browser tools. In my example, I used the Sharepoint 2010/2013 iApp to build the LTM configuration. I’m using a single pool member, sp1.f5.demo (10.10.30.2) listening on HTTP and the Virtual Server listening on HTTPS performing SSL offload. Step 1 - Create a delegation account on your domain 1.1 Open Active Directory Users and Computers administrative tool and create a new user account. User logon name: host/apm-kcd.f5.demo User logon name (pre-Windows 2000): apm-kcd Set the password and not expire 1.2 Alter the account and set the servicePrincipcalName. Run setspn from the command line: setspn –A host/apm-kcd.f5.demo apm-kcd A delegation tab will now be available for this user. Step 2 - Configure the SPN 2.1 Open Active Directory Users and Computers administrative tool and select the user account created in the previous step. Edit the Properties for this user Select the Delegation tab Select: Trust this user for delegation to specified services only Select: Use any authentication protocol Select Add, to add services. Select Users or Computers… Enter the host name, in my example I will be adding HTTP service for sp1.f5.demo (SP1). Select Check Names and OK Select the http Service Type and OK 2.2 Make sure there are no duplicate SPNs and run setspn –x from the command line. Step 3 - Check Forward and Reverse DNS DNS is critical and a missing PTR is common error I find when troubleshooting Kerberos SSO problems. From the BIG-IP command line test forward and reverse records exist for the web service using dig: # dig sp1.f5.demo ;; QUESTION SECTION: ;sp1.f5.demo. IN A ;; ANSWER SECTION: sp1.f5.demo. 1200 IN A 10.10.30.2 # dig -x 10.10.30.2 ;; QUESTION SECTION: ;2.30.10.10.in-addr.arpa. IN PTR ;; ANSWER SECTION: 2.30.10.10.in-addr.arpa. 1200 IN PTR sp1.f5.demo. Step 4 - Create the APM Configuration In this example I will use a Logon Page to capture the user credentials that will be authenticated against Active Directory and mapped to the SSO variables for the Kerberos SSO. 4.1 Configure AAA Server for Authentication Access Policy >> AAA Servers >> Active Directory >> “Create” Supply the following: Name: f5.demo_ad_aaa Domain Name: f5.demo Domain Controller: (Optional – BIG-IP will use DNS to discover if left blank) Admin Name and Password Select “Finished" to save. 4.2 Configure Kerberos SSO Access Policy >> SSO Configurations >> Kerberos >> “Create” Supply the following: Name: f5.demo_kerberos_sso Username Source: session.sso.token.last.username User Realm Source: session.ad.last.actualdomain Kerberos Realm: F5.DEMO Account Name: apm-kcd (from Step 1) Account Password & Confirm Account Password (from Step1) Select “Finished” to save. 4.3 Create an Access Profile and Policy We can now bring it all together using the Visual Policy Editor (VPE). Access Policy >> Access Profiles >> Access Profile List >> “Create” Supply the following: Name: intranet.f5.demo_sso_ap SSO Configuration: f5.demo_kerberos_sso Languages: English (en) Use the default settings for all other settings. Select “Finished” to save. 4.4 Edit the Access Policy in the VPE Access Policy >> Access Profiles >> Access Profile List >> “Edit” (intranet.f5.demo_sso_ap) On the fallback branch after the Start object, add a Logon Page object. Leave the defaults and “Save”. On the fallback branch after the Logon Page object, add an AD Auth object. Select the Server Select “Save” when your done. On the Successful branch after the AD Auth object, add a SSO Credential Mapping object. Leave the defaults and “Save”. On the fallback branch after the SSO Credential Mapping, change Deny ending to Allow. The finished policy should look similar to this: Don't forget to “Apply Access Policy”. Step 5 – Attach the APM Policy to the Virtual Server and Test 5.1 Edit the Virtual Server Local Traffic >> Virtual Servers >> Virtual Server List >> intranet.f5.demo_vs Scroll down to the Access Policy section and select the Access Profile. Select “Update” to save. 5.2 Test Open a browser, access the Virtual Server URL (https://intranet.f5.demo in my example), authenticate and verify the client is automatically logged on (SSO) to the web service. To verify Kerberos SSO has worked correctly, check /var/log/apm on APM by turning on debug. You should see log events similar to the ones below when the BIG-IP has fetched a Kerberos Ticket. info websso.1[9041]: 014d0011:6: 33186a8c: Websso Kerberos authentication for user 'test.user' using config '/Common/f5.demo_kerberos_sso' debug websso.1[9041]: 014d0018:7: sid:33186a8c ctx:0x917e4a0 server address = ::ffff:10.10.30.2 debug websso.1[9041]: 014d0021:7: sid:33186a8c ctx:0x917e4a0 SPN = HTTP/sp1.f5.demo@F5.DEMO debug websso.1[9041]: 014d0023:7: S4U ======> ctx: 33186a8c, sid: 0x917e4a0, user: test.user@F5.DEMO, SPN: HTTP/sp1.f5.demo@F5.DEMO debug websso.1[9041]: 014d0001:7: Getting UCC:test.user@F5.DEMO@F5.DEMO, lifetime:36000 debug websso.1[9041]: 014d0001:7: fetched new TGT, total active TGTs:1 debug websso.1[9041]: 014d0001:7: TGT: client=apm-kcd@F5.DEMO server=krbtgt/F5.DEMO@F5.DEMO expiration=Tue Apr 29 08:33:42 2014 flags=40600000 debug websso.1[9041]: 014d0001:7: TGT expires:1398724422 CC count:0 debug websso.1[9041]: 014d0001:7: Initialized UCC:test.user@F5.DEMO@F5.DEMO, lifetime:36000 kcc:0x92601e8 debug websso.1[9041]: 014d0001:7: UCCmap.size = 1, UCClist.size = 1 debug websso.1[9041]: 014d0001:7: S4U ======> - NO cached S4U2Proxy ticket for user: test.user@F5.DEMO server: HTTP/sp1.f5.demo@F5.DEMO - trying to fetch debug websso.1[9041]: 014d0001:7: S4U ======> - NO cached S4U2Self ticket for user: test.user@F5.DEMO - trying to fetch debug websso.1[9041]: 014d0001:7: S4U ======> - fetched S4U2Self ticket for user: test.user@F5.DEMO debug websso.1[9041]: 014d0001:7: S4U ======> trying to fetch S4U2Proxy ticket for user: test.user@F5.DEMO server: HTTP/sp1.f5.demo@F5.DEMO debug websso.1[9041]: 014d0001:7: S4U ======> fetched S4U2Proxy ticket for user: test.user@F5.DEMO server: HTTP/sp1.f5.demo@F5.DEMO debug websso.1[9041]: 014d0001:7: S4U ======> OK! Conclusion Like I said in the beginning, once you know how Kerberos SSO works with APM, it’s a piece of cake!
OAuth SSO
Hi All, we'd like to secure the access to a backend portal with OAuth (F5 Authorization Server and F5 Client/Ressource Server). We aleady configured 2 Virtual Servers and 2 Access Profiles access profile 1 for the backend application (OAuth Client and Scope Agents) access profile 2 for the OAuth AS (Logon Page, LDAP Auth and OAuth AS Agent) The login and the OAuth (OIDC) works with the backend via id_token. Idea was to ask the user ONCE for his LDAP Credentials and then authorize the user in subsequent authorization requests from client applications WITHOUT asking for entering his credentials again. What we see in the session logs is, that the authorization server session always ends with "session deleted (oauth_finished)" once the authorization request has successfully ended, hence the users LDAP information is destroyed together with the "session deleted" Is it possible to get some kind of SSO so that the users credentials is stored in the client for subsequent authorization requests and that the logon page can make use those credentials without prompting the user to login manually again? Thanks Steffen
APM Portal Links SSO with Azure AD
Hi, We have an APM portal using AD authentication. We recently transitioned to using Azure AD MFA to log into it. This was done by following the solution to integrate APM with Azure AD using the bigIP as a SAML SP and works without issue. However, after logging into the portal and clicking on any of the links for the the various apps (which are also Azure AD integrated) the user must go through the login process with Azure AD all over again which is anyoing. Is there a way to somehow use the original SAML authentication from loging into the portal to seemlessly be logged into the various apps? Interestingly, once the user clicks on subsequent apps after the second login, they are logged in automatically so I believe it's able to use the session tokens stored in the browser for subsequent logins after the second login (but not after the initial log in to the portal).APM Kerberos Auth or fallback to another authentication method
Problem this snippet solves: This iRule can be used when it is required to offer both Kerberos authentication and for example SAML or another authentication method in a mixed environment for devices that are domain joined and devices that are not domain joined. This iRule uses javascript and HTML5 Web Workers to determine if the browser can successfully authenticate by using Kerberos or will need to fallback to another authentication method. I've been testing this iRule with Internet Explorer, Edge, Firefox and Chrome. All these browsers seem to be working fine. Only Chrome seems to do things a bit differently and is showing a login prompt for a split second, but it's working. How to use this snippet: The screenshot below shows an example of an Access Policy that uses either Kerberos or SAML authentication. The first agent in the policy is an 'Empty Agent' which will read the session.custom.domainjoined variable to determine which authentication method to use. The session.custom.domainjoined variable is set by the kerberos_auth_or_fallback_auth iRule. Tested this on version: 13.0 Link to iRule https://github.com/nvansluis/f5.kerberos_auth_or_fallback_authTransparent Kerberos Authentication and APM fallback authentication
Problem this snippet solves: This iRule can be used when it is required to offer both Kerberos authentication (transparent, non-APM) and for example SAML or another APM authentication method in a mixed environment for devices that are domain joined and devices that are not domain joined. This iRule uses javascript and HTML5 Web Workers to determine if the browser can successfully authenticate by using Kerberos or will need to fallback to another authentication method. I've been testing this iRule with Internet Explorer, Edge, Firefox and Chrome. All these browsers seem to be working fine. Only Chrome seems to do things a bit differently and is showing a login prompt for a split second, but it's working. How to use this snippet: Create a Virtual Server that delivers a webserver that uses Kerberos Authentication. Create APM Access Policy that will perform the fallback authentication. Add this iRule to the Virtual Server that holds the APM access policy to perform the fallback authentication. Tested this on version: 13.0 Location of iRule https://github.com/nvansluis/f5.transparent_kerberos_auth_or_apm_authentication
APM, Kerberos and SSO
Hi, I was trying to setup SSO using APM Cookbook: Single Sign On (SSO) using Kerberos article. I am using VE with 12.0.0HF1. I have https vs with one member pool pointing to IIS server (IIS is runing on the same computer as AD). My VS has IP 10.128.10.6, it resolves to interent.f5demo.com (via DNS on AD), there is as well PTR record defined My AD (and KDC) has IP 10.128.10.2, it resolves to ad.f5demo.com, there is as well PTR record defined. On F5 both dig elvis162.f5demo.com and dig -x 10.128.10.2 is resolving correctly (DNS set on F5 is the one running on AD - 10.128.10.2) - here I am getting two names elvis162.f5demo.com and hostmaster.f5demo.com Target pool member in my IIS pool is 10.128.10.2 (IIS on AD computer) Delegation account on AD is set with user logon name host/apm-kcd.f5demo.com and pre-Windows 2000 apm-kcd Delegation is set as on screen below: Everything works OK except after auhenticating via APM Logon page I am getting Windows logon popup. Even if credentials entered there are the same that are working when directly connecting to IIS (on AD computer using elvis162.f5demo.com host) I can't authenticate. Of course main issue is that this second logon should not show up - at least that is my understanding. In APM log (logging set to debug) only error is: Feb 17 12:30:11 bigip11 err websso.1[2037]: 014d0019:3: /Common/intranet.f5demo.com_sso_ap:Common:9ba7de8f: Kerberos: Failed to resolve IP address: ::ffff:10.128.10.2 Feb 17 12:30:11 bigip11 err websso.1[2037]: 014d0048:3: /Common/intranet.f5demo.com_sso_ap:Common:9ba7de8f: failure occurred when processing the work item So what I am doing wrong here? PiotrSubsequent Form Based SSO
Problem this snippet solves: After performing a successful APM Form Based SSO it can happen that the backend website will expire the user session while the APM session is still active. When this happens, the user will see the logon page of the backend website and needs to login again. This code snippet will try to detect that the user is being redirected to the backend website login page and will perform a Form Based SSO again by using the credentials from the active APM session. How to use this snippet: When using this code snippet, make sure you set the below shown variables to match your environment. set static::start_uri set static::form_action You should also use the Variable Assign agent in the VPE to set the APM session variable session.custom.form_based.password with the users password. This password will be used to perform the subsequent Form Based SSO. Use the following custom expression: return [mcget -secure {session.logon.last.password}] . Code : when RULE_INIT { set static::start_uri "login.html" set static::form_action "/F5/form_based_login/login.php" set static::form_html { Your browser does not support JavaScript, press the Continue button once to proceed. } set static::form_html [string map "form_action $static::form_action" $static::form_html] } when HTTP_REQUEST { if { [HTTP::cookie exists MRHSession] and [ACCESS::session exists -state_allow -sid [HTTP::cookie MRHSession]] } { set active_session 1 if { [HTTP::method] equals "POST" && [HTTP::uri] equals $static::form_action } { set collect_length 2048 if { [HTTP::header Content-Length] eq "" } { set collect_length $collect_length } elseif { [HTTP::header Content-Length] == 0 } { unset collect_length } elseif { [HTTP::header Content-Length] > $collect_length } { set collect_length $collect_length } else { set collect_length [HTTP::header Content-Length] } if { [info exists collect_length] } { HTTP::collect $collect_length } } } } when HTTP_REQUEST_DATA { # the session.custom.form_based.password variable needs to be set via a variable assign agent in the VPE. set username [ACCESS::session data get session.logon.last.username] set password [ACCESS::session data get session.custom.form_based.password] HTTP::payload replace 0 [HTTP::payload length] "username=$username&password=$password" } when HTTP_RESPONSE { if { [info exists active_session] } { if { [HTTP::header "Location"] equals $static::start_uri } { if { [ACCESS::session data get session.custom.first_redirect] == 1 } { # this is the subsequent redirect which is not covered by APM Form Based SSO HTTP::respond 200 content $static::form_html } else { # this is the initial redirect which is covered by APM Form Based SSO ACCESS::session data set session.custom.first_redirect 1 } } unset active_session } } Tested this on version: 13.0Kerberos SSO without webtop
Dear Fellows, Is it possible to have a irule for kerberos SSO without webtop similar to SAML SSO without webtop. Do you have an example: SAML SSO without webtop: when ACCESS_POLICY_COMPLETED { switch -glob [ACCESS::session data get session.server.landinguri] { "/mycloudapp*" { ACCESS::respond 302 Location "https://idp.mycompany.com/saml/idp/res?id=/Common/MYCLOUDAPP" } "/proofpoint*" { ACCESS::respond 302 Location "https://idp.mycompany.com/saml/idp/res?id=/Common/PROOFPOINT" } "/businessolver*" { ACCESS::respond 302 Location "https://idp.mycompany.com/saml/idp/res?id=/Common/BUSINESSOLVER" } }
Client-initiated form SSO with international characters
Hi! We are having an issue with Client initiated form SSO that is seems to come from the form containing international characters in the form parameters. In our case Swedish characters åäö in the names of username and password fields. After logging in at the APM logon page, the SSO POST triggers but the user does not get signed in. Looking at what gets sent to the server, the username and password fields seems to be inserted twice in the POST to the application. Expanding the form params in wireshark shows: "username field" = "typed in username" "password field" = f5-sso-token ..other params... "username field" = "typed in username" "password field" = "typed in password" In our case: pAnvändarnamn = testuser pLösenord = f5-sso-token ..other params... pAnvändarnamn = testuser pLösenord = 123456789 We are running 11.6 HF5. Worth mentioning perhaps is that we are trying to apply this to a portal application with full patchning. Searching the forum and ask-f5 knowledge base, I found SOL17489: Form-based client-initiated SSO may fail to process strings with special characters The article does not go into detail what is considered special characters, but I gave it a try and upgraded to 12.0 HF1. Unfortunately the issue persisted. We replicated the behavior with a very simple form that worked right away when having sane username and password parameter names, but stopped working when changed to parameter names as above. I'm thinking if I should open a case regarding this as a potential bug, but just wanted to run the issue by here if anyone has seen this before and might know of a fix? Thanks /Andreas
