Last Updated on June 7, 2017 by Dishan M. Francis
Today I am going to explain about another great feature which comes with Azure Active Directory. Rebeladmin Corp. does have a CRM application which use by its employees. This is web based app and hosted in internal network. This app uses windows authentication. From internal, users can log in to it with SSO. Rebeladmin Corp. also uses some application hosted in Azure as well as Office 365. These applications are currently used by its users internal and externally. There was recent requirement that users also want to access this CRM application from external. So, what we can do to allow access from external?
1. Setup VPN, so users can dial in to VPN and access the application through it.
2. Use ADFS to provide multi factor authentication and SSO from external. ADFS proxy server can place in DMZ to provide more secure connection from external
3. Use Remote Desktop Gateway and Remote Desktop Servers to host application for external access
4. If users are connecting from specific networks, allow direct access to application using edge firewall rules.
All above solutions can work but it need additional configurations and resource such as,
1. Firewall rules to control traffic between different network segments (DMZ, LAN, WAN)
2. Public IP addresses and DNS entries for internet facing components
3. Additional servers to host server roles and applications such as ADFS proxy, ADFS Farm, RDG etc.
4. Additional licenses cost
5. Additional maintenance cost
6. Skills to configure these additional server roles, firewall rules etc.
Azure Active Directory Application Proxy can integrate on-premises applications with Azure Active Directory and provide secure access with minimum changes to the existing infrastructure. It doesn’t need VPN, additional firewall rules or any other additional servers’ roles. This experience is similar to accessing applications hosted in azure or accessing office 365. This great feature was there for a while but still lots of people do not use this and some not even aware there is such feature available. Whole point of this blog series in to make public aware of this and encourage them to use this.
Why it’s good?
1. This allows organizations to use existing Azure security features to protect the on-premises workloads similar to azure SaaS workloads.
2. All the components are hosted in cloud so less maintenance.
3. Simple to setup and no need additional skills to setup different server roles or applications.
4. If users already familiar with Azure or other Microsoft hosted solutions, the access experience will be similar. Users will not need to train to use different tools to access the hosted applications. (VPN, Remote Desktop etc.)
5. No requirement for public IP address or public DNS entries. It will use public url which is generated during the configuration process and its from Azure.
However, not every application supported for this method. According to Microsoft it only supports,
• Any web application which uses windows authentication or form-based authentication.
• Applications hosted behind RDG (Remote Desktop Gateway)
• Web APIs
How it works?
Let’s see how it’s really works in real world.
1. User accessing the published Url for the application from the internet. This URL is similar to application url which is hosted in Azure. This is the azure generate public URL for on premises app.
2. Then its redirected to log in page and will be authenticate using Azure AD.
3. After successful authentication, it generates a token and send it to user.
4. Then request is forwarded to Azure AD application proxy. Then it extracts User principle name (UPN) and security principal name (SPN) from the token.
5. Then the request is forwarded to application proxy connector which is hosted in on-premises. This is act as a broker service between application proxy module and web application.
6. In next step, application proxy connector requests Kerberos ticket which can use to authenticate web application. This request is made on behalf of the user.
7. On-premise AD issue Kerberos ticket.
8. Kerberos ticket used to authenticate in to web app.
9. After successful authentication web app send response to application proxy connector.
10. Application proxy connector send response to the user and he/she can view the web application content.
To implement this we need the followings,
• Azure AD Basic or Premium Subscription
• Healthy Directory Sync with on-premises AD
• Server to install Azure Application Proxy Connector (this can be same server which host web application)
• Supported web application (earlier I mentioned what type of applications are supported)
In next part of this blog series will look in to configuration of Azure AD application proxy. Hope this was helpful and if you have any questions feel free to contact me on firstname.lastname@example.org
Great blog my friend 🙂