Application Access Management Let Them Work! Application Access Made Easy. Case Study And Lessons Learned

In an event of collaboration or a merger with another organization, you may need to enable internal application access for many users. At the same time, you need to stay compliant with security regulations and keep your resources safe from leakage or malware. Today we are presenting a number of solutions which you can use to achieve those goals. Read on to find out what solutions you can use for application access and how to enable them.

It’s happening. Your company is growing. It is no longer a small shop, but it is merging with other companies.

This is the case for many of our customers: international companies, working across many locations and merging existing organizations with each other. Different enterprises and legal entities with separate networks. And the need to work together and share access to applications is growing.

Typically, in such scenario in the past, the common solution was to establish direct network connections or VPNs over the internet. To allow users to access apps, especially those using Windows authentication, a mesh of Windows AD domain trusts was created.

However, these days, this scenario might not be possible. Nor needed.

THE CASE: To provide access for thousands

Let’s take a look at the case of our client:

• A group of international companies working together under one umbrella
• Legal entities and locations spread across Western Europe in several countries
• Several thousand users working together and needing to access the same set of applications.

The business side wants this to be resolved in a seamless and easiest possible way for users. With simple access and SSO.

Applications in use are standard, Windows authentication-based apps. The setup is moving towards SaaS apps and some of those are already in use, but the majority of the shared ones still need Kerberos to work. Like SharePoint, or SQL Reporting Services.

Here is the business case to be solved

An IT organization knows that there are some challenges to meeting this demand. There are also some legal and regulatory requirements which prevent AD domain trust to be established.

NOT saying that this is not a modern setup.

THE SOLUTION: Let’s roll it out on-premises

What’s the answer then? If you’ve been following our blog for some time, you may already have an idea, as I have covered all the required elements in a blog post.

Let’s build it together.

We need to publish an application like SharePoint or SQL Reports and authenticate users using Kerberos on-premises.

What we have at hand is:

• Active Directory Domain Services on-prem (we all know it pretty well)
• Applications using Kerberos, working within an internal network.

What we need is:

• This application being published outside
• Users being able to authenticate using their credentials from AD DS, with SSO
• Application published in a secure way.

The solution for this on-premises scenario is to use Active Directory Federation Services (AD FS) and Web Application Proxy (WAP). Both are elements of Windows Server and can be deployed without the need for additional purchase of products and licenses.

AD FS provides user authentication services. It is also providing us with SSO capabilities – user authenticated once, on subsequent application access attempts, does not have to provide credentials again.

But hey – isn’t AD FS only for this special kind of modern web apps that recognize federation protocols?

Good, you’ve got it right, but this is where the Web Application Proxy steps in.

Web Application Proxy (WAP) is a Windows component performing three roles here:

• It acts as a reverse proxy. It can publish your apps from an internal network to external world with URL mapping. It’s simple, but it does the job in this case.
• WAP functions as an AD FS proxy. It is publishing your AD FS servers to the Internet and can act as a proxy for your users to do auth while working outside of the organization’s network.
• This component can do *MAGIC* and translate AD FS auth into a Kerberos token for non-claims based (those non-federated) applications.

With this setup, we can allow our users to access internal applications like SharePoint and authenticate against AD FS. And because we are working with WAP, the solution goes into Kerberos auth when the user is accessing an application published with WAP. Simple! And it works, too!

Let’s take it to another level

Hey, but where are the other companies? You’re right, we are missing all those organizations from this picture.

How will we use this setup to enable users from another organization to access this application?

We have all the components in place, we just need to make them work together, using a simple fact: federation services can be federated among each other!

In other organizations, we need:

• Active Directory Domain Services (of course, we need it to work somehow)
• Active Directory Federation Services, to authenticate users
• Web Application Proxy, to publish AD FS to the external network.

When we have it, we can federate AD FS from one organization to another. This means that user accessing an application will get redirected to their home organization and will authenticate there with all the benefits of AD FS (HTTPS only, SSO provided). When they present a valid token, WAP publishing this app will do the *MAGIC* and translate the token into a Kerberos one.

But… how will it know which user account it should map to? Which groups should I put into the token?

Good question! You are paying attention to this entire thing!

It all comes down to the UPN value and object with a correct UPN, matching the original user UPN being present in the target AD DS forest. It requires a shadow account to be created with right UPN value.

No! You don’t have to do it on your own. Microsoft Identity Manager synchronization service can do it for you with a simple setup. You can use other tools as well but MIM synch comes free of charge with Windows Server.

And there it is. The entire solution to the problem, in place.

How to set up onsite access with AD FS and WAP?

The case was:

• To allow users from several different organizations to work together
• To access Kerberos (but not only) apps with the original AD user accounts and SSO provided.

The on-premises solution is to:

• build federation and publishing infrastructure using AD FS and WAP
• federate organizations using AD FS
• use WAP for non-claims aware applications to map federated auth to on-premises Kerberos apps.

A few practical hints:

• You will need user synchronization between organizations – don’t forget those UPNs
• SSL certificates will come into play for all this publishing
• Many organizations will not publish all these services directly but will add some network level security. In our case, this was an F5 Networks solution. Make sure it is configured well to handle SNI certificates.

THE CLOUD SOLUTION: Let’s fly

It’s a lot of on-prem infrastructure, isn’t it? Can we make it simpler with some cloud services?

Yes, we can!

Our client, as many other organizations, is adopting Office 365 and with it also the Azure Active Directory. Azure Active Directory is providing a cloud service: Azure AD Web Application Proxy.

Does the name sound familiar? It should. Its role is the same as the one of WAP on-premises; it can publish applications and it can do Kerberos apps publishing, too (we’ve covered it before here).

With Azure AD and WAP service in place you:

• can enable the same scenario using Azure AD authentication which you are already building for Office 365
• don’t need to set up on-premises WAP and publish applications directly
• can apply additional security services like multi-factor authentication or conditional access for users.

You will still require:

• User synchronization between on-premises environments to do proper Kerberos user mappings.

Just a side note: To be completely fair, you can enable MFA with Azure for on-premises setup, and with AD FS configuration you can get some benefits of conditional access as well.

And just like that, we can build the same scenario with minimal on-premises infrastructure footprint.

Wow, this sounds great! Is there more?

Actually, it gets even more interesting with guest users. I’ve covered this a moment ago on our blog – just to refresh: you can use Azure AD B2B feature to enable users from other organizations to work with your applications.

With Azure B2B and this setup, you can enable users from outside of your group to access your on-premises applications! All of it secured, authenticated and with SSO enabled (the entire recipe for configuring it is provided in this blog post).

And here it is – our cloud-based version of secure application access across organizations!

Setting up the cloud solution with Azure AD Web Application Proxy

The cloud solution is:

• To leverage Azure AD for user authentication and security services
• To use cloud service, Azure AD Web Application Proxy, to securely publish your applications to the external networks.

What you will get:

• Application access with single sign-on provided by Azure AD
• The ability to leverage MFA and conditional access for additional security
• Enabling all kinds of external collaboration scenarios with Azure AD B2B.

Summary

We’ve covered a REAL case study of a multinational organization with SEVERAL thousands of users needing a simple solution to enable application access for ALL of them.

We have used existing services with no additional products to configure this scenario. It is all there at hand in your existing Windows Server.

You can make it even simpler and minimize the infrastructure footprint leveraging Azure cloud services.

And we have used a lot of links and references to our previous blog posts, because it all comes in handy in a nice and easy way.

Want to know more?

Get in touch to discuss your questions or requirements!