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!
Secure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2)
This article is the first in a two-part series. Go to Part 2 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2) Introduction Despite recent advances in security and identity management, controlling and managing access to applications through the web—whether by onsite/remote employees or contractors, partners, customers, 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 recognize and stop attempts at unauthorized access is critical in today’s security environment. The joint F5 BIG-IP® Access Policy Manager® (APM) and Okta identity management platform solution address these challenges. This solution provides extended access management capabilities across on-premises and cloud environments enabling organizations to secure web applications anywhere.In addition to authentication management and policy-based authorizations, the solution also supports applications with header-based and Kerberos based authentication. The F5 and Okta Solution In this SAML 2.0 integrated solution (shown in Figure 1), •Okta is the Identity Provider (IdP). Users can be defined locally within Okta. In most cases, an on-premises Active Directory and/or LDAP is the source of identities and is integrated with Okta via Okta’s AD/LDAP agent. •Between Okta and the F5 BIG-IP system, a SAML trust is built with the BIG-IP platform acting as a SAML service provider (SP). •The target applications are protected behind the BIG-IP reverse proxy by header-based or Kerberos authentication. •SAML assertion from Okta is consumed by the BIG-IP system, which then translates the assertion appropriately for the downstream application based on its authentication scheme. Figure 1: The basic integration between the F5 BIG-IP system and Okta for single sign-on (SSO) Deployment Procedure This procedure described below is based on a lab environment. The instructions below may be modified to match your specific needs or requirements. Prerequisites •Refer to AskF5 for additional information, including how to initially set up a BIG-IP environment including basic BIG-IP® Local Traffic Manager® (LTM) and BIG-IP APM configurations. F5 BIG-IP TMOS® version 15.1 is used for this demonstration. However, these practices apply for versions 11.0 and later. •For additional information about configuring the Okta portion of the solution, refer to Okta documentation. Step 1: Configure Okta as SAML IDP for a New Application Refer to the step by step instructions and screenshots below to configure Okta as a SAML IdP for a new application called app.f5sec.net. 1.1 Okta Classic User Interface For this lab demonstration, we are using the Okta developer account. Click here to sign up for an Okta developer account, if you don’t already have one. •Log in to the Okta developer portal using your username and password. •For this demonstration, we will be using the Classic UI. On the top left corner of the developer portal, change the drop-down from Developer Console to Classic UI. Figure 2: Switching the Okta user interface to the Classic option. 1.2 Build a New Application We will build a new web application for SAML 2.0 integration. •On the main menu, hover on the Applications tab and click on Applications. •On the Applications page, click on the Add Application button. •On the Add Application page, click on the Create New App button. •In the Create a New Application Integration dialogue box, select the Web option in the Platform drop-down and SAML 2.0 as the Sign on method and click Create. Figure 3: Creating a new application for SSO using SAML 2.0 •On the Create SAML Integration page, under the General Setting section, enter the app name and click Next. Figure 4: Entering the app name •In the SAML Settings section, under the GENERAL options, enter the Single sign on URL and the Audience URI. Figure 5: Sample SAML configuration •Leave all other values as default and click Next. •In the next section, check the radio button that says, “I’m an OKTA customer adding an internal app”. •In the expanded window, select “This is an internal app that we have created” for App Type and click on Finish. Figure 6: Sample feedback configuration •In the resulting application page for app.f5sec.net, navigate to the SAML 2.0 section. •Right-click the Identity Provider Metadata hyperlink and click Save Link As. •Save the metadata.xml to the local system. We will be using this file later when configuring F5 BIG-IP APM as SAML SP. Figure 7: Exporting the IdP metadata 1.3 Assign Users to the Application Next, we will assign users to the application, granting them access. •Scroll up and click on the Assignments tab beneath app.f5sec.net. •Click on the Assign button and then again click Assign to People from the drop-down. •In the pop-up dialog box, click on the Assign button next to all the users that you want to assign access to app.f5sec.net web application. •When finished, click Done. Figure 8: Assigning users to the application This completes the Okta configuration. Next, we will move on to F5 BIG-IP APM for SAML SP and web app configuration. Part 2 - Secure Access to Web Applications with F5 and Okta using SAML 2.0Secure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2)
This article is the second in a two-part series. Go to Part 1 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2) Step 2: Configure F5 BIG-IP APM as SAML SP for the Application Refer to the step by step instructions and screenshots below to configure F5 BIG-IP APM as SAML SA for a new application called app.f5sec.net. 2.1 Import Certificate for the Application Import the certificate for app.f5sec.net. This certificate will be later referenced when configuring the application. •Log in to the F5 BIG-IP System. • On the F5 Configuration Utility (Web UI) Main menu, navigate to System > Certificate Management > Traffic Certificate Management > SSL Certificate List. •On the Traffic Certificate Management page, click the Import button on the right-hand corner. •On the SSL Certificate/Key Source page, select Key from the Import Type drop-down box. •Specify a Key Name and browse to the folder that contains the Key. After selecting the key file, click Import. • Back in the Traffic Certificate Management page, click on the imported Key name. • In the General Properties page, click on the Import button. •Browse to the folder that contains the Certificate. After selecting the certificate file, click Import. Figure 9: Importing application certificate and key 2.2 Using Guided Configuration The F5 BIG-IP APM Guided Configuration presents a completely new and streamlined user experience. This workflow-based architecture provides intuitive configuration steps tailored for a selected use case. The steps below will walk through the Guided Configuration to build the application and configure F5 BIG-IP APM as SAML SP. •On the F5 Web UI Main menu, navigate to Access > Guided Configuration. •Click on the Federation tile. From the expanded option, click on the SAML Service Provider tile. Figure 10: Guided configuration initial selection. •Take a moment to review the various configuration options on the SAML Service Provider page. Figure 11: SAML Service Provider page •Satisfy any of the DNS, NTP, Interface, VLAN, Route, and Self IP configuration prerequisites from this initial configuration page. •Scroll down and click Next. 2.2.1 Configure Service Provider Properties •To configure these properties, follow the guidance below. Figure 12: Sample ‘Service Provider Properties’ configuration. •Accept the remaining default entries and click Save & Next. 2.2.2 Configure Virtual Server Properties •To configure a virtual server for the app, follow these steps. Figure 13: Sample ‘Virtual Server Properties’ configuration. •Click Save & Next. 2.2.3 Configure Okta Identity Provider Connector •To configure Okta as the external SAML IdP provider, follow the steps below. Figure 14: Sample Okta IdP configuration. •Click Save & Next. 2.2.4 Create a Pool •To create a load balancing pool of application servers, follow the steps below. Figure 15: Sample ‘Pool Properties’ configuration. •Click Save & Next. 2.2.5 Configure Single Sign-On Settings •To configure Okta as the external SAML IdP provided, follow the steps below. Figure 16: Sample ‘Single Sign-on Settings’ configuration. •Click Save & Next. 2.2.6 Endpoint Checks Select the Enable Endpoint Checks radio button to enable endpoint checks. For this demonstration, we will leave this setting at default. Figure 17: 'Endpoint Checks Properties' page to enable and configure endpoint checks. •Click Save & Next. 2.2.7 Session Management Leave the Timeout Settings at default. Figure 18: Default timeout settings •Click Save & Next. 2.2.8 Summary Review the Summary screen. When done, scroll down and click Deploy. Figure 20: Confirmation of a successful deployment. • Click on the Finish button. This completes the F5 BIG-IP APM configuration. Step 3: Verification We will verify the solution by accessing app.f5sec.net. •Open a web browser on an end host and navigate to https://app.f5sec.net. Notice the request will be redirected to Okta.com for user authentication. Figure 21: Redirection to Okta for user authentication. •The application default web page prints all the headers. Notice that the HTTP_MYAUTHORIZATION header has been inserted with the appropriate value. Figure 22: HTTP_MYAUTHORIZATION header inserted with user identity value. Additional Resources Part 1 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 BIG-IP APM Product Information: Knowledge Center Free Training Course: Getting Started with BIG-IP Access Policy Manager (APM) Lightboard Lesson: F5 Access Policy Manager and Okta - Single Sign On and Multi-Factor Authentication External Resource: F5 | Okta partnershipEnhanced security with F5 BIG-IP APM and Okta through Multi-Factor Authentication
This article is the third in the three-part series. Go to Part 1 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (1 of 2) Go to Part 2 here: Secure Access to Web Applications with F5 and Okta using SAML 2.0 (2 of 2) Multi-factor Authentication (MFA) is a security best practice that enhances authentication by requesting two or more verifiable authentication factors. Common authentication factors are: Something You Know, Something You Have, and Something You Are. In addition to configuring native MFA support, the F5 BIG-IP Access Policy Manager (APM) system offers the flexibility to combine multiple authentication mechanisms from partners like Okta. In this DevCentral blog, we will look at how to configure APM for Okta MFA to authenticate using Something You Know and Something You Have. The HTTP connector for Okta MFA is supported in F5 BIG-IP APM system running TMOS v16.0 or later. Setting up Okta MFA Follow the steps below to configure ‘Okta Verify’ for mobile MFA. Navigate to Okta web UI >> Security >> Multifactor and activate Okta Verify. Figure 1: Activate Okta Verify MFA Click on the Factor Enrollment option in the sub menu, then click on the Edit button. On the popup screen, choose Everyone option under Assign to groups. When done, press the Update Policy button. Figure 2: Assign the MFA policy to the user group Configuring F5 BIG-IP APM for Okta MFA Follow the steps below to configure the HTTP connector for Okta MFA. Create a DNS Resolver to Resolve the DNS Queries and Cache the Results On the main menu, navigate to Network >> DNS Resolvers. On the DNS Resolvers web page, click on the Create button. Enter a name and click the Finished button. On the DNS Resolvers web page, click on the above created DNS resolver list name. Navigate to the Forward Zones tab in the sub menu to add any recursive nameservers. When done, press the Finished button. Figure 3: Create the DNS resolver Creating an HTTP Connector and Assign the DNS Resolver Navigate to Access >> Authentication >> HTTP Connector and click on HTTP Connector Transport. On the HTTP Connector Transport web page, click on the Create button. Enter a name and select the above created DNS Resolver and the SSL Server Profile. When done, press the Save button. Figure 4: Sample HTTP connector configuration Creating the Okta Connector and Assigning the HTTP Connector Navigate to Access >> Authentication and click on Okta Connector. On the Okta Connector web page click on the Create button. Enter a name and select the above created HTTP connector. Type the Okta Domain name and paste the Okta API Token from Okta. When done, press the Save button. Figure 5: Sample Okta connector configuration Note: To create a new Okta API token, navigate to Okta web UI >> Security >> API and click on Tokens. Creating and assigning the Access profile and Access Policy to the Application Follow the steps below to create an access profile and per-request access policy for Okta MFA and assign them to the application. Creating the Access Profile and Access Policy Navigate to Access >> Profiles/Policies and click on Access profiles (Per Session Policies). click on the Create button to create a new access profile. Enter a name and select All in the Profile Type drop down-list. Scroll down to the Language Settings section. Select the preferred language and move it to the left into Accepted Languages box. When done, press the Finished button. Figure 6: Sample access profile configuration Next, navigate to Access >> Profiles/Policies and click on Per-Request Policies. Click on Create button to create a new access policy. Enter a name and select All in the Profile Type drop down list. Scroll down to the Language Settings section. Select the preferred language and move it to the left into Accepted Languages box. When done, click on Finished button. On the Per-Request Policies page, click the Edit button next to the above created policy. Create the per-request policy using the Visual Policy Editor as show in the figure 7. Figure 7: Sample per-request policy To add the Okta MFA, click on the + sign. On the popup screen, click on the Authentication tab and select Okta MFA. When done, click on the Add Item button. On the popup screen, enter a name and choose the above configured Okta connector. When done, click the Save button. Figure 8: Sample Okta MFA configuration with ‘Okta Connector’ assigned Assigning the Access Profile and Access Policy to the Virtual Server Navigate to Local Traffic >> Virtual Servers >> Virtual Server List and click on the Virtual server configured for the application. Scroll down to the Access Policy section and select the Access Profile and the Per-request Policy. When done, press the Update button. Figure 9: Assign the access profile and per-request policy to the virtual server Validating and Verifying the Solution Follow the steps below to setup and validate mobile MFA using ‘Okta Verify’. Download the ‘Okta Verify’ app on your mobile device. Login to Okta Web UI using your username and password. On the dashboard, click on the user setting. Under the extra verification section, click on the Setup button. On the resulting web page, click on Configure Factor and choose the Device Type (Android or Apple). Scan the presented barcode with the Okta mobile app for verification, this completes the setup. Access the application app.f5sec.net from a browser. When prompted enter the username and password. After successful authentication, you will be prompted for MFA, click on the Send Push button. Complete the MFA using the Okta Verify app on your mobile device. Figure 10: User prompted for MFA after successful authentication Conclusion The joint F5 and Okta MFA integration offers a compelling solution for customers who are interested in securely accessing enterprise applications on-premises and in any cloud by increasing the assurance of authentication. Additional Resources Part 1 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 Part 2 - Secure Access to Web Applications with F5 and Okta using SAML 2.0 BIG-IP APM Product Information: Knowledge Center Free Training Course: Getting Started with BIG-IP Access Policy Manager (APM) Lightboard Lesson: F5 Access Policy Manager and Okta - Single Sign On and Multi-Factor Authentication External Resource: F5 | Okta partnershipShared Authentication Domains on BIG-IP APM
How to share an APM session across multiple access profiles. A common question for someone new to BIG-IP Access Policy Manager (APM) is how do I configure BIG-IP APM so the user only logs in once. By default, BIG-IP APM requires authentication for each access profile. This can easily be changed by sending the domain cookie variable is the access profile’s SSO authentication domain menu. Let’s walk through how to configure App1 and App2 to only require authentication once. We’ll start with App1’s Access Profile. Once you click through to App1’s settings, in the Top menu, select SSO/Auth Domains. For the Domain Cookie, we’ll set the value to f5demo.com since App1 and App2 use this domain and it is a FQDN. Of course, click Update. Next, we’ll select App2’s Access Profile. Like App1, we select SSO/Auth Domains and set the Domain Cookie value to f5demo.com. To make sure it works, we’ll launch App1 in our browser. We’re prompted for authentication and enter our credentials and luckily, we have a successful login. And then we’ll try to login to App2. And when we click it, we’re not prompted again for authentication information and gain access without prompts. Granted this was a single login request for two simple applications but it can be scaled for hundreds of applications. If you‘d like to see a working demo of this, check it out here. psPost of the Week: Two-Factor Auth and SSO with BIG-IP
In this Lightboard Post of the Week, I answer a question about 2FA and SSO with AD/RSA on BIG-IP by creating a SSO Credential Mapping policy agent in the Visual Policy Editor, that takes the username and password from the logon page, and maps them to variables to be used for SSO services. Special thanks to senthil147for the question and a new 2018 MVP, MrPlastic (Lee Sutcliffe, which I flubbed) for the great answer. Posted Question on DevCentral: 2FA Authentication with SSO on APM psUS FEDERAL: Enabling Kerberos for Smartcard Authentication to Apache.
The following provides guidance on the configuration of BIG-IP Local Traffic Manager and Access Policy Manager in support of Apache Web Server Smartcard / Kerberos access using Active Directory as the Key Distribution Center. This content is part of a series developed to address the configuration of non IIS webservers to support Kerberos Single Sign On and therefore smartcard access, but should be relevant anywhere SSO utilizing Kerberos is needed. Several assumptions are made concerning the implementation of Active Directory, PKI, and the Linux Distro(s) used. Base Software Requirements The following base requirements are assumed for this configuration. Microsoft Windows Server 2008 R2 (Active Directory) BIG-IP LTM 11.4 or higher (the configuration items will probably work with most versions of 11 but only 11.4 and 11.5 were tested in the scenario) Ubuntu Server 13.10 (This is a fairly simple and user friendly distro based on Debian, this was also tested in RHEL/CentOS.) This config will work in other distro’s of Linux, but posting all the difference configurations would just be redundant. If you need help, reach out to the US Federal Team. How it Works The configuration of this scenario is fairly simple. The majority of the configuration and testing will most likely reside on the Linux side. The client access and authenticates to APM via a smartcard. Depending on the method of choice, an attribute identifying the user is extracted from the certificate and validated against an AD/LDAP. In Federal, this step has two purposes; to extract the UPN to query AD for the User (EDIPI@MIL), and to retrieve the sAMAccountName to use for the Kerberos Principal. Once the user has been validated and the sAMAccountName retrieved, the session variables are assigned and the user is granted access. Base Linux Configuration Configure Static IP & DNS You can use the text editor of your own preference, but I like nano so that is what I will document. sudo nano /etc/network/interfaces You will want to change iface eth0 inet dhcp to static, and change the network settings to match your environment. Since this scenario uses Windows AD as the KDC, you will want to make sure your DNS points to a domain controller. auto eth0 iface eth0 inet static address 192.168.1.2 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 dns-nameservers 192.168.1.1 Note: Depending on your distro, you will use dns-nameservers or resolv.conf. I also removed the DHCP client entirely. (Not necessary, but I like to clean out things I wont ever use.) Restart networking sudo /etc/init.d/networking restart Or sudo service networking restart Install LAMP (Linux, Apache, MySQL, PHP) In Ubuntu, this is fairly simple, you can just do the following. sudo tasksel Then check the box for LAMP, and follow the on-screen instructions, set MySQL password, and then you are done. If you access the IP of your server from a browser, you will see the default Apache "It Works!" page. Install & Configure Kerberos sudo apt-get install krb5-user Some distros will ask for default REALM, KDC, and Admin server configs. In my case it is F5LAB.LOCAL, 192.168.1.5, 192.168.1.5. krb5.conf Depending on your distro, there will be a ton of extra settings in the krb5.conf file, some related to Heimdal and some for MIT Kerberos. The core settings that I needed for success are listed below. [libdefaults] Set your default realm, DNS lookups to true, and validate the encryption types. HMAC is good, Windows does not have DES enabled by default and you should not consider enabling it. default_realm = F5LAB.LOCAL dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = true default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des3-hmac-sha1 default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des3-hmac-sha1 [realms] KDC: Domain Controller admin_server: Not required, but can also point o Domain Controller default_domain: Kerberos Realm F5LAB.LOCAL = { kdc = 192.168.1.5:88 admin_server = 192.168.1.5 default_domain = F5LAB.LOCAL } Install Mod_Auth_Kerb This is required to make Apache support Kerberos. Some distros include this when you load apache, but here is how you make sure. sudo apt-get install libapache2-mod-auth-kerb Testing Lets make sure that we configured networking and Kerberos properly. Use KINIT to test a known user account. This should reach out to the KDC to get a ticket for the user. REALMS are case sensitive, so make sure its all upper case. The following will request a password for the user, and if everything is set up properly, there will be no response. kinit mcoleman@F5LAB.LOCAL You can run KLIST to see your ticket. klist An example of what happens when the REALM is entered incorrectly: KDC reply did no match expectations while getting initial credentials. Windows Configurations Configuring SPNs Since Linux is not the KDC or Admin server, this is done on the Active Directory side. Create a user account for each application, with the appropriate Service Principal Names. Be aware, when we run keytab, all SPNs will be overwritten, with the exception of the SPN used in the command. Crypto Pay attention to the encryption types that are / were enabled in the krb5.conf file. It is important to remember that both DES cipher suites (DES-CBC-MD5 & DES-CBC-CRC) are disabled by default in Windows 7.The following cipher suites are enabled by default in Windows 7 and Windows Server 2008 R2: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC For the purposes of this guide and the available settings in Windows use RC4-HMAC. DO NOT enable DES on Windows. Create a Keytab Keytabs can be created in windows by using ktpass. A keytab is a file that contains a Kerberos Principal, and encrypted keys. The purpose is to allow authentication via Kerberos, without using a password. ktpass –princ HTTP/lamp.f5lab.local@F5LAB.LOCAL -mapuser F5LAB\apache.svc -crypto RC4-HMAC-NT -pass pass@word1 -ptype KRB5_NT_PRINCIPAL -kvno 0 -out LAMP.keytab Copy the keytab to your linux server(s). For my use case I put the keytab at /etc/apach2/auth/apache2.keytab Lock it down - Linux The security of a keytab is pretty important. Malicious users with access to keytabs can impersonate network services. To avoid this, we can secure the keytab’s permissions. sudo chown www-data:www-data /etc/apache2/auth/apache2.keytab sudo chmod 400 /etc/apache2/auth/apache2.keytab Testing Now, we want to make sure everything is looking alright so far. So lets make sure the keytab looks right, and we can authenticate properly against the KDC. List the contents of the Keytab klist –ke /etc/apache2/auth/apache2.keytab Test Authentication with the S4U SPN The following commands can be used to initialize the credential cache for the S4U proxy account and then to test authentication with a user account. kinit –f http/lamp.f5lab.local@F5LAB.LOCAL kvno http/lamp.f5lab.local@F5LAB.LOCAL sudo klist –e –k –t /etc/apache2/auth/apache2.keytab kvno –C –U mcoleman http/lamp.f5lab.local Apache Configurations I was able to get authentication working by adding the following to the default site. In Ubuntu its /etc/apache2/sites-enabled/000-default.conf. <VirtualHost *:80> … <Location /> Options Indexes AllowOverride None Order allow,deny allow from allAuthType Kerberos #KrbServiceName HTTP/lamp.f5lab.local@F5LAB.LOCAL AuthName "Kerberos Logon" KrbMethodNegotiate on KrbMethodK5Passwd on KrbVerifyKDC off KrbAuthRealm F5LAB.LOCAL Krb5KeyTab /etc/apache2/auth/apache2.keytab require valid-user </Location> </VirtualHost> BIG-IP Configurations This portion is actually pretty straightforward. Configure a standard Virtual Server with a Pool pointing at the Apache Servers. Configuration Items • Kerberos SSO Profile – This is used to authenticate to Apache. • Access Profile – The Access profile binds all of the APM resources. • iRule – an iRule is used to extract the smartcard certificate User Principal Name (UPN). • ClientSSL Profile - This is used to establish a secure connection between the user and the APM VIP. Apply the server certificate, key, and a trusted certificate authority’s bundle file. All other settings can be left at default. • HTTP profile – This is required for APM to function. A generic HTTP profile will do. • SNAT profile – Depending on other network factors, a SNAT profile may or may not be necessary in a routed environment. If the backend servers can route directly back to the clients, bypassing the BIG-IP, then a SNAT is required. • Virtual server –The virtual server must use an IP address accessible to client traffic. Assign a listener (destination) IP address and port, the HTTP profile, the client SSL profile, a SNAT profile (as required), the access profile, and the iRule. Modify the krb5.conf [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes APM Kerberos SSO Profile Create an APM Kerberos SSO profile like the one shown below. Change the Username Source to “session.logon.last.username”, enter the Active Directory domain name (in all upper case), enter the full service principal name of the AD user service account previously created , and enter the account’s password. The only real change from IIS is the Send Authorization setting, which should be set to “On 401 Status Code.” Username Source: session.logon.last.username User REALM Source: session.logon.last.domain Kerberos REALM: F5LAB.COM KDC(optional): Account Name: HTTP/lamp.f5lab.com Account Password: password Confirm Account Password: password SPN Pattern (optional): Send Authorization: On 401 Status Note: The full service principal name includes the service type (ex. host/), the service name (ex. krbsrv.alpha.com), and the domain realm name (ex. @ALPHA.COM – in upper case). KDC can be specified, but is not needed unless you do not configure DNS lookup enabled in the krb5.conf on the F5. Basically, if you dont tell the F5 how to resolve the KDC, then you need to specify one. SPN Pattern can help resolve issues if you have issues with DNS/rDNS. You can specify which SPN you want to sent with either a designated, or dynamic option. VPE configuration The components of the VPE are as follows: • On-Demand Cert Auth – Set this to Require. • Rule event – Set the ID to “CERTPROC” to trigger the EDIPI extraction iRule code. • LDAP Query – Validates the UPN and retrieves sAMAccountName. Basic CAC iRule when ACCESS_ACL_ALLOWED { #Set Username to value of sAMAccountName extracted from LDAP Query. ACCESS::session data set session.logon.last.username [ACCESS::session data get "session.ldap.last.attr.sAMAccountName"] } when ACCESS_POLICY_AGENT_EVENT { switch [ACCESS::policy agent_id] { #Name of iRule event called from APM Policy "CERTPROC" { if { [ACCESS::session data get session.ssl.cert.x509extension] contains "othername:UPN<" } { #Set temporary session variable to value extracted from X.509 data. set tmpupn [findstr [ACCESS::session data get session.ssl.cert.x509extension] "othername:UPN<" 14 ">"] ACCESS::session data set session.custom.certupn $tmpupn #log local0. "Extracted OtherName Field: $tmpupn" } } } } Put it together. Now that all the functional parts are in place, you can test access to Apache. If you want to add some code to see what user is hitting your application, you can create a small PHP page containing the following code. $_SERVER['REMOTE_USER'] $_SERVER['KRB5CCNAME'] The server variables will echo the current authenticated user name. Troubleshooting Kerberos is fairly fault-tolerant, if the requisite services are in place. That being said, it can be a PITA to troubleshoot. If Kerberos authentication fails, check the following: The user has a valid ticket. Use klist, kinit, and kvno as explained previously. Validate basic network connectivity. DNS (Forward & Reverse), ensure no duplicate A or PTR records. This can be overwritten in the Keberos SSO profile SPN pattern settings. Verify the clocks of the KDC and local server are synced. Turn APM SSO logging up to debug and tail the APM logs (tail -f /var/log/apm). Questions? Contact the US Federal team, Federal [at] f5.com.To Pre-authenticate or Not to Pre-authenticate
I’m bouncing around in the friendly skies, (turbulence sucks!) on my way back from the Microsoft Exchange conference and one question keeps rolling around in my head; how important is pre-authentication? Granted, it may not be a very compelling topic to most but with the recent announcement of TMG’s end-of-life, it’s at least relevant. Along with other remote access / pre-authentication solutions, including F5’s Access Policy Manager, (APM) many organizations from SMBs to large enterprises have utilized Microsoft’s TMG, (Threat Management Gateway) to provide external pre-authentication for a variety of applications such as MS Exchange and SharePoint. In a nutshell, reverse-proxy with pre-authentication, (aka remote access) solutions act as a secure doorway on the perimeter of the organization and prevent un-authenticated and un-trusted traffic from accessing resources residing on the private internal corporate network. Now to be honest, there’s not much debate in my mind around the value provided by pre-authentication at the edge of the Network. However, discontinuing the use of pre-authentication entirely in the light of TMG’s demise was proposed as a possible solution. Disclaimer --> This is not an official Microsoft recommendation but rather the opinion expressed by an individual presenter. It’s also important to mention that while TMG will no longer be offered as a product after December 1, 2012, mainstream support will still continue into 2015 which should give current users sufficient time to investigate and implement alternative solutions, (such as APM). Now with that said, I think it would behoove us all to quickly review some of what remote access solutions provide the organization before we tear the door off its hinges. Isolation of Internal Domain-joined Resources As I already mentioned pre-authentication resides at the perimeter of the organization’s network and provides a layer of security further isolating internal resources from external access. Rather than allowing direct access to the internal resource, (an Exchange CAS server for example), only authenticated and authorized user connections will be able to pass into the corporate LAN. To provide a multi-layered perimeter security solution this functionality can be combined with other security systems such as IPS and layer 7 firewalls. Multi-factor Authentication I’ll leave it up to you the reader to determine the value of multi-factor authentication. Regardless, whether it’s username and password, certificates, hard/soft tokens, pre-defined security questions, adaptive auth, or any of the other various flavors of authentication methods available; many remote access solutions provide a much more secure authentication mechanism than what can be natively found on most applications. This is especially critical when we consider the vast and ever-growing number of devices organizations need to provide access for as a part of doing business. Endpoint Inspection To dovetail onto the previous comment, providing a username and password is simply not enough. In the age of BYOD, (Bring Your Own Device), an organization should not only have confidence in who the user is that’s accessing the corporate resource, (Exchange via ActiveSync for example) but have confidence that the device used to connect, (smartphone, corporate laptop, personal tablet, etc.) adheres to corporate policies. Some remote access solutions provide a means to identify and evaluate the client endpoint as part of the authentication/authorization process. For example, (here comes a shameless plug), utilizing APM on the F5 Big-IP with LTM can provide a means to manage access to corporate resources based upon the device trying to connect as well as ensuring the approved device adheres to corporate policies for such things as AV status, OS versions, patch levels, etc.. A Strategic Point of Control for Application Delivery Pre-authentication / reverse-proxies provide a central point to administer access to multiple applications. Consider the alternatives. Without a reverse-proxy / pre-authentication solution access must be configured and controlled separately at each internal resource. All too often these internal resources, (such as Microsoft Exchange and SharePoint), are administered by different individuals or groups. What’s more, independent access control makes applying corporate security policy consistently a challenge to say the least. On the contrary, implementing an application delivery controller like the F5 Big-IP with Access Policy Manager provides a strategic point of control where corporate applications can be deployed in a secure and consistent manner. End-User Experience It’s not all about security. An application delivery controller that provides, among other things, pre-authentication can improve the user experience. Deploying applications behind the Big-IP with APM can provide single sign-on access as well as advanced application delivery. For example, once authenticated at the Big-IP users can access various corporate applications such as SharePoint and Exchange, often from a single namespace, while only needing to provide credentials once and often from a single namespace. Latest F5 Information F5 News Articles F5 Press Releases F5 Events F5 Web Media F5 Technology Alliance Partners F5 YouTube FeedBig-IP and ADFS Part 4 – “What about Single Sign-Out?”
Why stop at 3 when you can go to 4? Over the past few posts on this ever-expanding topic, we’ve discussed using ADFS to provide single sign-on access to Office 365. But what about single sign-out? A customer turned me onto Tristan Watkins’ blog post that discusses the challenges of single sign-out for browser-based, (WS-Federation) applications when fronting ADFS with a reverse-proxy. It’s a great blog post and covers the topic quite well so I won’t bother re-hashing it here. However, I would definitely recommend reading his post if you want a deeper dive. Here’s the sign-out process: 1. User selects ‘Sign Out’ or ‘Sign in as Different User’, (if using SharePoint Online); 2. The user is signed out of the application; 3. The user is redirected to the ADFS sign out page; and 4. The user is redirected back to the Microsoft Federation Gateway and the user’s tokens are invalidated. In a nutshell, claims-unaware proxies, (Microsoft ISA and TMG servers for example) are unable to determine when this process has occurred and subsequently the proxy session remains active. This in turn will allow access to ADFS, (and subsequently Office 365) without be prompted for new credentials, (not good!). Here’s where I come clean with you dear readers. While the F5 Big-IP with APM is a recognized replacement for the AD FS 2.0 Federation Server Proxy this particular topic was not even on my radar. But now that it is…… Single Sign-Out with Access Policy Manager You’ll may have noticed that although the Big-IP with APM is a claims-unaware proxy I did not include it in the list above. Why you ask? Well, although the Big-IP is currently “claims-unaware”, it certainly is “aware” of traffic that passes through. With the ability to analyze traffic as it flows from both the client and the server side, the Big-IP can look for triggers and act upon them. In the case of the ADFS sign-out process, we’ll use the MSISSignOut cookie as our trigger to terminate the proxy session accordingly. During the WS-Federation sign out process, (used by browser-based applications) the MSISSignOut cookie is cleared out by the ADFS server, (refer to the HttpWatch example below). Once this has been completed, we need to terminate the proxy session. Fortunately, there’s an iRule for that. The iRule below analyzes the HTTP response back from the ADFS server and keys off of the MSISSignOut cookie. If the cookie’s value has been cleared, the APM session will be terminated. To allow for a clean sign-out process with the Microsoft Federation Gateway, the APM session termination is delayed long enough for the ADFS server to respond. Now, APM’s termination can act in concert with the ADFS sign-out process. 1: when HTTP_RESPONSE { 2: # Review server-side responses for reset of WS-Federation sign-out cookie - MSISSignOut. 3: # If found assign ADFS sign-out session variable and close HTTP connection 4: if {[HTTP::header "Set-Cookie"] contains "MSISSignOut=;"} { 5: ACCESS::session data set session.user.adfssignout 1 6: HTTP::close 7: } 8: } 9: 10: when CLIENT_CLOSED { 11: # Remove APM session if ADFS sign-out variable exists 12: if {[ACCESS::session data get session.user.adfssignout] eq 1} { 13: after 5000 14: ACCESS::session remove 15: } 16: } What? Another iRule? Actually, the above snippet can be combined with the iRule we implemented in Part 3 creating a single iRule addressing all the ADFS/Office 365 scenarios. 1: when HTTP_REQUEST { 2: # For external Lync client access all external requests to the 3: # /trust/mex URL must be routed to /trust/proxymex. Analyze and modify the URI 4: # where appropriate 5: HTTP::uri [string map {/trust/mex /trust/proxymex} [HTTP::uri]] 6: 7: # Analyze the HTTP request and disable access policy enforcement WS-Trust calls 8: if {[HTTP::uri] contains "/adfs/services/trust"} { 9: ACCESS::disable 10: } 11: 12: # OPTIONAL ---- To allow publishing of the federation service metadata 13: if {[HTTP::uri] ends_with "FederationMetadata/2007-06/FederationMetadata.xml"} { 14: ACCESS::disable 15: } 16: } 17: 18: when HTTP_RESPONSE { 19: # Review serverside responses for reset of WS-Federation sign-out cookie - MSISSignOut. 20: # If found assign ADFS sign-out session variable and close HTTP connection 21: if {[HTTP::header "Set-Cookie"] contains "MSISSignOut=;"} { 22: ACCESS::session data set session.user.adfssignout 1 23: HTTP::close 24: } 25: } 26: 27: when CLIENT_CLOSED { 28: # Remove APM session if ADFS sign-out variable exists 29: if {[ACCESS::session data get session.user.adfssignout] eq 1} { 30: after 5000 31: ACCESS::session remove 32: } 33: } Gotta love them iRules! That’s all for now. Additional Links: Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm” Big-IP and ADFS Part 2 – “APM–An Alternative to the ADFS Proxy” Big-IP and ADFS Part 3 – “ADFS, APM, and the Office 365 Thick Clients” BIG-IP Access Policy Manager (APM) Wiki Home - DevCentral Wiki AD FS 2.0 - Interoperability with Non-Microsoft Products MS TechNet - AD FS: How to Invoke a WS-Federation Sign-Out Tristan Watkins - Office 365 Single Sign Out with ISA or TMG as the ADFS Proxy Technorati Tags: load balancer,ADFS,Office365,active directory,F5,federation,exchange,microsoft,network,blog,APM,LTM,Coward,SSO,single sign-on,single sign-outVDI Gateway Federation with BIG-IP
Today let’s look at how F5 BIGIP APM can consolidate, secure and federate all the core VDI gateways technology. For instance, if an organization decides move from one VDI technology to another or if you’re consolidating VDI technologies, BIG-IP can help. On the BIG-IP we’ve set up three VDI environments. Microsoft RDS/RDP with a broker authentication server, VMware Horizon and Citrix XenApp. With only a corporate account, a user can authenticate to all of them as needed and access all available desktop content. In this example, we connect to the BIG-IP APM. This is the default view. And here we’ve put some advanced security fields like OTP or multifactor authentication for instance. So here we’d use our username and password and for additional security we'll choose a secondary grid. By default, a grid is not generally available from any of the VDI vendors. When we select grid, BIG-IP APM will present a grid for a PIN entry. This is provided through a partnership with Gemalto. BIG-IP is connecting to Gemalto servers to present the grid to the user. We then enter our confidential PIN. Upon auth, we’re presented with our BIG-IP APM Webtop and BIG-IP did the necessary single sign on for all the VDI technologies and environments assigned to us. With a single, multifactor authentication we’re able to gain access to our federated BIG-IP Webtop and select the specific VDI resource we need. From an administrative view, here is the full Visual Policy Editor (VPE) for the overall solution. This also shows where the OTP/Grid is if you follow the Host FQDN path. And here are the specific inspections and criteria for the VDI scenario. You can see a path for each VDI vendor along with specific inspections and actions depending on the situation. Special thanks to F5 Sr. Security SE Matthieu Dierick for the explanation and you can watch the demo video. ps
