Building Nutanix Ready – Understanding “Ready” Early On – Part 1

Featured

Updated 9/22/17
The Journey to “Ready”
Are you Ready?

This is my journey to building a world-class “Ready” Program and understanding what validation means to me and the customer….This will be a multi-part series of my journey.

The early days of understanding the concept of “Ready”

I’ve spent the better part of my life in IT consulting. It has been some of the best and worst times of my life ;).  But when you make a choice to work in this industry, there are certain givens. Sometimes as consultants and IT Pros we don’t get the recognition we deserve, but if you have the passion for technology, it doesn’t matter.  I’m happy with the fact that I resolved or completed a project for a client. And enabled them to make their businesses stronger and more efficient. These IT pros tend to be part of grassroots communities, like the Microsoft MVP community, which is all about giving back and enabling others.

Anyways, moving along on with the story.  As a consultant, my many years in the field gave the opportunity to deploy a wide range of technologies.To name a few: InfoBox, Riverbed, Plexxi, Cisco, Microsoft (of course), CheckPoint, RSA, Silverpeak, A10, Carbonite, Comvault, CyberPower, EMC Solutions, F5, Fortinet, Sonicwall, Juniper, Palo Alto, Splunk, Trend Micro, VMTurbo (before they were Turboonomics) Veeam and the list could continue on, but I think everyone gets the point. Try saying that line in one breath :).

Deploying and supporting all these solutions for years is what prepared me to understand what “Ready” really means for a solution. When I first joined Nutanix, I was hired as a Microsoft Solutions Architect in Technical Alliances.  My job was to help advance and evangelize the story around Microsoft and Nutanix.  Also, I supported the field with sales motions around Microsoft solutions. Or as my new colleagues knew me, I was the resident “Microsoft Guy” :).

Introducing “Ready” into my Journey

About 2 or 3 months into my journey at Nutanix, I was approached by my manager about starting a “Ready” program for alliance partners. When he first told me, it took me a day or so let it set in  “I thought wow, this is right up my alley. I’ve been in the field and felt the good and bad of these solutions for years.”

Building a ready program is like building a highway through a mountain, especially in a startup. It’s not just about rubber-stamping a solution for anyone willing to pay to have their logo on your site. It’s a critical validation process that requires a team experienced and critical enough to ask; 1) Is there a real need from my customers that this solution answers;  2) Is this solution possible? In other words, the customer has to be the first and last consideration. Yes, as with the highway. There is an advantage to the solution builders (Who hasn’t wanted a highway named after them, not to mention collecting tolls?). If it doesn’t solve a problem, it’s not worth the investment.

Validation implies that you have guidelines and standards that the partner must meet. If they don’t meet the criteria, then they don’t get the status of “Ready” and all the benefits that go along with it. As Indiana Jones would say “No Ticket, No Ride” (from the Last Crusade movie 🙂 ).

So you ask, “What’s the importance of validation?”

Well, let’s look at the pharmaceutical industry. Validation for the pharmaceutical industry is the process of establishing documentary evidence demonstrating that a procedure, process, or activity carried out in testing and then production maintains the desired level of compliance at all stages. In the pharmaceutical industry, it is very important that in addition to final testing and compliance of products, it is also assured that the process will consistently produce the expected results.[1]   Validation is “Establishing documented evidence that provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes. This, for the pharmaceutical industry, is to maintain and assure a higher degree of quality for drug products.

Breaking it down simply, validation gives customers a degree of confidence that they are getting exactly what is advertised. Without validation in the pharmaceutical industry, there would be a lot of quality control issues. And this results in people getting sick or death in some cases.

So now, you can see why validation is so important. In the software industry, this can be the life or death of a customer environment resulting in costly downtime. It also puts doubt in the customer’s mind about if they should move forward with the solution.

Crazy story about Validation and QA with a Vendor Solution

Back in my consulting days, I was working with a large enterprise client deploying (at the time) Exchange 2010.  The client was on Exchange 2003, which at the time, did not really have a simple solution for failing over Exchange to a secondary site, in case of failure. This led to the rise of third-party products that made this failover process easy and gave you lots of options.  Continuing on with the story, I was at the end of the day at the client. We had just finished getting the Exchange 2010 DAGs (Database Available Groups) in place between the US and UK. This was so we could start the migration from Exchange 2003.

I had left for the day around 6 pm to head home. Within an hour, while I was in Boston traffic, I got a call from the client.  They proceeded to tell me that their Exchange 2003 environment was down. The product solution that was supposed to auto-failover is not working. The client asked, “Can you please come back and take a look. We have already called the vendor support and making no headway?”

I arrived back and started my troubleshooting.  Sure enough, before support called I found a serious bug that was not accounted for during the vendor’s QA process. In addition, the solution had completed another vendor’s “Ready” program. Now, I’m not going to name vendors, but this caused the client to go down for a number of hours while I worked with support to get this rolling again.

For this client or most clients, any downtime on email is a loss of business.  They took a big hit that day of hundreds of thousands of dollars.  Now, I’m not saying that validation is a silver bullet or could have saved this client headaches that day, but it certainly reduces the surface area of a problem arising in the field.

More about “Ready” with Technical Alliances and the Customer

Having a “Ready” program in the software industry is not just about approving and denying a solution, it’s also about helping partners resolve their issues whether it’s on either side, so they can eventually achieve “Ready” status.  And with that, “Ready” for a customer gives them the peace of mind that a solution will run on the given platform or hypervisor.

I was up to the challenge, and so starts the journey to “Building Nutanix Ready, What “Ready” means?”……Up next, paving the road to “Ready”.

Until next time, Rob.

Understanding Identity with ADFS – Part 1

Identity is always something of a taboo subject and is still not clearly understood out there and the IT security landscape keeps evolving.

One of the recent changes past few years is a move away from (Access Control Lists) ACLs on files in the NTFS file system to an access control system that is based on claims. Claims based authentication is an industry standard security protocol to authenticate users. This is the underlying WS-* standards that describe the usage of Security Assertion Mark-up Language (SAML) tokens. Claims based auth requires these tokens, and by extension an entity that can issue the token. This is the Secure Token Service (STS). The STS server can be based on Active Directory Federation Services (ADFS) or other platforms that provide this service. This is where ADFS comes in and the highlight of this series.

Why Active Directory Federation Services (ADFS)?

When I started to work on ADFS, a number of years ago during my days as a consultant, most of my customer’s requests where simple:

“I want to federate with some application, hosted by some vendor, so that my users can login into this application without being prompted for credentials.”

This type of request may seems simple, but this where the power of the Single Sign-On(SSO) experience and the underlying technology is transformative.

So, what exactly is ADFS?
In plain English, it’s a web service that authenticates your users to Active Directory while also simultaneously providing them access to some claims-aware application (i.e. Office 365, Salesforce.com, etc.). Many times, these applications are typically used through the client’s web browser.The applications can be on-premises, off-premises, or even hosted by other companies. It doesn’t really matter where these applications live, who owns them, as long as they can accept a token with claims.

This blog post will review the history of ADFS and an overview ADFS itself. Next in the series I will cover deploying ADFS and configuring Federation with Office 365 on Nutanix in the lab. This will play into a series I am planing around Office 365 and Hybrid setup on Nutanix in the future. After that, I will cover different deployment scenarios. So sit back and enjoy the identity ride.

Active Directory Federation Services

ADFS is an identity access solution that provides client computers (internal or external to your network) with seamless SSO access to protected Internet-facing applications or services, even when the user accounts and applications are located in completely different networks or organizations. (i.e. think how you login with facebook to other services)

When an application or service is in one network and a user account is in another network, typically the user is prompted for secondary credentials when he or she attempts to access the application or service. These secondary credentials represent the user’s identity in the realm where the application or service resides. They are usually required by the Web server that hosts the application or service so that it can make the most appropriate authorization decision.

With ADFS, organizations can bypass requests for secondary credentials by providing trust relationships (federation trusts) that these organizations can use to project a user’s digital identity and access rights to trusted partners. In this federated environment, each organization continues to manage its own identities, but each organization can also securely project and accept identities from other organizations.

Below is an example of a typical Office 365 Deployment with ADFSADFS-O365

So here we go.  Let’s start with the basics.  There are currently 5 versions of ADFS, and understanding where to get each can be a bit tricky.

ADFS 1.0

  • ADFS 1.0 was first introduced with Windows Server 2003 R2 and it was installed as a Windows Feature.
  • Avoid using this version.  If for no other reason, 2003 R2 fell out of mainstream support in 2010!
    ADFS-2K3

ADFS 1.1

  • ADFS 1.1 was included with Windows Server 2008 and 2008 R2 and can be installed through Server Manager.
  • Obviously 2008 R2 has a longer shelf life than 2003 R2, but that doesn’t mean you should use this version of ADFS either.  It’s missing features most federation partners are expecting.
  • If you want to install ADFS on Windows Server 2008 do NOT do it from Server Manager (unless you know you need AD FS 1.1).
    ADFS-2K8

ADFS 2.0

  • ADFS 2.0 was a release to web (RTW).  It was NOT included with any OS.  It must be downloaded and installed on either Windows Server 2008 SP2 or 2008 R2.
  • ADFS 2.0 has seen three update rollups.  If you don’t want to go with Windows Server 2012 yet, make sure to install the latest update rollup.
    ADFS-RTW

ADFS 2.1

  • ADFS 2.1 is included with Windows Server 2012 and can once again be installed through server manager.
    ADFS-2K12

ADFS 2012 R2 (Official Name)

  • ADFS 2012 R2 is included with Windows Server 2012 R2 and can once again be installed through server manager.
    ADFS-2K12

Great, now that we understand what we’ve got to work with, let’s talk about what ADFS is used for. The rest of this blog post will focus on ADFS 2.x\2012 R2.  For me the easiest way to understand a new technology is to understand its purpose in relatable terms.  I’ll make an assumption that most of you understand Active Directory and I will discuss ADFS in relation to it.

Ultimately, ADFS is just a Security Token Service (STS).  In other words, it generates security tokens for users to present to applications.  If you work with Active Directory often, this should sound familiar.  One of the roles of a Domain Controller is that of a Key Distribution Center (KDC).  Whether you call it a key or a token, STS’s and KDC’s are similar in nature.  It’s important to realize that ADFS CANNOT authenticate a user by itself, it must rely on a DC for authentication to Active Directory.  Once authentication occurs, ADFS does the same thing a DC would do; verify users and issue security tokens

Q: If they’re so similar, why do we need ADFS?

A: There are specific scenarios in which Active Directory Domain Controllers don’t meet modern needs.

Without going into too much detail, generally a DC uses Integrated Windows Authentication (IWA, usually Kerberos or NTLM) to authenticate a user to the application they are trying to access.

Q: What happens though, when that application is a web application?  And the user is at home on their iphone, ipad or tablet?

A: IWA doesn’t work so well in that scenario for a few reasons:

  1. The client doesn’t have access to a domain controller from the internet (at least I hope not 🙄 ).
  2. Whatever device they’re using, it may not support IWA (most likely).
  3. Ports for HTTP and/or HTTPS are likely the only ports open between the client and the server.

The first means Kerberos won’t work (the client has to get a ticket from a DC).  The third means NTLM won’t work (NTLM uses RPC :cry:!).  The middle one trumps them both anyway.

Let’s consider another typical Microsoft scenario: I work for Contoso and need to access a web application at Fabrikam.  Each organization has its own Active Directory forest, and there isn’t a trust relationship between them.  Traditionally I have two options:

  • Setup an Active Directory trust relationship between the AD Domains
  • Create a “shadow” account in Fabrikam’s forest for my Contoso user account

Setting up a trust can be a pain, because of the port requirements for AD trusts.  Just look at them all!  You can always establish those over a VPN tunnel (or something else) like the article mentions, but there are other security related concerns with an AD trust as well. Too many to mention in this blog post.  😥

Creating shadow accounts isn’t much better.  You could use a product to synchronize forests (such as Forefront Identity Manager) or you could manually add and remove the shadow accounts. All which is a pain to manage in either case.

Q: What happens when a user at Contoso is fired?  Is there a defined process for making sure that user is deleted on the Fabrikam side?  If not, they’ll still have access to whatever applications they had access to before.

That is where ADFS comes in……

Using ADFS, we can get around each of these issues:

  • The client doesn’t need to access a DC from the internet because an ADFS proxy server can be used.  The ADFS proxy is typically NOT joined to the corporate forest for security reasons. It proxies the requests to the ADFS server, in other words, no direct contact to your ADFS server.
  • ADFS can use forms based authentication, which means the type of client becomes irrelevant, since the username and password is entered in a webpage:
    ADFS-Login
  • All of the authentication is done over a TLS (SSL) tunnel (port 443 by default) so no need to open additional ports.
  • ADFS can setup a trust relationship from company to company without ANY ports being open.  Everything is accomplished through the exchange of x509 certificates (in an email if you’d like).
  • Once the trust is established, there’s no need to create shadow accounts for users from one organization to access resources at another.
So far this ADFS thing sounds pretty awesome huh…?!  And I’m only looking at the benefits from an infrastructure standpoint.
As with anything, there are also some downsides…ADFS does NOT work for traditional Windows NT token based applications!  What does that mean?
    • ADFS will NOT allow you to
      • access file shares or print servers
      • access Active Directory resources
      • connect to servers using RDP
    • ADFS will NOT authenticate you to “older” web applications

There are plenty of benefits for developers also. Ok then, what does Active Directory Federation Services help you with in DevOps you ask?  This gets us back to those terms used at the beginning of the blog post, specifically, Claims-Aware, WS-Trust, WS-Federation, and SAML.

Here is a high level explanation of each:

Claims-Aware is the most ambiguous of the terms mentioned.  All it really means is that an application is written to use “claims” presented in a token to make authorization decisions.  From a Microsoft standpoint this typically indicates it’s a .NET application written with the Windows Identity Foundation (WIF) SDK (which is now a part of .NET 4.5).  A “claim” is nothing more than information about a user or some other identity.  You can think of claims as group memberships in Active Directory, only a lot more flexible.  For example, I could have a claim called “Age” with the value of “65”.  An application could then decide to let me into the “retirement” section.  That’s a very generic example but hopefully it gets the point across.

WS-Trust is a bit more specific.  Just like Kerberos is a defined authentication protocol, WS-Trust is a defined OASIS (Organization for the Advancement of Structured Information Standards) standard.  You can find the WS-Trust standard here.  Basically WS-Trust defines a way for applications to build trusted tokens for authentication and authorization purposes.

WS-Federation is really just an extension of other WS-* standards.  The biggest difference is: “WS-Federation defines a mapping of these mechanisms, and the WS-Trust token issuance messages, onto HTTP such that WS-Federation can be leveraged within Web browser environments.”  In other words, it makes all of this work in a web browser (which incidentally is still probably the biggest use case).

SAML (Security Assertions Markup Language) is yet another OASIS specification mostly unrelated to the WS-* standards even though it achieves roughly the same thing.  You can find all three versions defined here.

Great, now let’s outline a few important points from this infomation:

  • If you want to use Active Directory Federation Services, the application or organization ADFS is to federate with must follow the WS-Trust, WS-Federation, or SAML standard.
  • The SAML standard defines a token type referred to as a SAML token.  WS-Trust and WS-Federation can use many token types including SAML tokens.  Don’t be confused if an application is WS-Federation even though it’s using SAML tokens.
  • ADFS can federate with applications (that follow one of the standards above) AND with other federation service providers.  Federating with other partners establishes the trust relationship necessary for users in one organization to access resources in another.
  • WS-Federation is mostly used by websites designed to interact with a browser (SharePoint is a good example).
  • WS-Trust is typically used by web services designed to interact with a thick client (Lync with Office 365 is a good example)
  • SAML is typically used by products from companies other than Microsoft but ADFS does support its use.

To end this blog post on Understanding ADFS, I’d like to finish with a diagram that should help explain the traffic flow when using ADFS to protect applications.  This is what a client would go through if the application the client is accessing is written with WS-Federation or SAML SP-Initiated sign on in mind.

ADFS overview
(ADFS proxy servers left out for diagram simplicity)

Notice that the user is a Contoso employee with an account in the contoso.com AD domain.  This user is accessing a resource in the AD fabrikam.com domain.  Because the account resides at Contoso, Contoso’s ADFS server is considered the Identity Provider (IdP) or Claims Provider (CP) to the Fabrikam ADFS server.  The resource the user is trying to access is located in Fabrikam, so the Fabrikam ADFS server is the Service Provider (SP) or Relying Party (RP) to the Contoso ADFS server.  Going a step farther, the Fabrikam ADFS server is the IdP or CP to the web server, while the web server is the SP or RP to the Fabrikam ADFS server.  Make sense?  The yellow bar should help.

The yellow bar in the diagram does not indicate network connectivity, but instead the logical trust relationships:

  • The Fabrikam web server trusts the Fabrikam ADFS server.
  • The Fabrikam ADFS server trusts the Contoso ADFS server.
  • In both instances, the trust is established by trusting what’s called a token-signing certificate (or trusting the root it chains to).

The terms identity provider, claims provider, service provider and relying party can get a bit confusing. But they are interchangeable as you can see. Think of it like this:

Standard Industry Terminology

MS ADFS Terminology

Identity Provider (IdP)

Claims Provider (CP)

Service Provider (SP)

Relying Party (RP)

Here are a few additional resources for reference:

TechNet – Active Directory Federation Services Overview

Windows Server 2012 R2 AD FS Deployment Guide

I hope this post gives you a good understanding of ADFS and the benefits it can provide.  In the next posts in this series, we’ll look more closely at deployment with Office 365, and different  deployment scenarios.

Until next time, Rob