These days, when you make applications and services available from external locations, security is always (or should be) top-of-mind for IT admins. What they need to make sure of is that no one from an external location can easily break into their applications. To achieve front-end security, one of the practices we normally carry out is to protect systems with multi-factor authentication. This gives any potential hacker an incredibly tough time, even if they managed to guess or brute force a user’s insecure password.

That said, how many companies protect Office 365 only with single-factor authentication? I am going to bet an extremely large sect of the customer base. Why? Some organisations have multi-factor authentication for NetScaler, but only single-factor authentication for Office 365. That is like placing a NetScaler on the internet with LDAP authentication; it’s frowned upon. For some reason, however, Office 365 seems exempt from the same. If someone manages to break into an Office 365 Global Administrator account that is protected only with single-factor authentication, then you are in big trouble. What happens when a confidential mailbox — something with customers’ personal and sensitive company information — is breached?

All it takes is for one unsecure computer to be key-logged, and the unsuspecting end-user from their home computer logs on to Office 365 to read their emails before bed (I know, we all do it right?). Little do they know they have just handed over the keys to the hacker whilst they are at it. Even a simple phishing attack is enough to compromise mailboxes that are protected with single-factor.

It’s time to rethink your authentication strategy and learn how NetScaler can not just help but go beyond your expectations.

The SAML authentication protocol has been around for over 10 years. It has also been one of those abbreviations referenced at many Citrix Synergy sessions in the past year or two. But for those of you who don’t know, what is SAML?

SAML (Security Assertion Markup Language) provides a way for one federation (an Identity Provider) to authenticate with another separate federation (a Service Provider) typically to consume available services. Rather than send passwords over the internet to authenticate with external SaaS applications, SAML is a more secure way to authenticate. Think of one Active Directory farm wanting to authenticate and consume services from another Active Directory farm, without the trust.

As one of many SaaS providers available today, Office 365 is claimed to beMicrosoft’s fastest growing business ever. I’ll stake my wager now that more people who read this post consume Office 365 services than not.

With Office 365 offering services to us all, we can class Office 365 as the Service Provider as, well, it provides the service. Office 365 supports SAML, and so does NetScaler. This means that with Office 365 as the Service Provider, we can configure NetScaler to be the Identity Provider. That is to say, NetScaler provides the authentication offering that Office 365 accepts before providing Outlook access, or SharePoint access, OneDrive, and so on.

Since NetScaler is now the Identity Provider, we open a whole stack of different ways users can authenticate to NetScaler and, in turn, Office 365. To name a few, NetScaler supports traditional LDAP, Certificates, RADIUS, WebAuth, Negotiate, and more. To understand the flow of authentication when NetScaler is in the mix, I’ve documented the steps at a high level:

  1. Joe browses to https://login.microsoftonline.com and enters his email address
  2. Office 365 detects the specified realm and redirects user to NetScaler AAA
  3. NetScaler is normally connected to Active Directory, but supports a number of different authentication protocols and, as such, can challenge the user for a range of authentication methods
  4. If Joe can successfully authenticate with NetScaler, the NetScaler sends a SAML assertion (token) to Office 365
  5. Because Office 365 is configured to trust the NetScaler IdP, the token is accepted
  6. The attributes are extracted from the SAML assertion to identify Joe, and Joe is granted access to Office 365

Here are some of the scenarios you can support with NetScaler acting as the authentication enforcer for Office 365:

  • User Certificate authentication, followed by LDAP password. If successful, authentication to Office 365 is granted.
  • LDAP authentication followed by Azure Multi-Factor authentication (Microsoft Authenticator phone prompt). If successful, authentication to Office 365 is granted.
  • LDAP authentication followed by Google one-time password. If successful, authentication to Office 365 is granted.
  • Negotiate authentication for internal clients who can reach a KDC (Key Distribution Center). If successful, authentication to Office 365 is granted. No password is entered as Integrated Windows Authentication is used for true single sign-on.
  • Certificate authentication only. Optionally no password has to be entered. If successful, authentication to Office 365 is granted.
  • Username only followed by two one-time password prompts. If successful, authentication to Office 365 is granted.

You get the gist by now, but the scenarios are endless.

So what do you need? An Office 365 subscription, of course, and you need to be eligible to use the AAA (Authentication, Authorization and Auditing) feature, which requires, at a minimum, NetScaler Enterprise licensing. You’ll also need any required subscriptions for external authentication solutions. The good news is there are no further “gotchas” so you don’t need NetScaler Platinum licenses to achieve any of the authentication scenarios I described above.

So how do you configure it?

I’ll be clear, I’m not going to bore you with all the steps as there are quite a few. Instead, if you want more detail you can find my documentation here.

At a high level, you need to first configure Office 365 for federation.

You should:

  • Configure Azure AD Connect for on-premises replication of Active Directory objects to the cloud.
  • Use Azure AD PowerShell Module to setup the federation for your domain name.

Once the federation is configured, you perform the remaining configuration on NetScaler.

  1. Firstly, you need to configure an AAA Virtual Server. This Virtual Server must be accessible externally, with an FQDN created for example https://aaa.jgspiers.com. You also need a public certificate bound to the Virtual Server which matches the FQDN.
  2. Depending on which authentication methods and scenario you want to use, you’ll need authentication policies. You will absolutely need a SAML authentication policy. Additionally, you might just go with LDAP authentication which keeps things easy. On the other hand, you may want different scenarios for different types of users. How about 3-factor authentication for Office 365 administrators and 2-factor for the remaining users? How about multiple factors for mailboxes that contain highly confidential emails? Anything is possible with NetScaler.
    • Note that if you do go down the route of implementing different types of authentication for various use cases, you can achieve this by using nFactor authentication.
  3. Finally you’ll have to bind the different authentication policies to your AAA Virtual Servers, including the SAML authentication policy.

So, with the configuration complete, let me show you the final outcome. In this scenario, external users are challenged with LDAP authentication followed by Azure Multi-Factor Authentication using the Authenticator mobile app. Internal users are challenged with Negotiate authentication and are passed straight through without the need for entering a password.

Scenario 1 – External user:

  1. External user browses Office 365
  2. User enters email address
  3. Office 365 redirects user to AAA Virtual Server
  4. User enters LDAP credentials and clicks Log Ongeorge1
  5. User is prompted by Azure Multi-Factor Authenticationgeorge2
  6. User is successfully authenticated with NetScaler, the SAML assertion is sent to Office 365 and the user is granted accessgeorge3

Scenario 2 – Internal user

  1. Internal user browses Office 365
  2. User enters email addressgeorge4
  3. Office 365 redirects user to AAA Virtual Servergeorge5
  4. Negotiate authentication is performed which automatically logs the user on to Office 365george6

To see a GIF-formatted animation of the auto-logon, see http://www.jgspiers.com/single-sign-on-office-365-netscaler-saml-azure-mfa-authentication/#Internal-Results

Why not try it today?

See for yourself how NetScaler brings value to your Office 365 deployments by enrolling for a 90-day trial: https://www.citrix.co.uk/products/netscaler-adc/get-started.html

citrix-blog-footer-banners-3