What is locked by someone else’s key? Exceptions to BYOK in Power BI
Data governance is one of the hot topics right now. Especially if you’re in a regulated industry like finance or insur...
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.
Let’s take a look at the case of our client:
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.
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:
What we need is:
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.
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:
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!
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:
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.
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:
The on-premises solution is to:
It’s a lot of on-prem infrastructure, isn’t it? Can we make it simpler with some cloud services?
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:
You will still require:
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.
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:
What you will get:
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?
Read other similar articles