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!
5 Years Later: OpenAJAX Who?
Five years ago the OpenAjax Alliance was founded with the intention of providing interoperability between what was quickly becoming a morass of AJAX-based libraries and APIs. Where is it today, and why has it failed to achieve more prominence? I stumbled recently over a nearly five year old article I wrote in 2006 for Network Computing on the OpenAjax initiative. Remember, AJAX and Web 2.0 were just coming of age then, and mentions of Web 2.0 or AJAX were much like that of “cloud” today. You couldn’t turn around without hearing someone promoting their solution by associating with Web 2.0 or AJAX. After reading the opening paragraph I remembered clearly writing the article and being skeptical, even then, of what impact such an alliance would have on the industry. Being a developer by trade I’m well aware of how impactful “standards” and “specifications” really are in the real world, but the problem – interoperability across a growing field of JavaScript libraries – seemed at the time real and imminent, so there was a need for someone to address it before it completely got out of hand. With the OpenAjax Alliance comes the possibility for a unified language, as well as a set of APIs, on which developers could easily implement dynamic Web applications. A unified toolkit would offer consistency in a market that has myriad Ajax-based technologies in play, providing the enterprise with a broader pool of developers able to offer long term support for applications and a stable base on which to build applications. As is the case with many fledgling technologies, one toolkit will become the standard—whether through a standards body or by de facto adoption—and Dojo is one of the favored entrants in the race to become that standard. -- AJAX-based Dojo Toolkit , Network Computing, Oct 2006 The goal was simple: interoperability. The way in which the alliance went about achieving that goal, however, may have something to do with its lackluster performance lo these past five years and its descent into obscurity. 5 YEAR ACCOMPLISHMENTS of the OPENAJAX ALLIANCE The OpenAjax Alliance members have not been idle. They have published several very complete and well-defined specifications including one “industry standard”: OpenAjax Metadata. OpenAjax Hub The OpenAjax Hub is a set of standard JavaScript functionality defined by the OpenAjax Alliance that addresses key interoperability and security issues that arise when multiple Ajax libraries and/or components are used within the same web page. (OpenAjax Hub 2.0 Specification) OpenAjax Metadata OpenAjax Metadata represents a set of industry-standard metadata defined by the OpenAjax Alliance that enhances interoperability across Ajax toolkits and Ajax products (OpenAjax Metadata 1.0 Specification) OpenAjax Metadata defines Ajax industry standards for an XML format that describes the JavaScript APIs and widgets found within Ajax toolkits. (OpenAjax Alliance Recent News) It is interesting to see the calling out of XML as the format of choice on the OpenAjax Metadata (OAM) specification given the recent rise to ascendancy of JSON as the preferred format for developers for APIs. Granted, when the alliance was formed XML was all the rage and it was believed it would be the dominant format for quite some time given the popularity of similar technological models such as SOA, but still – the reliance on XML while the plurality of developers race to JSON may provide some insight on why OpenAjax has received very little notice since its inception. Ignoring the XML factor (which undoubtedly is a fairly impactful one) there is still the matter of how the alliance chose to address run-time interoperability with OpenAjax Hub (OAH) – a hub. A publish-subscribe hub, to be more precise, in which OAH mediates for various toolkits on the same page. Don summed it up nicely during a discussion on the topic: it’s page-level integration. This is a very different approach to the problem than it first appeared the alliance would take. The article on the alliance and its intended purpose five years ago clearly indicate where I thought this was going – and where it should go: an industry standard model and/or set of APIs to which other toolkit developers would design and write such that the interface (the method calls) would be unified across all toolkits while the implementation would remain whatever the toolkit designers desired. I was clearly under the influence of SOA and its decouple everything premise. Come to think of it, I still am, because interoperability assumes such a model – always has, likely always will. Even in the network, at the IP layer, we have standardized interfaces with vendor implementation being decoupled and completely different at the code base. An Ethernet header is always in a specified format, and it is that standardized interface that makes the Net go over, under, around and through the various routers and switches and components that make up the Internets with alacrity. Routing problems today are caused by human error in configuration or failure – never incompatibility in form or function. Neither specification has really taken that direction. OAM – as previously noted – standardizes on XML and is primarily used to describe APIs and components - it isn’t an API or model itself. The Alliance wiki describes the specification: “The primary target consumers of OpenAjax Metadata 1.0 are software products, particularly Web page developer tools targeting Ajax developers.” Very few software products have implemented support for OAM. IBM, a key player in the Alliance, leverages the OpenAjax Hub for secure mashup development and also implements OAM in several of its products, including Rational Application Developer (RAD) and IBM Mashup Center. Eclipse also includes support for OAM, as does Adobe Dreamweaver CS4. The IDE working group has developed an open source set of tools based on OAM, but what appears to be missing is adoption of OAM by producers of favored toolkits such as jQuery, Prototype and MooTools. Doing so would certainly make development of AJAX-based applications within development environments much simpler and more consistent, but it does not appear to gaining widespread support or mindshare despite IBM’s efforts. The focus of the OpenAjax interoperability efforts appears to be on a hub / integration method of interoperability, one that is certainly not in line with reality. While certainly developers may at times combine JavaScript libraries to build the rich, interactive interfaces demanded by consumers of a Web 2.0 application, this is the exception and not the rule and the pub/sub basis of OpenAjax which implements a secondary event-driven framework seems overkill. Conflicts between libraries, performance issues with load-times dragged down by the inclusion of multiple files and simplicity tend to drive developers to a single library when possible (which is most of the time). It appears, simply, that the OpenAJAX Alliance – driven perhaps by active members for whom solutions providing integration and hub-based interoperability is typical (IBM, BEA (now Oracle), Microsoft and other enterprise heavyweights – has chosen a target in another field; one on which developers today are just not playing. It appears OpenAjax tried to bring an enterprise application integration (EAI) solution to a problem that didn’t – and likely won’t ever – exist. So it’s no surprise to discover that references to and activity from OpenAjax are nearly zero since 2009. Given the statistics showing the rise of JQuery – both as a percentage of site usage and developer usage – to the top of the JavaScript library heap, it appears that at least the prediction that “one toolkit will become the standard—whether through a standards body or by de facto adoption” was accurate. Of course, since that’s always the way it works in technology, it was kind of a sure bet, wasn’t it? WHY INFRASTRUCTURE SERVICE PROVIDERS and VENDORS CARE ABOUT DEVELOPER STANDARDS You might notice in the list of members of the OpenAJAX alliance several infrastructure vendors. Folks who produce application delivery controllers, switches and routers and security-focused solutions. This is not uncommon nor should it seem odd to the casual observer. All data flows, ultimately, through the network and thus, every component that might need to act in some way upon that data needs to be aware of and knowledgeable regarding the methods used by developers to perform such data exchanges. In the age of hyper-scalability and über security, it behooves infrastructure vendors – and increasingly cloud computing providers that offer infrastructure services – to be very aware of the methods and toolkits being used by developers to build applications. Applying security policies to JSON-encoded data, for example, requires very different techniques and skills than would be the case for XML-formatted data. AJAX-based applications, a.k.a. Web 2.0, requires different scalability patterns to achieve maximum performance and utilization of resources than is the case for traditional form-based, HTML applications. The type of content as well as the usage patterns for applications can dramatically impact the application delivery policies necessary to achieve operational and business objectives for that application. As developers standardize through selection and implementation of toolkits, vendors and providers can then begin to focus solutions specifically for those choices. Templates and policies geared toward optimizing and accelerating JQuery, for example, is possible and probable. Being able to provide pre-developed and tested security profiles specifically for JQuery, for example, reduces the time to deploy such applications in a production environment by eliminating the test and tweak cycle that occurs when applications are tossed over the wall to operations by developers. For example, the jQuery.ajax() documentation states: By default, Ajax requests are sent using the GET HTTP method. If the POST method is required, the method can be specified by setting a value for the type option. This option affects how the contents of the data option are sent to the server. POST data will always be transmitted to the server using UTF-8 charset, per the W3C XMLHTTPRequest standard. The data option can contain either a query string of the form key1=value1&key2=value2 , or a map of the form {key1: 'value1', key2: 'value2'} . If the latter form is used, the data is converted into a query string using jQuery.param() before it is sent. This processing can be circumvented by setting processData to false . The processing might be undesirable if you wish to send an XML object to the server; in this case, change the contentType option from application/x-www-form-urlencoded to a more appropriate MIME type. Web application firewalls that may be configured to detect exploitation of such data – attempts at SQL injection, for example – must be able to parse this data in order to make a determination regarding the legitimacy of the input. Similarly, application delivery controllers and load balancing services configured to perform application layer switching based on data values or submission URI will also need to be able to parse and act upon that data. That requires an understanding of how jQuery formats its data and what to expect, such that it can be parsed, interpreted and processed. By understanding jQuery – and other developer toolkits and standards used to exchange data – infrastructure service providers and vendors can more readily provide security and delivery policies tailored to those formats natively, which greatly reduces the impact of intermediate processing on performance while ensuring the secure, healthy delivery of applications. API Jabberwocky: You Say Tomay-to and I Say Potah-to OpenAjax Metadata 1.0 and the Adobe Dreamweaver Widget Browser OpenAjax Alliance AJAX-based Dojo Toolkit The Stealthy Ascendancy of JSON JSON Continues its Winning Streak Over XML JSON versus XML: Your Choice Matters More Than You Think I am in your HTTP headers, attacking your application The Web 2.0 API: From collaborating to compromised IT as a Service: A Stateless Infrastructure Architecture Model JSON Activity Streams and the Other Consumerization of IT
APM Cookbook: SAML IdP Chaining
As an APM subject mater expert at F5 I often find myself in situations where a customer or colleague needs an example of a particular configuration. While most of these requests are easily handled with a call or WebEx I'm a firm believer in sharing knowledge through documentation.. and I don't like getting calls at 3 AM. If you're like me you grew up with the O'Reilly Cookbook series which served as a great reference document for various development or server configuration tasks. My goal is to create a similar reference resource here on DevCentral for those one-off scenarios where a visual example may help your complete your task. For the first APM Cookbook series I'll discuss SAML IdP chaining. Overview Security Assertion Markup Language, more commonly known as SAML, is a popular federated authentication method that provides web based single sign-on. One of the key security advantages to SAML is the reduction in username/password combinations that a user has remember... or in my experience as a security engineer the number of passwords written on a post-it note stuck to their monitor. There are two major services in a SAML environment: IdP - Identity Provider SP - Service Provider The identity provider is the SAML service that authenticates the user and passes an assertion to then service providers proving the user's identity. F5's APM performs both IdP and SP services and allows customers to easily deploy federated authentication in their environment. In more complex scenarios you may run across a requirement where multiple SAML IdPs need to be chained together. This comes up from time to time when customers have contractors that utilize federated authentication for authorization to corporate resources. Example For our configuration we have the Globex Corporation that uses APM to authenticate uses to Office 365. Globex hire contractors from Acme Corp. who authenticate using the Acme Corp. ADFS environment. However, since Office 365 is configured to authenticate against the Globex APM we need to convert the Acme Corp. SAML assertion into a Globex SAML assertion, which is known as IdP chaining. The step ladder for this process is shown below: 1. User requests https://outlook.com/globex.com 2 - 3. Office 365 redirects user to idp.globex.com 3 - 4. idp.globex.com determines user is a contractor and redirect user to sts.acme.com 5 - 8. User authenticates using Acme credentials and is then redirect back to idp.globex.com 9. idp.globex.com consumes the Acme SAML assertion and creates a Globex SAML assertion 10. User is redirected back to Office 365 11 - 12. Office 365 consumes the Globex SAML assertion and displays the user's mail Configuration To configure your APM SAML IdP to accept incoming assertion from sts.acme.com we need to create an external SP connector. Under the Access Policy -> SAML -> BIG-IP as SP configuration section: 1. Create a new SAML SP Service 2. Export the SP metadata and configure sts.acme.com accordingly (follow your IdP vendor's documentation) 3. Click the External IdP Connectors menu at the top 4. Click the dropdown arrow on the create button and choose From Metadata (import the metadata from sts.acme.com) 5. Bind the Local SP service to the external IdP connector Now that idp.globex.com and sts.acme.com are configured to trust one another we need to configure the APM IdP to consume the sts.acme.com SAML assertion. The IdP's Visual Policy Editor should look similar to the image below: 1. The Decision Box asks the user what company they're with. This is a simple example but more elaborate home realm discovery techniques can be used. 2. The SAML Auth box is configured to consume the sts.acme.com assertion 3. Since we no longer have a login form on the IdP we need to set a few APM session variables: session.logon.last.username = Session Variable session.saml.last.identity session.logon.last.logonname = Session Variable session.saml.last.identity 4. Create an Advanced Resource Assign that matches your existing IdP Advance Resource Assign. Conclusion This particular post was a little longwinded due to the steps required but overall is a fairly simple configuration. So the next time someone asks if your F5 can do IdP chaining you can confidently reply "Yes and I know how to do that".The all new iRules Wiki brings you enhanced documentation and more!
Editors note: The iRules Wiki moved to F5's CloudDocs platform in May of 2019. iRules Home (f5.com) DevCentral is all about enabling users in the community to do powerful and innovative things. Whether it’s providing answers to your technical questions in the Forums, giving you the latest up to date news about F5, or providing documentation on some of the coolest things F5 has to offer, like iRules and iControl, we do our best to keep you up to speed, and equipped to get the most out of your F5 devices. With that in mind, we’ve been working hard to heed the call from the members of the community, partners, and the entire F5 global team for extended and enhanced documentation about iRules. Well we’re quite happy to announce the DevCentral iRules Wiki! - http://clouddocs.f5.com/api/irules/. This new section of DevCentral, intended to be a constant work in progress, represents the most comprehensive, advanced documentation of the iRules language available to date. Whether you’re just getting started, or you’re, there’s something there for everyone. And regardless of your skill level, the CodeShare is sure to have some cool examples of what you can do, and what others are currently doing with iRules. It’s also a place to share your cool ideas with others! Why? Well, the more people share, the more likely you’ll be able to find the perfect iRule sample when you need it most at some point in the future. By working together, the community can benefit from the collective experience contributed by all members. Our real goal in providing this sort of documentation, though, is to provide the tools you need to truly leverage F5’s solutions in your environment. That’s what this Wiki is all about. With this addition we hope to: Offer additional resources beyond the Forums for iRule information. We love talking to you in the Forums, but sometimes you just want the facts, fast. Provide enhanced documentation in a centralized location. We want to make it easier to find more of what you want, when you want it. Increase your success with iRules by enabling you to find what you need to succeed.The better we can make you look, the happier we are…seriously. So check it out, poke around, and let us know what you think. We’re constantly striving to make this a better place for you to come together to learn, discuss and share, whether it’s about iRules or any of the other things happening on DevCentral so feedback is always welcome.
How is SDN disrupting the way businesses develop technology?
You must have read so much about software-defined networking (SDN) by now that you probably think you know it inside and out. However, such a nascent industry is constantly evolving and there are always new aspects to discover and learn about. While much of the focus on SDN has focused on the technological benefits it brings, potential challenges are beginning to trouble some SDN watchers. While many businesses acknowledge that the benefits of SDN are too big to ignore, there are challenges to overcome, particularly with the cultural changes that it brings. In fact, according to attendees at the Open Networking Summit (ONS) recently the cultural changes required to embrace SDN outweigh the technological challenges. One example, outlined in this TechTarget piece, is that the (metaphorical) wall separating network operators and software developers needs to be torn down; network operators need coding skills and software developers will need to be able to program networking services into their applications. That’s because SDN represents a huge disruption to how organisations develop technology. With SDN, the speed of service provisioning is dramatically increased; provisioning networks becomes like setting up a VM... a few clicks of the button and you’re done. This centralised network provision means the networking element of development is no longer a bottleneck; it’s ready and available right when it’s needed. There’s another element to consider when it comes to SDN, tech development and its culture. Much of what drives software-defined networking is open source, and dealing with that is something many businesses may not have a lot of experience with. Using open source SDN technologies means a company will have to contribute something back to the community - that’s how open source works. But for some that may prove to be a bit of an issue: some SDN users such as banks or telecoms companies may feel protective of their technology and not want is source code to be released to the world. But that is the reality of the open source SDN market, so it is something companies will have to think carefully about. Are the benefits of SDN for tech development worth going down the open source route? That’s a question only the companies themselves can answer. Software-defined networking represents a huge disruption to the way businesses develop technology. It makes things faster, easier and more convenient during the process and from a management and scalability point of view going forward. There will be challenges - there always are when disruption is on the agenda - but if they can be overcome SDN could well usher in a new era of technological development.Deploying F5 BIG-IP in Windows Server Hyper-V for Developers
F5’s BYOL (Bring Your Own License) model allows you to purchase a developer/lab license and deployinto your Microsoft Hyper-V environment. This provides a stable development instance for the following software components of BIG-IP: LTM, GTM, DNS, AFM, ASM, APM Lite (10 users), AAM, CGN, SSL Forward Proxy, Advanced Protocols, and Crypto Offload all at a 10Mbps rate limit. Please refer to these resources to get started with Microsoft Hyper-V How to get a F5 BIG-IP VE Developer Lab License F5 BIG-IP Virtual Edition Setup Guide for Microsoft Hyper-V @ support.f5.com Hyper-V Overview @ Microsoft Technet NOTE: For Development and Lab environments, DevCentral recommends 2 logical processors and no less than 4GB RAM, preferring 8GB. This will allow you to run more than one BIG-IP software module at a time, i.e. BIG-IP DNS & LTM. As you change development requirements you can enable and disable other modules within the Developer Lab license as needed. You can even build multiple environments and enable different modules accordingly using multiple Developer Lab licenses. For staging and production environments, follow F5 recommended guidelines; DevCentral recommendations are for development and sandbox environments.
Leveraging BIG-IP APM for seamless client NTLM Authentication
Many customers express interest to use F5 Access Policy Manager for transparent seamless authentication for their users. There are a couple of leading use cases that drive that desired behavior: Providing silent seamless authentication to Windows-based applications such as Exchange or Sharepoint from the domain-joined machines. The premise is is that if the user is logged in to their domain-joined machine, no matter where they are, they should be able to perform seamless NTLM authentication to their applications such as Sharepoint based on the Windows Integrated Authentication settings. Providing SAML Identity Provider services with APM. When users access SAML-enabled applications, they are asking for SAML assertions. Because APM can act as either native SAML 2.0 IDP or as a proxy to other SAML IDPs such as ADFS, for example, customer desire silent authentication to those IDP services from the domain-joined machines in order to seamlessly enable to SaaS applications such as Office 365, SalesForce.com, Google Apps, etc. APM can perform three types of 401-based challenge authentication: Basic, NTLM, and Kerberos. Basic always requires user’s intervention, but Kerberos and NTLM can enable users to seamlessly authenticate to the APM virtual server and allow it to either securely proxy connection to the backend application such as Sharepoint, leveraging Kerberos Constrained Delegation as the SSO mechanism, or acting as SAML IDP and issuing assertions to the SAML Service Providers based upon user identity extracted during NTLM authentication or Kerberos ticket. Today, we are going to examine the second use case on how to configure APM to perform client NTLM authentication and use it in the context of sending a SAML assertion to the Office 365 service. It is assumed below that user knows how to configure APM for standard forms-based authentication and also has at least one existing policy(although you can create a new one from the scratch). One of the easiest ways to test this is to deploy the Office 365 configuration using the iApp and the modify configuration to enable NTLM authentication. The steps below assume that you either have a working Office 365 configuration based on the iApp, or you have an equivalent policy that you can modify. First, and foremost, we need to create an NTLM Machine Account object. Under Access Policy, go to Access Profiles->NTLM->Machine Account, and click on Create to join the BIG-IP to the domain and create unique computer object in Active Directory Keep in mind that you will need to create a unique account in Active Directory for your BIG-IP. In the example above, the account name is bigip1. Create a “NTLM Auth Configuration” using the above machine account name. Under Access Policy, go to Access Profiles->NTLM->NTLM Auth Configuration and click on Create. Give the configuration the name, select the Machine Account Name value based on the object you created in Step 1, and add as many FQDNs for the AD domain controllers in your infrastructure Now we need to create an iRule that will help us handle NTLM authentication to the BIG-IP properly. You need to modify the sec on cline of the RULE_INIT event to match the name of the NTLM Auth configuration you created in step 2. You will also need to replace all instances of appname with a unique identifier. Go to Local Traffic->iRules->iRules List and click on Create. Give the iRule name of “ntlm-auth-iRule” and paste the iRule into the BIG-IP: when RULE_INIT { set static::appname_ntlm_retries 2 set static::appname_ntlm_config "/Common/appname_ntlm_config" set static::appname_access_log_prefix "01490000:7:" set static::appname_ntlm_on_demand_prfx "$static::appname_access_log_prefix \[NTLM-ON-DEMAND\]" } when ACCESS_SESSION_STARTED { ACCESS::session data set "session.ntlm.last.retries" 0 } when HTTP_REQUEST { log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx Request: [HTTP::uri]" switch -glob -- [string tolower [HTTP::uri]] { "/ntlm/auth" { set sid [ACCESS::session sid] log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx sid: $sid" set referer [HTTP::header value Referer] log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx Referer: $referer" set x_session_id [ HTTP::header value X-Session-Id ] if { [ string length $x_session_id ] != 0 } { set sid $x_session_id } set retries [ACCESS::session data get -sid $sid "session.ntlm.last.retries"] log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx retries: $retries" set auth_result [ACCESS::session data get -sid $sid "session.ntlm.last.result"] log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx auth result: $auth_result" if { ($auth_result == 1) || ($retries == $static::appname_ntlm_retries) && ($auth_result != 1) } { ECA::disable log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx Redirect to: $referer" HTTP::redirect "$referer" } else { ECA::enable ECA::select select_ntlm:$static::appname_ntlm_config } unset x_session_id unset referer } default { ECA::disable } } } when CLIENT_ACCEPTED { set second_pass pass[IP::client_addr][TCP::client_port] # Check if this is the first or second time passing through this virtual if { [ table lookup $second_pass ] == "1" } { set wait_timeout 3000 set wait_delay 100 set wait_total 0 set disable_ssl disablessl[IP::client_addr][TCP::client_port] # Wait for SERVER_CONNECTED event to complete while { [ table lookup $disable_ssl ] != 0 && [ table lookup $disable_ssl ] != 1 && $wait_total < $wait_timeout } { set wait_total [ expr "$wait_total + $wait_delay" ] after $wait_delay } unset wait_delay wait_timeout # Check table value set by SERVER_CONNECTED to disable ssl set disable_ssl_value [ table lookup $disable_ssl ] if { $disable_ssl_value == "1" } { set command "SSL::disable" eval $command unset command } elseif { $disable_ssl_value != 0 } { log -noname accesscontrol.local1.notice "$static::appname_ntlm_on_demand_prfx Error: SERVER_CONNECTED event not completed after $wait_total ms" } table delete $disable_ssl table delete $second_pass unset disable_ssl wait_total } else { # This is the first time through this virtual. Set clientssl flag set client_ssl clientssl[IP::client_addr][TCP::client_port] if { [ catch { PROFILE::clientssl name } ] } { table add $client_ssl "0" } else { table add $client_ssl "1" } unset client_ssl } unset second_pass } when SERVER_CONNECTED { set client_ssl clientssl[IP::client_addr][TCP::client_port] set disable_ssl_value 0 # Check clientssl flag set from CLIENT_ACCEPTED. if { [ table lookup $client_ssl ] == "1" } { if { [ catch { PROFILE::serverssl name } ] } { # Clientssl is present but serverssl is not. Disable clientssl set disable_ssl_value 1 } table delete $client_ssl } set disable_ssl disablessl[IP::client_addr][TCP::client_port] table add $disable_ssl $disable_ssl_value unset disable_ssl unset client_ssl disable_ssl_value } when ECA_REQUEST_ALLOWED { log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx NTLM Auth succeed" ACCESS::session data set session.ntlm.last.username "[ECA::username]" ACCESS::session data set session.ntlm.last.domainname "[ECA::domainname]" ACCESS::session data set session.ntlm.last.machinename "[ECA::client_machine_name]" ACCESS::session data set session.ntlm.last.status "[ECA::status]" ACCESS::session data set session.ntlm.last.result 1 ACCESS::disable HTTP::header insert X-Session-Id $sid log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx use virtual: [ virtual name ]" # Set flag for next CLIENT_ACCEPTED telling it that it is the second pass through virtual set second_pass pass[IP::client_addr][TCP::client_port] table add $second_pass "1" unset second_pass # Connect to itself in order to generate HTTP response use virtual [ virtual name ] } when ECA_REQUEST_DENIED { log -noname accesscontrol.local1.debug "$static::appname_ntlm_on_demand_prfx NTLM Auth succeed" if { [ACCESS::session data get session.ntlm.last.retries] != $static::appname_ntlm_retries } { incr retries ACCESS::session data set session.ntlm.last.retries $retries } } After creating this iRule, assign it to the APM Virtual Server. Now you can create or modify your existing policy as below. Let’s examine how the policy depicted below is structured. The assumption is that the policy is going to be used to authenticate both internal and external users. If the users are coming in from the internal corporate network, we want to steer them straight to the NTLM authentication, if not, we want to use forms-based login for to authenticate them. I’ve started the policy with IP Subnet Match action to steer clients from certain networks to the NTLM authentication. One the desired source networks are matched, we move on to an External Login Page object that will send user back to the APM virtual and request NTLM authentication. Let’s examine how the policy depicted above is structured. The assumption is that the policy is going to be used to authenticate both internal and external users. If the users are coming in from the internal corporate network, we want to steer them straight to the NTLM authentication, if not, we want to use forms-based login for to authenticate them. I’ve started the policy with IP Subnet Match action to steer clients from certain networks to the NTLM authentication. Once the desired source networks are matched, we create an External Login Page object that will send user back to the APM virtual and request NTLM authentication. After sending the user to the “external login page”, which in fact is just a request to the same virtual server that is handled by the iRule that enables NTLM authentication between the client and BIG-IP, we need to check the status of the NTLM authentication, so we add the “NTLM Auth Result Check” action to see if the NTLM authentication was successful. If so, we need to populate the username session variable to enable APM to use it in session reporting/tracking, SAML assertion, SSO, etc. Now you can assign necessary resources to the user session. In this example, we are assigning APM to act as the IDP to Office 365. After you finished creating or modifying the Access Policy, make sure it is assigned to the APM virtual. Now we need to associate a ECA profile with the Virtual Server in order to enable NTLM functionality. This assignment needs to be performed via the command line. Establish an SSH connection in the box and enter TMSH and type the following commands, substituting the name of your virtual server for the highlighted portion /sys modify /ltm virtual NTLM-AUTH-vs profiles add { eca } save config list /ltm virtual NTLM-AUTH-vs Note the ‘eca’ profile associated with the virtual server 6. Next, we need to modify how the virtual server handles preservation of the original source port of the connection. This can be done either from the BIG-IP Administrative interface, or from the command line. Both examples are shown below. Command Line Interface Using the same SSH session as established in Step 5, type the following commands substituting the name of your virtual server for the highlighted portion: modify /ltm virtual NTLM-AUTH-vs source-port preserve-strict save /sys config BIG-IP Administrative Interface From the main menu, go to Local Traffic > Virtual Servers > Virtual Server List. Click on the APM virtual server. Under Configuration, select Advanced. For Source Port, select Preserve Strict. Click Update.” 7. Last, but not least, you need ensure that the machine you’re using to achieve the silent sign-on has the APM Virtual FQDN added to its Local Intranet zone as per the picture below. Voila! You should be all set. Point your browser on the machine to the FQDN of the APM Virtual Server where you assigned the new policy and iRule, and you should be silently authenticated. If you are interested in performing SSO to applications such as Sharepoint, you will need to setup Kerberos SSO in order to perform single sign-on to the Sharepoint based on the NTLM authentication.X-Forwarded-For HTTP Module For IIS7, Source Included!
For those who of you that are having problems with logging client addresses in their server logs because you are running your web servers behind a proxy of some sort, never fear, your solution is here. For those that don't, I already discussed in my previous posts about what the X-Forwarded-For header is so feel free to click back into those to read about it. History Back in September, 2005 I wrote and posted a 32-bit ISAPI filter that extracted the X-Forwarded-For header value and replaced the c-ip value (client ip) that is stored in the server logs. Lots of folks have found this useful over time and I was eventually asked for a 64-bit version which I posted about in August, 2009. The Question Well, it looks like it's time for the next generation for this filter… I received an email from a colleague here at F5 telling me that his customer didn't want to deploy any more ISAPI filters in their IIS7 infrastructure. IIS7 introduced the concept of IIS Modules that are more integrated into the whole pipeline and was told that Microsoft is recommending folks move in that direction. I was asked if I had plans to port my ISAPI filter into a HTTP Module. The Answer Well, the answer was "probably not", but now it's changed to a "yes"! The Solution In reading about IIS Module, I found that you can develop in managed (C#/VB) or Native (C++) code. I loaded up the test C# project to see if I could get it working. In a matter of minutes I had a working module that intercepted the event when logging occurs. The only problem was that from managed code, I could find no way to actually modify the values that were passed to the logging processor. This was a problem so I scrapped that and moved to a native C++ module. After a little while of jumping through the documentation, I found the things I needed and pretty soon I had a working HTTP module that implemented the same functionality as the ISAPI filter. Download The new Http Module hasn't had much testing done so please test it out before you roll it out into production. I've made the source available as well if you find an issue and care to fix it. Just make sure you pass back the fixes to me B-). X-Forwarded-For Http Module Binary Distribution X-Forwarded-For Http Module Source Distribution The filter will require installation into IIS in order for you to be able to add it to your applications. Both distributions include a readme.txt file with an example installation procedure. Make sure you use the Release builds for the appropriate platform (x86 or x64) unless you are in need of some troubleshooting as the Debug build will dump a lot of data to a log file. The module supports customizable headers if you are using something other than X-Forwarded-For. Instructions for using that are in the readme.txt file as well. If you have any issues with using this, please let me know on this blog. Keep in mind that this is an unsupported product, but I'll do my best to fix any issues that come up. I'm even open to enhancements if you can think of any. Enjoy! -JoeX-Forwarded-For Log Filter for Windows Servers
For those that don't know what X-Forwarded-For is, then you might as well close your browser because this post likely will mean nothing to you… A Little Background Now, if you are still reading this, then you likely are having issues with determining the origin client connections to your web servers. When web requests are passed through proxies, load balancers, application delivery controllers, etc, the client no longer has a direct connection with the destination server and all traffic looks like it's coming from the last server in the chain. In the following diagram, Proxy2 is the last hop in the chain before the request hits the destination server. Relying on connection information alone, the server thinks that all connections come from Proxy2, not from the Client that initiated the connection. The only one in the chain here who knows who the client really is (as determined by it's client IP Address, is Proxy1. The problem is that application owners rely on source client information for many reasons ranging from analyzing client demographics to targeting Denial of Service attacks. That's where the X-Forwarded-For header comes in. It is non-RFC standard HTTP request header that is used for identifying the originating IP address of a client connecting to a web server through a proxy. The format of the header is: X-Forwarded-For: client, proxy1, proxy, … X-Forwarded-For header logging is supported in Apache (with mod_proxy) but Microsoft IIS does not have a direct way to support the translation of the X-Forwarded-For value into the client ip (c-ip) header value used in its webserver logging. Back in September, 2005 I wrote an ISAPI filter that can be installed within IIS to perform this transition. This was primarily for F5 customers but I figured that I might as well release it into the wild as others would find value out of it. Recently folks have asked for 64 bit versions (especially with the release of Windows 2008 Server). This gave me the opportunity to brush up on my C skills. In addition to building targets for 64 bit windows, I went ahead and added a few new features that have been asked for. Proxy Chain Support The original implementation did not correctly parse the "client, proxy1, proxy2,…" format and assumed that there was a single IP address following the X-Forwarded-For header. I've added code to tokenize the values and strip out all but the first token in the comma delimited chain for inclusion in the logs. Header Name Override Others have asked to be able to change the header name that the filter looked for from "X-Forwarded-For" to some customized value. In some cases they were using the X-Forwarded-For header for another reason and wanted to use iRules to create a new header that was to be used in the logs. I implemented this by adding a configuration file option for the filter. The filter will look for a file named F5XForwardedFor.ini in the same directory as the filter with the following format: [SETTINGS] HEADER=Alternate-Header-Name The value of "Alternate-Header-Name" can be changed to whatever header you would like to use. Download I've updated the original distribution file so that folks hitting my previous blog post would get the updates. The following zip file includes 32 and 64 bit release versions of the F5XForwardedFor.dll that you can install under IIS6 or IIS7. Installation Follow these steps to install the filter. Download and unzip the F5XForwardedFor.zip distribution. Copy the F5XForwardedFor.dll file from the x86\Release or x64\Release directory (depending on your platform) into a target directory on your system. Let's say C:\ISAPIFilters. Ensure that the containing directory and the F5XForwardedFor.dll file have read permissions by the IIS process. It's easiest to just give full read access to everyone. Open the IIS Admin utility and navigate to the web server you would like to apply it to. For IIS6, Right click on your web server and select Properties. Then select the "ISAPI Filters" tab. From there click the "Add" button and enter "F5XForwardedFor" for the Name and the path to the file "c:\ISAPIFilters\F5XForwardedFor.dll" to the Executable field and click OK enough times to exit the property dialogs. At this point the filter should be working for you. You can go back into the property dialog to determine whether the filter is active or an error occurred. For II7, you'll want to select your website and then double click on the "ISAPI Filters" icon that shows up in the Features View. In the Actions Pane on the right select the "Add" link and enter "F5XForwardedFor" for the name and "C:\ISAPIFilters\F5XForwardedFor.dll" for the Executable. Click OK and you are set to go. I'd love to hear feedback on this and if there are any other feature request, I'm wide open to suggestions. The source code is included in the download distribution so if you make any changes yourself, let me know! Good luck and happy filtering! -JoeBIG-IP to Azure Dynamic IPsec Tunneling
In one of my previous posts we took a look at configuring the BIG-IP to act as a site-to-site VPN tunnel endpoint for connecting on-premises environments with Azure. At the time the BIG-IP only supported policy-based, (static-route) VPN tunnels. Now, with the latest release of the F5 BIGIP OS, (version 12.x), both dynamic as well as static-based IPSec VPNs are supported. “But Greg, why do I care?”, you may ask. Excellent question! For a good primer on the two version of IPSec VPNs checkout this blog post from Russ Slaten. From a practical standpoint, if your organization needs to connect multiple endpoints, (including Multi-Site, Point-to-Site, and VNet-to-VNet ), to their Azure environment, you must utilize a dynamic route-based VPN configuration. So with that said, let’s take a look at a typical configuration setup. Note: The following steps assume the BIG-IP has been initially configured settings including, but not limited to, licensing, provisioning, and network configurations. Addtionally, an iApp template is available here. The iApp will facilitate the deployment described below. Setup – Configure each of the following objects in BIG-IP as illustrated below. Step 1. Create IPsec Policy – The following IPsec policy created utilizes SHA-1’ for authentication, ‘AES-256’ for encryption, and Diffie-Hellman (MODP1024) Perfect Forward Secrecy. However, you have various options with regards to levels and types of auth/encryption. Refer to the Azure’s page for requirements. Step 2. Create Azure Traffic Selector – During the initial tunnel negotiation, the Azure VPN gateway will advertise ‘0.0.0.0/0’ for both source and destination subnets regardless of the actual on-premises and Azure VNet address spaces. The BIG-IP traffic selector should match this to allow for Azure initiated tunnels. The actual traffic direction, (routing) will be determined by the static route entries, (see Step 6 below). Step 3. Create Azure Peer – The Azure IKE peer utilizes IKE v2, ‘SHA-1’ for authentication, ‘AES-256’ for encryption, Diffie-Hellman (MODP1024) Perfect Forward Secrecy, and a ‘preshared key’. Step 4. Create IPsec tunnel profile and tunnel – This is where dynamic, (aka route-based) IPsec and policy-based IPsec diverge. Utilizing an IPsec tunnel interface allows us to create static routes with the tunnel endpoint as the next hop. This way any traffic destined for the Azure side will be routed through the tunnel. By contrast, policy-based VPNs require a policy that explicitly states which traffic can use the VPN. Step 5. Create Tunnel Endpoint Self-IP and IPsec interface Self-IP. Note:Although required, the address assigned is not utilized by Azure tunnel and the only requirement is the subnet must be unique. Step 6. Create Route – A static route with the newly created tunnel as the next hop allows any traffic hitting the BIG-IP and destined for the specified subnet to be routed through the IPsec tunnel. Step 7. Create a forwarding virtual server – The simple forwarding virtual server listens for and directs traffic over the IPsec tunnel. Additional Links: CodeShare - IPSec Tunnel Endpoint iApp Download Connecting to Windows Azure with the BIG-IP About VPN devices for site-to-site virtual network connections Configuring IPsec between a BIG-IP system and a third-party device Windows Azure Virtual Networks Static vs Dynamic Routing Gateways in Azure – Russ Slaten Blog Post Technorati Tags: F5,BIG-IP,VPN,AES,IPsec,IKE,SHA,AZURE,ADC
