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
Citrix Federated Authentication Service Integration with APM
Introduction This guide will cover how to use APM as the access gateway in front of Storefront when using Citrix FAS. This will enable you to leverage authentication methods like SAML, Kerberos, or NTLM on the client side. Note that almost any auth method can be supported via Receiver for web, but Receiver self-service does not support some auth methods such as SAML. Deploy Citrix Federated Authentication Service Now you’ll need to deploy Citrix Federated Authentication Service (FAS). Deployment of FAS is out of scope for this article, but as there are many parts I found the following guide from Carl Stalhood very helpful: http://www.carlstalhood.com/citrix-federated-authentication-service-saml. Ignore the section “SAML on Netscaler Gateway” since you’re going to deploy APM instead, but don’t miss that last section “Configuring Storefront for SAML Gateway”. When configuring Storefront anywhere it requests the Netscaler Access Gateway address you’ll use the FQDN you intend to use for your virtual server on Big-IP (how users will access Storefront). Examples include the callback URL field when configuring the authentication and when configuring the Netscaler gateway. Before proceeding, you should be able to go direct to the Storefront server, log in, and be able to launch an application successfully. There can still be misconfigurations that prevent access through an access gateway, but you will have fewer areas left as problems. You must use an Enterprise CA, otherwise on the CA you will see pending certificates not getting approved automatically and you will be unable to launch apps. Also note that if you have previously made configuration modifications usually needed forearlier versions like Citrix 6.5, such as host file entries, those should be removed prior to proceeding. For correct operation of FAS, DNS needs to be setup properly which may include setting up PTR records. Create the SAML SP In the Big-IP GUI go to Access Policy -> SAML -> Big-IP as SP and click create. You’ll create an SP config and for the entity ID in the format https://my-vs-fqdn.domain.com. All the rest can be left default. Now you’ll need to setup your IdP Connector. This could be another Big-IP APM, ADFS, Okta, or any other IdP service. You can import the metadata if available or you can manually configure it. Configuring the IdP connector is out of scope for this article, but after configuring it, you’ll select your SP and click the “Bind/Unbind IdP Connectors” button, “Add New Row”, select it from the drop down as the SAML IdP Connector, then click Update, OK. Note that you can bind multiple IdP connectors here if there are multiple IdPs. You need to set a matching source (variable) and the matching value that should cause use of that IdP. A common solution might be %{session.server.landinguri} for the source and /customer1 for the matching value to go to customer 1’s IdP. Now you’ll see this on the SP configuration page. Your IdP should be setup to send either the user’s userPrincipalName or sAMAccountName as the NameID. This should match either the userPrincipalName or sAMAccountName of the user account in the AD domain used by Citrix that you want the user logged in as. Carl Stalhood’s guide linked above provides an example configuring the ADFS IdP and he is using userPrincipalName. Note that if you decide to use alternate UPNs (not matching your AD domain name) for your users you will also need to enable those domains in “Trusted Domains” on your Storefront server. Deploy the iApp Now we can move on to deploying APM as your access gateway. First, deploy the latest iApp. At the time of writing this article, that’s version 2.4.0. When deploying the iApp you’ll need to answer the following questions as shown: You’ll need to specify your STA servers: Finally, pay special attention to the DNS name you’re going to have clients use. This should be the same as you used in the Citrix Storefront configuration earlier and the SAML configuration later. This is how users are going to access the deployment. Now you have the iApp for Citrix deployed, but it’s using the default forms based authentication. You need to customize the authentication method. This guide will help you deploy SAML authentication, but as mentioned you could use NTLM, Kerberos, or another authentication method. Before proceeding you need to verify that the certificate you’ve selected is valid. If it is not, SSO will fail when Storefront tries to callback to the virtual server and the user will get the error “Cannot Complete Your Request”. You can browse to the FQDN you entered from the Storefront server to make sure you don’t get certificate errors. Normally you would use a publicly signed certificate and that will work fine (but don’t forget the chain). If it’s an internally signed certificate, your Storefront server needs to trust it as well. Modify the iApp’s APM Policy By default the policy looks like this: We need to modify it to look like this: To modify the policy you will need to turn off “strict updates” on the iApp: Note that in this case we aren’t modifying the Receiver branch because Receiver doesn’t support SAML authentication. You could just change it to deny receiver clients if desired. First remove the Logon Page, AD Authentication, and SSO Credential Mapping objects from the Browser branch. Next add a SAML Auth object right before the Session Variable Assign object (plus sign, Authentication tab, SAML Auth). Select the SP you configured earlier. Next, open the Session Variable Assign. You need to add a new entry, and set session.logon.last.username to equal the session variable session.saml.last.nameIDValue. Notice that the domain and sta_servers variables were set here already, those were done by the iApp. Here is what creating that looks like: Now your policy should look like the one above. Be sure to click Apply Policy in the top left. Test And finally you should be able to browse to the FQDN of your new virtual server, be redirected to your SAML IdP for authentication, then get redirected back and SSO’ed in to your Citrix environment. You should be able to see the Storefront catalog and launch an application Updates 12/21/2016 - Removed an iRule that is not needed for SSO to function properly in a complete deployment
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.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_auth
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!
