Azure Active Directory and BIG-IP APM Integration
Introduction Security is one of the primary considerations for organizations in determining whether or not to migrate applications to the public cloud. The problem for organizations with applications in the cloud, in a data center, managed, or as a service, is to create a cost-effective hybrid architecture that produces secure application access and a great experience that allows users to access apps easily, have consistent user experiences, and enjoy easy access with single-sign-on (SSO) tied to a central identity and authentication strategy. Some applications are not favorable to modernization. There are applications that are not suited for, or incapable of, cloud migration. Many on-premises apps do not support modern authentication and authorization, including standards and protocols such as SAML, OAuth, or OpenID Connect (OIDC). An organization may not have the staff talent or time to perform application modernization for their on-premises apps. With thousands of apps in use daily, hosted in all or any combination of these locations, how can organizations ensure secure, appropriate user access without requiring users to login in multiple times? In addition, how can organizations terminate user access to each application without having to access each app individually? By deploying Microsoft Azure Active Directory, Microsoft’s comprehensive cloud-based identity platform, along with F5’s trusted application access solution, Access Policy Manager (APM), organizations are able to federate user identity, authentication, and authorization and bridge the identity gap between cloud-based (IaaS), SaaS, and on-premises applications. Figure 1Secure hybrid application access This guide discusses the following use cases: ·Users use single sign-on to access applications requires Kerberos-based authentication. ·Users use single sign-on to access applications requires header-based authentication. Microsoft Azure Active Directory and F5 BIG-IP APM Design For organizations with a high security demand with low risk tolerance, the need to keep all aspects of user authentication on premise is required. The Microsoft Azure Active Directory and F5 BIG-IP APM solution integrates directly into AAD configured to work cooperatively with an existing Kerberos based, header based or variety of authentication methods. The solution has these components: •BIG-IP Access Policy Manager (APM) •Microsoft Domain Controller/ Active Directory (AD) •Microsoft Azure Active Directory (AAD) •Application (Kerberos-/header-based authentication) Figure 2APM bridge SAML to Kerberos/header authentication components Figure 3APM bridge SAML to Kerberos authentication process flow Deploying Azure Active Directory and BIG-IP APM integration The joint Microsoft and F5 solution allow legacy applications incapable of supporting modern authentication and authorization to interoperate with Azure Active Directory. Even if an app doesn’t support SAML, and only is able to support header- or Kerberos-based authentication, it can still be enabled with single sign-on (SSO) and support multi-factor authentication (MFA) through the F5 APM and Azure Active Directory combination. Azure Active Directory as an IDaaS delivers a trusted root of identity to APM creating a bridge between modern and legacy applications, delivering SSO and securing the app with MFA. Adding F5 from the gallery To configure the integration of BIG-IP APM into Azure AD, you need to add F5 from the gallery to your list of managed SaaS apps. Sign-on to theAzure portalusing either a work or school account, or a personal Microsoft account. On the left navigation pane, select theAzure Active Directoryservice. Navigate toEnterprise Applicationsand then selectAll Applications. To add new application, selectNew application. In theAdd from the gallerysection, typeF5in the search box. SelectF5from results panel and then add the app. Wait a few seconds while the app is added to your tenant. Configuring Microsoft Azure Active Directory Configure and test Azure AD SSO with F5 using a test user calledA.Vandelay. For SSO to work, you need to establish a link relationship between an Azure AD user and the related user in F5. To configure and test Azure AD SSO with F5, complete the following building blocks: Configure Azure AD SSO - to enable your users to use this feature. Create an Azure AD test user - to test Azure AD single sign-on with A.Vandelay. Assign the Azure AD test user - to enable A.Vandelay to use Azure AD single sign-on. Configure Azure AD SSO Follow these steps to enable Azure AD SSO in the Azure portal. In theAzure portal, on theF5application integration page, find theManagesection and selectsingle sign-on. On theSelect a single sign-on methodpage, selectSAML. On theSet up single sign-on with SAMLpage, click the edit/pen icon forBasic SAML Configurationto edit the settings. On theBasic SAML Configurationsection, if you wish to configure the application inIDPinitiated mode, enter the values for the following fields: In theIdentifiertext box, type a URL using the following pattern:https://<YourCustomFQDN>.f5.com/ In theReply URLtext box, type a URL using the following pattern:https://<YourCustomFQDN>.f5.com/ ClickSet additional URLsand perform the following step if you wish to configure the application inSPinitiated mode: In theSign-on URLtext box, type a URL using the following pattern:https://<YourCustomFQDN>.f5.com/ Note These values are for only used for illustration. Replace these them with the actual Identifier, Reply URL and Sign-on URL. Refer to the patterns shown in theBasic SAML Configurationsection in the Azure portal. On theSet up single sign-on with SAMLpage, in theSAML Signing Certificatesection, findFederation Metadata XMLand selectDownloadto download the certificate and save it on your computer. On theSet up F5section, copy the appropriate URL(s) based on your requirement. Create an Azure AD test user In this section, you'll create a test user in the Azure portal called A.Vandelay. From the left pane in the Azure portal, selectAzure Active Directory, selectUsers, and then selectAll users. SelectNew userat the top of the screen. In theUserproperties, follow these steps: In theNamefield, enterA.Vandelay. In theUser namefield, enter the username@companydomain.extension. For example,A.Vandelay@contoso.com. Select theShow passwordcheck box, and then write down the value that's displayed in thePasswordbox. ClickCreate. Assign the Azure AD test user In this section, you'll enable A.Vandelay to use Azure single sign-on by granting access to F5. In the Azure portal, selectEnterprise Applications, and then selectAll applications. In the applications list, selectF5. In the app's overview page, find theManagesection and selectUsers and groups. SelectAdd user, then selectUsers and groupsin theAdd Assignmentdialog. In theUsers and groupsdialog, selectA.Vandelayfrom the Users list, then click theSelectbutton at the bottom of the screen. If you're expecting any role value in the SAML assertion, in theSelect Roledialog, select the appropriate role for the user from the list and then click theSelectbutton at the bottom of the screen. In theAdd Assignmentdialog, click theAssignbutton. Configure F5 BIG-IP APM Configure your on-premise applications based on the authentication type. Configure F5 single sign-on for Kerberos-based application Open your browser and access BIG-IP. You need to import the Metadata Certificate into the F5 (Kerberos) which will be used later in the setup process. Go toSystem > Certificate Management > Traffic Certificate Management >> SSL Certificate List. Click onImportof the right-hand corner. Additionally you also need anSSL Certificatefor the Hostname (Kerbapp.superdemo.live), in this example we used Wildcard Certificate. Go to –F5 BIG-IP Click Access > Guided Configuration > Federation > SAML Service Provider. Specify theEntity ID(same as what you configured on the Azure AD Application Configuration). Create a new Virtual Server, Specify theDestination Address. Choose theWild Card Certificate(orCertyou uploaded for the Application) that we uploaded earlier and theAssociated Private Key. Upload the ConfigurationMetadataand Specify a newName for SAML IDP Connectorand you will also need to specify the Federation Certificate that was uploaded earlier. Create NewBackend App Pool, specify theIP Address(s)of the Backend Application Servers. UnderSingle Sign-on Settings, chooseKerberosand SelectAdvanced Settings. The request needs to be created inuser@domain.suffix. Under theusername sourcespecifysession.saml.last.attr.name.http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname. Refer Appendix for complete list of variables and values. Account Name Is the F5 Delegation Account Created ( Check F5 Documentation). Under Endpoint Checks Properties , click Save & Next. Under Timeout Settings, leave default settings and click Save & Next. Review Summaryand click onDeploy. Configure F5 single sign-on for Header-based application Open your browser and access BIG-IP. You need to import the Metadata Certificate into the F5 (Header Based) which will be used later in the setup process. Go toSystem > Certificate Management > Traffic Certificate Management >> SSL Certificate List. Click onImportof the right-hand corner. Additionally you also need anSSL Certificatefor the Hostname (headerapp.superdemo.live), in this example we used Wildcard Certificate. Go to –F5 (Header Based) BIG-IP Click Access > Guided Configuration > Federation > SAML Service Provider. Specify theEntity ID(same as what you configured on the Azure AD Application Configuration). Create a new Virtual Server, Specify theDestination Address,Redirect Portis Optional. Choose theWild Card Certificate(orCertyou uploaded for the Application) that we uploaded earlier and theAssociated Private Key. Upload the ConfigurationMetadataand Specify a newName for SAML IDP Connectorand you will also need to specify the Federation Certificate that was uploaded earlier. Create NewBackend App Pool, specify theIP Address(s)of the Backend Application Servers. Under Single Sign-on, ChooseHTTP header-based. You can add other Headers based on your application. See the Appendix for the list of SAMLSession Variables. Under Endpoint Checks Properties , click Save & Next. Under Timeout Settings, leave default settings and click Save & Next. Review Summaryand click onDeploy. Resources BIG-IP Knowledge Center BIG-IP APM Knowledge Center Configuring Single Sign-On with Access Policy Manager Summary By centralizing access to all your applications, you can manage them more securely. Through the F5 BIG-IP APM and Azure AD integration, you can centralize and use single sign-on (SSO) and multi-factor authentication for on-premise applications. Validated Products and Versions Product BIG-IP APM Version 15.0
How to generate the persistence cookie with an iRule
Problem this snippet solves: When you configure a cookie persistence profile to use the HTTP Cookie Insert or HTTP Cookie Rewrite method, the BIG-IP system inserts a cookie into the HTTP response. The cookie value contains the encoded IP address and port of the destination server. Exemple of a cookie value : 1677787402.36895.0000 (See SOL6917 for more information about this topic) Let's assume that you want your pool member to receive a copy of this cookie value in an HTTP header. Because for example you want your application to forge an url where the cookie value is in a GET parameter. (NOTE : I cannot modify the behavior of the application, I can only play with headers) Retrieving the cookie value is pretty easy with iRule : [HTTP::cookie value $cookie_name] But you'll notice that there is a little issue with this feature: when you are a new visitor, the persistence cookie is inserted in the HTTP response ... Meaning that for the very first hit made by the visitor, there will be NO cookie value to retrieve ... In my scenario it was an issue to miss this cookie value on the first hit, so I had to come up with a solution to forge the cookie value based on pool member IP and port when the persistence cookie is missing. I chose to adapt the code found here and there (thanks !) EDIT : Well I figured out that if you are not using a default route-domain the persistence cookie value will be different (see https://support.f5.com/csp/article/K6917 ) Here is the alternative code bloc to use IPv4 non-default route domains: set ADDR "[format %02x $a][format %02x $b][format %02x $c][format %02x $d]" set PORT [LB::server port] set COOKIE "rd2o00000000000000000000ffff${ADDR}o${PORT}" How to use this snippet: To summarize what the iRule does : if the persistence cookie doesn't exist (most likely because it's the very first hit), then calculate it from member IP and PORT (it obviously has to be after the "When LB_SELECTED" statement) ; else just read the existing cookie. You can set the $cookie_name parameter manually, or let the iRule identify it Code : when LB_SELECTED { #set cookie_name SERVERID # following function could determine persistence cookie name being used if not manually set by the previous line if {not [info exists cookie_name]} { if { [set cookie_name [PROFILE::persist mode cookie cookie_name]] eq "" } { set cookie_name "BIGipServer[getfield [LB::server pool] "/" 3]" } #Default cookie name requires the getfield "/" 3 purge otherwise it's /Common/pool_name } if { [set COOKIE [HTTP::cookie value $cookie_name]] == "" } { scan [LB::server addr] {%d.%d.%d.%d} a b c d set ADDR [expr { $a + $b * 256 + $c * 65536 + $d * 16777216 }] set PORT [ntohs [LB::server port]] set COOKIE "${ADDR}.${PORT}.0000" ## Following bloc must be used instead if you are using non-default route domains, see K6917 #set ADDR "[format %02x $a][format %02x $b][format %02x $c][format %02x $d]" #set PORT [LB::server port] #set COOKIE "rd2o00000000000000000000ffff${ADDR}o${PORT}" ######### unset a b c d ADDR PORT #log local0. "$cookie_name = $COOKIE created for [HTTP::uri]" } else { #log local0. "$cookie_name = $COOKIE already exists for [HTTP::uri]" } HTTP::header insert X-F5-persist $COOKIE } Tested this on version: 11.5
An Irule for Client Ssl Profile that Allows Unassigned TLS Extension Values (17516)
Hello Community, I have a requirement to allow enriched https header enrichment. The SSL negotiation (I'm doing ssl termination on F5) fails because the enriched header from client contains reserved tls extension values. (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtmltls-extensiontype-values-1). The Client Hello request in the SSL Handshake was captured and contained an Extensions list, which included a reserved TLS Extension value (17156), which the F5 isn't presenting in Server Hello. I need an irule that can allow that Extension to be added on the client ssl profile so the ssl handshake doesn't fail.Azure Active Directory and BIG-IP APM Integration with SAP ERP
Introduction Despite recent advances in security and identity management, controlling and managing access to applications through the web—whether by onsite employees, remote employees or contractors, customers, partners, or the public—is as difficult as ever. IT teams are challenged to control access based on granular characteristics such as user role while still providing fast authentication and, preferably, unified access with single sign-on (SSO) capabilities. The ability to audit access and recognize and stop attempts at unauthorized access are also critical in today’s security environment. F5® BIG-IP® Local Traffic Manager™ (LTM) and F5 BIG-IP® Access Policy Manager® (APM) address these challenges, providing extended access management capabilities when used in conjunction with the Microsoft Azure Active Directory (AAD) identity management platform. The integrated solution allows AAD to support applications with header-based and Kerberos based authentication and multifactor authentication using a variety of factor types. In addition, the BIG-IP system can act as a reverse proxy for publishing on-premises applications beyond the firewall, where they can be accessed through AAD. This document will discuss the process of configuring AAD and F5 Big-IP to meet this requirement while still providing the flexibility and power of the cloud. Audience This guide is written for IT professionals who need to design an F5 network. These IT professionals can fill a variety of roles: ·Systems engineers who need a standard set of procedures for implementing solutions ·Project managers who create statements of work for F5 implementations ·F5 partners who sell technology or create implementation documentation Customer Use Cases Security is one of the primary considerations for organizations in determining whether or not to migrate applications to the public cloud. The problem for organizations with applications in the cloud, in a data center, managed, or as a service, is to create a cost-effective hybrid architecture that produces secure application access and a great experience that allows users to access apps easily, have consistent user experiences, and enjoy easy access with single-sign-on (SSO) tied to a central identity and authentication strategy. Some applications are not favorable to modernization. There are applications that are not suited for, or incapable of, cloud migration. Many on-premises apps do not support modern authentication and authorization, including standards and protocols such as SAML, OAuth, or OpenID Connect (OIDC). An organization may not have the staff talent or time to perform application modernization for their on-premises apps. With thousands of apps in use daily, hosted in all or any combination of these locations, how can organizations ensure secure, appropriate user access without requiring users to login in multiple times? In addition, how can organizations terminate user access to each application without having to access each app individually? By deploying Microsoft Azure Active Directory, Microsoft’s comprehensive cloud-based identity platform, along with F5’s trusted application access solution, Access Policy Manager (APM), organizations are able to federate user identity, authentication, and authorization and bridge the identity gap between cloud-based (IaaS), SaaS, and on-premises applications. Figure 1Secure hybrid application access This guide discusses the following use cases: ·Users use single sign-on to access SAP ERP application that requires Kerberos-based authentication. Microsoft Azure Active Directory and F5 BIG-IP APM Design For organizations with a high security demand with low risk tolerance, the need to keep all aspects of user authentication on premise is required. The Microsoft Azure Active Directory and F5 BIG-IP APM solution integrates directly into AAD configured to work cooperatively with an existing Kerberos based, header based or variety of authentication methods. The solution has these components: •BIG-IP Access Policy Manager (APM) •Microsoft Domain Controller/ Active Directory (AD) •Microsoft Azure Active Directory (AAD) •SAP ERP Application (Kerberos-based authentication) Figure 2APM bridge SAML to Kerberos authentication components Figure 3APM bridge SAML to Kerberos authentication process flow Deploying Azure Active Directory and BIG-IP APM integration The joint Microsoft and APM solution allow legacy applications incapable of supporting modern authentication and authorization to interoperate with Azure Active Directory. Even if an app doesn’t support SAML, and only is able to support header- or Kerberos-based authentication, it can still be enabled with single sign-on (SSO) and support multi-factor authentication (MFA) through the F5 APM and Azure Active Directory combination. Azure Active Directory as an IDaaS delivers a trusted root of identity to APM creating a bridge between modern and SAP ERP applications, delivering SSO and securing the app with MFA. Configuring Microsoft Azure Active Directory These instructions configure Azure AD SSO with APM to be used with SAP ERP. For SSO to work, you need to establish a link relationship between an Azure AD user and the related user in F5. To configure and test Azure AD SSO with APM, complete the following tasks: ·Create an Azure AD user– to add users to Azure AD. ·Assign the Azure AD user- to enable users to use Azure AD single sign-on. ·Configure Azure AD SSO- to enable your users to use this feature. Create an Azure AD user In this section, you'll create a test user in the Azure portal named Harvey Winn. From the left pane in the Azure portal, click Users, and then selectAll users. Click +New userat the top of the screen. In theUserproperties, follow these steps: User name: harvey@aserracorp.com Name:Harvey Winn Select theShow passwordcheck box, and then write down the value that's displayed in thePasswordbox. ClickCreate. Assign Azure AD users to application 1.In the search field, type “enterprise applications” and click on Enterprise applications. 2.Click on “New applications 3.In the search field under Add from the gallery, type “f5” and click on SAP ERP Central Component (ECC) and then Add. 4.In the SAP ERP Central Component (ECC) - Protected by F5 Networks BIG-IP APM | OverviewClick window, click 1. Assign users and groups, and in the next screen, click + Add user. 5.In Home > SAP ERP Central Component (ECC) - Protected by F5 Networks BIG-IP APM | Users and groups > Add Assignment page, click Users and groups. 6.In the search field under Users and groups, search “harvey” and click on the user Harvey Winn, click on Select and then click on Assign. Configure Azure AD SSO 1.Click on Single sign-on. 2.Click on SAML. 3.In Home > SAP ERP Central Component (ECC) - Protected by F5 Networks BIG-IP APM | Single sign-on > SAML-based Sign-on page, under Basic SAML Configuration, click the edit icon. 4.Complete the following information and click Save. ·Identifier (Entity ID): https://saperp.aserracorp.com/ ·Reply URL (Assertion Consumer Service URL): https://saperp.aserracorp.com/saml/sp/profile/post/acs ·Relay State: https://saperp.aserracorp.com/irj/portal ·Logout Url: https://saperp.aserracorp.com/saml/sp/profile/redirect/slo 5.In Home > SAP ERP Central Component (ECC) - Protected by F5 Networks BIG-IP APM | Single sign-on > SAML-based Sign-on page, under User Attributes & Claims, click the edit icon, and click + Add new claim. 6.In Home > SAP ERP Central Component (ECC) - Protected by F5 Networks BIG-IP APM | Single sign-on > SAML-based Sign-on > User Attributes & Claims > Manage claim page, complete the following information and click Save. ·Name: sAMAccountName ·Source attribute: user.onpremisessamaccountname 7.Click > SAML-based Sign-on > , to verify information 8.Under SAML Signing Certificate and next to Federation Metadata XML, click right click on Download and select Save Link As… 9.Rename File name to SAPEP.xml and click Save. Note: APM Guided Configuration will not accept spaces in the file name 10.Azure AD configuration completed. Configure F5 BIG-IP APM These instructions configure with APM to be used with Azure AD SSO for SAP ERP application access. For SSO to work, you need to establish a link relationship between APM and Azure AD in relation to the SAP ERP. To configure and test Azure AD SSO with APM, complete the following tasks: Configure the Service Provider (SAP ERP): Service Provider can sign authentication requests and decrypt assertions. Configure a Virtual Server: When the clients send application traffic to a virtual server, the virtual server listens for that traffic, processes the configuration associated with the server, and directs the traffic according to the policy result and the settings in the configuration. Configure External Identity Provider Connector: Define settings for an external SAML IdP. When acting as a SAML Service Provider, the BIG-IP system sends authentication requests to and consumes assertions from external SAML IdPs that you specify. Configure the Pool Properties: enables you to configure a pool of one or more servers. If you have a suitable pool configured already, select it. Otherwise, create a new one. Add servers, select a load balancing method, and, optionally, assign a health monitor to the pool. Configure Single Sign-On: leverages credential caching and credential proxying technology so users can enter their credentials once to access their secured web applications. This SSO mechanism allows the user to get a Kerberos ticket and present it transparently to the IIS application. You must know the Kerberos Realm, Account Name, and Account Password before proceeding. 1. In BIG-IP click Access > Guided Configuration > Federation > SAML Service Provider. 2. Click Next. 3. In the Service Provider Properties page, configure the following information, leave default settings and click Save & Next. • Configuration Name: saperp • Entity ID: https://saperp.aserracorp.com/ • Scheme: https • Host: saperp.aserracorp.com • Relay State: https://saperp.aserracorp.com/irj/portal 4. In the Virtual Server Properties page, configure the following information, leave default settings and click Save & Next. • Destination Address: 206.124.129.129 • Service Port: 443 HTTPS (default) • Enable Redirect Port: Checked (default) • Redirect Port: 80 HTTP (default) • Client SSL Profile: Create new • Client SSL Certificate: asper.aserracorp.com • Associated Private Key: saperp.aserracorp.com 5. In the External Identity Provider Connector Settings page, configure the following information, leave default settings and click Save & Next. • Select method to configure your IdP Connector: Metadata • Upload a file in the format name .xml: Choose File saper.xml • Name: saperp_aad_idp 6. In the Pool Properties page, configure the following information, leave default settings and click Save & Next. • Select a Pool: Create New • Load Balancing Method: Least Connections (member) • Pool Servers • IP Address/Node Name: /Common/172.31.23.14 • Port: 50000 7. In the Single Sign-On Settings page, click Enable Single Sign-On, and then click on Show Advanced Settings, configure the following information, leave default settings and click Save & Next. • Select Single Sign-On Type: Kerberos • Credentials Source • Username Source: session.saml.last.attr.name.sAMAccountName • SSO Method Configuration • Kerberos Realm: ASERRACORP.COM • Account Name: sapsrvacc • Account Password: password • Confirm Account Password: password • KDC: 172.16.60.5 • SPN Pattern: HTTP/sapsrv.aserracorp.com@ASERRACORP.COM • Ticket Lifetime: 600 (default) • Send Authorization: Always (default) 8. In the Endpoint Checks Properties page, leave default settings and click Save & Next. 9. In the Timeout Settings page, leave default settings and click Save & Next. 10. In the Your application is ready to be deployed page, click Deploy. 11. APM configuration completed. Resources BIG-IP Knowledge Center BIG-IP APM Knowledge Center Configuring Single Sign-On with Access Policy Manager Summary By centralizing access to all your applications, you can manage them more securely. Through the F5 BIG-IP APM and Azure AD integration, you can centralize and use single sign-on (SSO) and multi-factor authentication for SAP ERP.
How to validate receive string and set multiple send string
For one of the VIP below is the HTTP Send String I configured. GET /portal/portaladmin/healthCheck HTTP/1.1\r\nHost: TEST.TEST.Ca\r\nConnection: Close\r\n\r\n How to confirm what I am receiving in as receive string? I need to set Receive String as 401. ? I used Curl and I see 401 is showed up ( marked Black ). So is it that I only need to write 401 in the Receive String of Monitor ? 2nd question I need to set multiple monitor for different services configured on same server. How to set multiple send string from a single Monitor Configuration. ? Let say if I am configuring 2 send string and 2 corresponding receive string how to set that when both of the String Condition need to be True as a condition to mark the VIP live. ? [admin@F5:Active:In Sync] ~ # curl -vk https://test.test.ca/portal/portaladmin/healthCheck * About to connect() to test.test.ca port 443 (#0) *Trying 10.8.16.62... connected * Connected to test.test.ca (10.8.16.62) port 443 (#0) * successfully set certificate verify locations: *CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server key exchange (12): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using DHE-RSA-AES256-GCM-SHA384 * Server certificate: *subject: C=CA; ST=ns; L=Halifax; O=Nova Scotia Power Inc; OU=IT; CN=test.test.ca *start date: 2019-04-17 00:00:00 GMT *expire date: 2021-04-21 12:00:00 GMT *subjectAltName: test.test.ca matched *issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA *SSL certificate verify ok. > GET /portal/portaladmin/healthCheck HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 OpenSSL/1.0.1l zlib/1.2.3 libidn/1.18 > Host: test.test.ca > Accept: */* > < HTTP/1.1 401 Unauthorized < Content-Type: text/html < Server: Microsoft-IIS/10.0 < WWW-Authenticate: Negotiate < WWW-Authenticate: NTLM < X-Powered-By: ASP.NET < Date: Mon, 05 Aug 2019 18:41:27 GMT < Connection: close < Content-Length: 1293 < Vary: Accept-Encoding < <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>401 - Unauthorized: Access is denied due to invalid credentials.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} fieldset{padding:0 15px 10px 15px;} h1{font-size:2.4em;margin:0;color:#FFF;} h2{font-size:1.7em;margin:0;color:#CC0000;} h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;} #header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF; background-color:#555555;} #content{margin:0 0 0 2%;position:relative;} .content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;} --> </style> </head> <body> <div id="header"><h1>Server Error</h1></div> <div id="content"> <div class="content-container"><fieldset> <h2>401 - Unauthorized: Access is denied due to invalid credentials.</h2> <h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3> </fieldset></div> </div> </body> </html> * Closing connection #0 * SSLv3, TLS alert, Client hello (1):
Do I need to check HTTP::header exists before checking value?
I feel like this is a simple question, but I can't seem to find a definitive answer... To check the value of a particular HTTP header, I can do this: if { [HTTP::header Origin] ends_with "example.com" } { ...do stuff here... } My basic question is "What happens is the Origin header is not passed?"... The spec says that HTTP::header will return null if the header called does not exist. What does this mean for my if statement - is null treated the same as false in an if statement? If the above code example will be problematic if Origin is not passed, can I write the code as a single line, like this: if { [HTTP::header exists Origin] and [HTTP::header Origin] ends_with "example.com" } { ...do stuff here... } or does it need to be two separate nested if statements: if { [HTTP::header exists Origin] } { if {[HTTP::header Origin] ends_with "example.com" } { ...do stuff here... } }Using F5 as a Service Provider with Okta IdP
I've read part 1 and 2 of this article for how to connect F5 as a service provider to Okta: Secure Access to Web Applications with F5 and Okta... - DevCentral However, it doesn't provide instructions for how to get theSingle sign on URLand theAudience URIfor the app, and I also can't find an article for how to connect F5 to the application to pass the header or kerberos auth to. Could someone help me? I'm basically looking for what information I'll need to retrieve and give to the owners of the systems using legacy auth in order to connect those systems to F5 to use Okta auth with them.
TLS/1.0, PCI, and a custom message for HTTP response status codes
By June 30, 2018 we would like to turn off TLS/1.0 on all our HTTPS websites, in order to be compliant with PCI requirements. Instead of just turning TLS/1.0 off, we would like to use that time between now and June 30, 2018 to seamlessly phase the TLS/1.0 out. To do so, our F5 still supports all TLS protocols (TLS/1.0, TLS/1.1, and TLS/1.2), but only the clients supporting TLS/1.1 and above get the actual website content. Everyone else (clients supporting TLS/1.0 only) gets a custom error page informing them about the browser upgrade requirement. To achieve that, I'm using the HTTP status code "426 Upgrade Required". Please see: 4.2 Mandatory Advertisement in RFC2817 Server-initiated upgrade to TLS The expected result is: HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.1, HTTP/1.1 Connection: Upgrade ... Human-readable HTML page describing why the upgrade is required and what to do if this text is seen ... Unfortunately, F5 gives me the following result: HTTP/1.1 426 Unknown Code Upgrade: TLS/1.1, HTTP/1.1 Connection: close ... Human-readable HTML page describing why the upgrade is required and what to do if this text is seen ... My iRule looks like this: Detect TLSv1.0 protocol and send HTTP 426 when HTTP_REQUEST priority 150 { if { [SSL::cipher version] equals "TLSv1" } { log local0. "TLS/1.0 connection detected from [IP::client_addr] for [HTTP::host]" HTTP::respond 426 -version auto content $static::obsolete_browser_page noserver "Upgrade" "TLS/1.1, HTTP/1.1" "Content-Type" "text/html" "Cache-Control" "no-cache" "Retry-After" "60" "Connection" "Close" event disable return } } If I use "Connection" "Upgrade" in the HTTP::respond code, as defined in the aforementioned RFC2817, F5 replaces it with Connection: Keep-Alive in the actual response which is being sent back to the client. My questions are: Question 1: is there a way in F5 to replace the message in HTTP response, so that it says: HTTP/1.1 426 Upgrade Required instead of HTTP/1.1 426 Unknown Code Question 2: is there a way to force F5 to send HTTP header that says: Connection: Upgrade instead of Connection: close or Connection: Keep-AliveBIG-IP : http profile : insert x-forwarded-for : enabled
F5 BIG-IP Virtual Edition v11.4.1 (Build 635.0) LTM on ESXi HTTP Profile Insert X-Forwarded-For : Enabled Suppose the client has already added the "X-Forwarded-For" header value to the request. How will BIG-IP behave ? Will it leave the existing header value intact ? Or will it overwrite the value with what it believes to be the request client ip ? Further, at what point in request-processing does the insert/replace header operation occur ? Does it occur before iRule processing so that the header value is available within the iRule event processing when HTTP_REQUEST {} ?
Cannot POST files >60KB via BIGIP LTM
Hi, My Customers are facing an issue wherein the users not able to POST files >60KB to an application abc.xyz.com hosted on BIGIP. Below is the error they see, {"errors":["errors.adt.ci.metainfo.provider.not.found "]} However, they are able to send directly to the backend server without any issues. For the above VS on BIGIP, the default HTTP profile has been attached wherein the Maximum Header Size is as around 32KB. Is there anyway to increase this file limit or solve this issue ??? Thanks in advance, MSK
