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.
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 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? PiotrKerberos 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
OWA 2013 SSO - Client initiated form Logout
Hi! I currently have SSO working to log into OWA 2013 via a client-initiated form. I am having an issue with the logout functionality though. Currently when a user presses logout from OWA it loops back into itself and never logs the user out (browser close required to logout). I've used the "Deploying F5 with Microsoft Exchange 2013..." guide to set up the login part. This guide describes the following iRule to terminate inactive APM sessions (which also seems to include a logout feature). when RULE_INIT { set static::cookie_sessionid [format "sessionid=null; path=/; Expires=Thur, 01-Jan-1970 00:00:00 GMT;"] set static::cookie_cadata [format "cadata=null; path=/; Expires=Thur, 01-Jan-1970 00:00:00 GMT;"] set static::cookie_usercontext [format "UserContext=null; path=/; Expires=Thur, 01-Jan-1970 00:00:00 GMT;"] } when ACCESS_SESSION_STARTED { if { [string tolower [HTTP::uri]] contains "ua=0" } { ACCESS::session remove } } when ACCESS_ACL_ALLOWED { set apm_mrhsession [HTTP::cookie value "MRHSession"] if { [table lookup $apm_mrhsession] == "EXCHANGE_LOGOUT" } { ACCESS::session remove table delete $apm_mrhsession } } when HTTP_REQUEST { set isset 0 if {[string tolower [HTTP::uri]] starts_with "/owa" } { if {[string tolower [HTTP::uri]] contains "logoff" } { ACCESS::session remove HTTP::respond 302 Location "https://[HTTP::host]/vdesk/hangup.php3" "Set-Cookie" $static::cookie_sessionid "Set-Cookie" $static::cookie_cadata "Set-Cookie" $static::cookie_usercontext } else { if { [string tolower [HTTP::uri]] contains "ua=0" } { set mrhsession [HTTP::cookie value "MRHSession"] set isset 1 } } } } when HTTP_RESPONSE { if { $isset == 1 } { if { $mrhsession != "" && [HTTP::status] == 440 } { table set $apm_mrhsession "EXCHANGE_LOGOUT" return } } } Currently when a user logs out I see it hit: Which then loops directly back into: What am I missing here? Any tips would be great! ThanksRace Condition in SSO Logon Page
Hey there, I have a big problem with one of our ASPX Web Apps and the F5 SSO. I cant get it to work properly, i have 3 possible outcomes that happen at random and I don't know how to solve this mess... Case1: User types Credentials into Logon Page-> 2 URL Changes and everything works as intended. Case2: User types Credentials into Logon Page-> 2 URL Changes and the User gets a Blank Screen, if he now Refreshes the Page, he will be loged in and it will work fine. Case3: User types Credentials into Logon Page-> 1 URL Change and the User is presented with the ASPX Form. As for my Configuration I mostly took Table15 from https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-sso-config-11-2-0/3.html and changed it to my needs. The JavaScript injection looks as follow(EXTRA): WebForm_DoPostBackWithOptions(new WebForm_DoPostBackWithOptions("LoginVariable","",true,"","",false,false)); __f5form.enctype = 'application/x-www-form-urlencoded'; __f5form.encoding = 'application/x-www-form-urlencoded'; Is there anything I can do to fix this? This Random Race Condition is driving me crazy...
Microsoft Dynamics 365 Portal SSO
Hi Just wondering if anyone here has successfully setup SAML2.0 federation with Microsoft Dynamics 365 Portals? This document doesn't specifically mention F5, but I dont' see why it wouldn't work. https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-saml2-settings I have created the site settings similar to AzureAD and shibboleth Authentication/SAML2/F5/AssertionConsumerServiceUrl - https://samltrialf5.microsoftcrmportals.com/signin-saml2 Authentication/SAML2/F5/AuthenticationType - https://sts.myidp.com.au/idp/portal Authentication/SAML2/F5/Caption - MyIDP SSO Authentication/SAML2/F5/MetadataAddress - https://sts.myidp.com.au/idp/f5 Authentication/SAML2/F5/ServiceProviderRealm - https://samltrialf5.microsoftcrmportals.com/ When I go to the portal site and click sign in, I can see an external account option of "MyIDP SSO". However when I click on the button I get a HTTP 500 error from Microsoft "We're sorry, but something went wrong" The metadataAddress currently doesn't actually contain the federationMetadata file from the F5, so I plan on hosting that using an iFile and updating that site setting to see if that might be causing the issue. I just wanted to see if anyone here had been successful in federating with D365 Portals? Cheers, Simon
