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
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!
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 deploymentKerberos is Easy - Part 2
Yes my friends, this post has been long overdue. Life, work and all the other good excuses got in the way. However, there is nothing like a friend calling you out with a “WTF I need part 2” to get the motivation and kerberos mana flowing again. So where did we leave off? In part 1 we discussed some of the most common issues with Kerberos authentication and the necessity to break the problem down to client-side vs server-side authentication. In part 2 we will look at some of the first troubleshooting steps I take to determine why nothing is working - yes, this happens to me too. ADTest is Your New BF4L You know those people that open a web browser to see if their Internet works… yea, don’t be that person. Open a terminal, check if you can ping your gateway, public DNS server, etc. and then, only then, open a browser. ADTest is your equivalent of ping. Don’t assume because you configured an Active Directory AAA object that authentication is just going to work. Please open a console and verify that Kerberos authentication against the AD server is working with ADTest. Check out my APM Troubleshooting with ADTest for more information. Time is not on Your Side If you have worked with Kerberos before you know it is supper picky about time drift. If ADTest just won’t work and you can’t figure out why ensure the BIG-IP’s time matches the KDC. If you need to adjust the BIG-IP follow the F5 SOL3381. These Are Not the KDCs You’re Looking For Ever been in a multi-domain environment and the AD admin swears the KDC you’re talking to is the correct one; never mind the “Kerberos Principal Unknown” error you keep getting. So if ADTest doesn’t work then we need to ensure the AD server we’re talking to is a KDC for the expected realm. Now, if someone can RDP into the server this can be ruled out pretty quickly, but when in life is anything that easy. So it’s helpful to use nslookup to find all KDCs for the intended domain and ensure the IP you were give is in this list - example below: C:\Users\user>nslookup -type=SRV _kerberos._tcp.dc._msdcs.f5demo.com Server: ad1.f5demo.com Address: 10.1.10.2 _kerberos._tcp.dc._msdcs.f5demo.com SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ad1.f5demo.com ad1.f5demo.com internet address = 10.1.10.2 ad1.f5demo.com internet address = 10.1.1.3 Playing Go Fish with SPNs You have to admire how Microsoft took something as complicated as Kerberos and made it trivial to deploy and manage inside of Active Directory. Having managed MIT and MS version of Kerberos myself I felt a little guilty after setting up my first AD server without hours of troubleshooting issues. However, with that ease of use Microsoft also made it easy to shoot your own foot off if you have no basic understanding of Kerberos. Think of the KDC as a key, value pair database. The KDC will let you store multiple keys of the same value even though you shouldn’t do that. So if you have multiple SPN entries in AD you are not guarantied that a request for a ticket will return the value you’re looking for. This typically presents itself in APM as authentication works onetime and not the other. An easy way to check this is to log into a domain machine and issue: setspn -X This will print out any duplicate SPNs in your KDC. If the SPN you are working with appears in this list then you need to correct this issue. The easiest way I find is to delete the service account you have created for APM and just use the service account the web server application pool is using. Cached Tickets APM caches Kerberos tickets for both client side Kerberos authentication and server side Kerberos SSO. If you’re troubleshooting Kerberos be sure to clear these caches after you’ve made modifications. For Kerberos AAA: bigstart restart apd rba For Kerberos SSO: bigstart restart websso I’ll Just Do It Myself If you are working with Kerberos SSO then you have to sometimes determine if the issue is with APM obtaining the token or the web server not accepting the token. If you have your WebSSO logging set to debug and Kerberos SSO is working then you should see S4U=====>OK If not, then there are a few CLI commands you can use to simulate the request APM makes to the KDC. First, remove all kerberos tickets. kdestroy Second, obtain a kerberos ticket as the AD delegation account (if this works you won’t get a response) kinit -f <SPN of AD delegation account> Finally, test if the ticket you obtain has delegation capabilities knvo -C -U <username> <SPN of AD delegation account> If you receive a key version number on the kvno command then everything is working and it proves that ASREQ and RSREQ work. So the issue more than likely is on the web server side and not the F5 - more on this in part 3.US 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.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.Single Sign-On (SSO) to Legacy Web Apps Using BIG-IP & VMware Workspace ONE
A few months back VMware announced a joint collaborative effort on delivering even more applications to their Workspace One suite utilizing F5 BIG-IP APM to act as an authentication translator from SAML to legacy Kerberos and header-based web applications. How does it work? VMware Workspace ONE acts as an identity provider (IDP) that provides SSO access to cloud, mobile and SAML applications. F5 BIG-IP APM extends that functionality and as a service provider (SP) to Workspace ONE for Kerberos and header-based web applications. BIG-IP APM can take in a user’s SSO authentication credential (SAML assertion) from Workspace ONE and authenticate as that user into BIG-IP APM. Once the Authentication is completed BIG-IP APM will create a Kerberos Constrained Delegation (KCD) or header-based authentication using the user’s Realm (Domain). BIG-IP APM will then pass the authentication token to the legacy web application on behalf of the user. This will prevent the pop-up login dialog boxes from appearing and providing a seamless authentication from Workspace ONE to the legacy web application. BIG-IP can provide intelligent traffic management, high availability, secure SSL access through bridging or offloading, and monitoring using BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS (Formerly BIG-IP GTM). BIG-IP's Access Policy Manager (APM) can also provide secure access to the apps and resources accessible through the Workspace ONE portal. You can now download the updated step-by-step guide for integrating VMware Workspace ONE and BIG-IP APM for Legacy Web applications. https://www.vmware.com/pdf/vidm_implementing_SSO_to_kdc-and-hb_apps.pdf. You can also read more about this integration from VMware’s publishing’s from Ben Siler discussing the integration. https://blogs.vmware.com/euc/2016/10/single-sign-on-sso-legacy-apps-workspace-one-f5.html F5 has also provided a brief video talking and showing this integration in action Click the link below to see the video. https://devcentral.f5.com/s/articles/lightboard-lessons-sso-to-legacy-web-applications-24410 Here is an snipping from the documentation on setting up Kerberos within F5 APM. Setting up Kerberos Constrained Delegation (KCD) in BIG-IP APM If you are integrating a KCD app, you should now set up KCD in APM. Open the F5 BIG-IP admin console. Click Access Policy > SSO Configurations > Kerberos > plus icon ( +). In the New SSO Configuration menu, click Kerberos. Enter a unique name for your KDC SSO Configuration Set the Username Source field to session.sso.token.last.username Set the User Realm Source field to session.ad.last.actualdomain Set the Kerberos Realm field to your active directory domain (in CAPS). Set the Account Name field to your Kerberos service account and enter your account password. Note: If a Kerberos Service Account hasn’t been created it is recommended to create one via the following documentation. https://www.f5.com/pdf/deployment-guides/kerberos-constrained-delegation-dg.pdf Set the Account Password and Confirm Account Password fields with the Password associated to the Kerberos service account. Leave all other non-required fields with the default settings. (Required fields have a blue line) . Click Finished. Setting up Domain Authentication In the BIG-IP admin console, click Access Policy > AAA Servers > Active Directory > plus Icon ( + ). Enter a friendly name in the Name field. Set the Domain Name field to your Active Directory Domain Name (FQDN). Set the Server Connection radio button to Use Pool to increase resiliency. Set the Domain Controller Pool Name to a friendly name for your pool (no spaces allowed). Set the IP Address field to the IP Address of your domain controller. Set the Hostname field to the short name for your domain controller. Click Add, to add the domain controller to your pool. Repeat steps iv, v, and vi for each domain controller you want to add to the pool. Set the server pool monitor drop-down to gateway_icmp. Set the Admin Name field to your domain admin user. Set the Admin Password field to your domain admin’s password. Set the Group Cache Lifetime field to 30 days. Set the Password Security Object Cache Lifetime to 30 days. Click Finished. Special Thanks to Ben Siler, Paul Pindell, Peter Silva and Cody Green for all of their assistance putting this together!Lightboard Lessons: Basic Kerberos Authentication
In this Lightboard Lesson, I kick off a three-part series on Kerberos authentication, starting with the basic authentication messaging. Stay tuned for delegation and protocol transitions in part two, and then I'll wrap the Kerberos series with application to the BIG-IP Access Policy Manager.
