Category Archives: Azure AD Application Proxy

Install & Register Azure AD Application Proxy Connector on Windows Server 1709

I recently installed the new release of Windows Server, version 1709 on my Intel NUC, you can read about that here.

I have installed Project Honolulu for remote server management on that server, but as this Intel NUC is usually located on my home lab network, I want to be able to publish and access the Honolulu website using Azure AD Application Proxy.

As the Windows Server 1709 is Server Core, I need to install and configure the Azure AD Application Proxy Connector silently, and these are the steps I did to do that.

First, you need to download the Application Proxy connector install file, and transfer it to the server. You can access the connector download from Application Proxy section in your Azure AD portal:

After that, run the following command to do a quiet install of the connector, skipping registration interactively:

AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR=”false” /q

Next we need to register the Application Proxy connector to Azure AD, and for that we need to run some PowerShell commands. There are two ways this can be done, with a Credential Object, or using an Offline Token. Using Credential is simplest, but has the drawback that you cannot use that method if your Global Administrator account is protected with Azure MFA. Lets look at both methods below.

Using Credential Object:

On the Server you want to register the Azure AD App Proxy Connector, start a PowerShell session and run the following commands for setting the Global Administrator user name and password, and then create a Credential Object.

After that, run the following commands to run the RegisterConnector.ps1 script for register the connector using Credential object as authentication:

You can copy the PowerShell commands used above using the Gist linked at the end of this blog post.

Using Offline Token:

If you can’t or don’t want to use a credential object, you have to use a offline token. The following commands will get an access token for the authorization context needed for Application Proxy Connector Registration.

Getting the Token can be run from any client, and then transferred to the server, but you will need to have the Azure Active Directory Authentication Library (ADAL) installed at the machine you are running the PowerShell commands. The easiest way to get the needed libraries installed is to Install the AzureAD PowerShell Module.

The following commands locates the AzureAD (or AzureADPreview) Module, and then finds the ADAL Helper Library: Microsoft.IdentityModel.Clients.ActiveDirectory.dll, and adds that as a Type to the PowerShell session:

Next, run these commands to define some constants, these values are the same for all tenants:

Now we can run these commands for setting the authentication context and then prompt user for AuthN:

Running the above commands will result in an authentication prompt, this is where you would specify your Global Administrator account, and if MFA enabled this will also work:

After authenticating we can check the result and save the token and tenantId in variables as shown below:

Next, copy the contents of the $token and $tenantId to the Windows Server 1709, and run the following command to create a secure string from the token:

And then run the RegisterConnector.ps1 script with AuthenticationMode as Token and using the secure token and tenant id as parameter values as shown below:

PS! According to the official documentation, there are no description or examples for the mandatory parameter “Feature”, but I found that it accepts the value “ApplicationProxy” as used above.

You can copy the above PowerShell commands from the Gist linked at the end of this blog post.

	# Register Azure AD App Proxy Connector
	# PS! Using Credential Object cannot be used with MFA enabled administrator accounts, use offline token

	$User = "<username of global administrator>"
	$PlainPassword = '<password>'
	$SecurePassword = $PlainPassword \| ConvertTo-SecureString -AsPlainText -Force
	$cred = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User, $SecurePassword

	Set-Location "C:\Program Files\Microsoft AAD App Proxy Connector"
	.\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" `
	-moduleName "AppProxyPSModule" -Authenticationmode Credentials -Usercredentials $cred

view raw

RegisterAppProxyConnectorCredential.ps1

hosted with ❤ by GitHub

	# Get Offline Token for Azure AD App Proxy Register Connector
	# Then Register Connector with that Token

	# Locate AzureAD/AzureADPreview PowerShell Module
	# Change Name of Module to AzureAD or AzureADPreview after what you have installed
	$AADPoshPath = (Get-InstalledModule -Name AzureADPreview).InstalledLocation
	# Set Location for ADAL Helper Library
	$ADALPath = $(Get-ChildItem -Path $($AADPoshPath) -Filter Microsoft.IdentityModel.Clients.ActiveDirectory.dll -Recurse ).FullName \| `
	Select-Object -Last 1

	# Add ADAL Helper Library
	Add-Type -Path $ADALPath

	#region constants

	# The AAD authentication endpoint uri
	[uri]$AadAuthenticationEndpoint = "https://login.microsoftonline.com/common/oauth2/token?api-version=1.0/"

	# The application ID of the connector in AAD
	[string]$ConnectorAppId = "55747057-9b5d-4bd4-b387-abf52a8bd489"

	# The reply address of the connector application in AAD
	[uri]$ConnectorRedirectAddress = "urn:ietf:wg:oauth:2.0:oob"

	# The AppIdUri of the registration service in AAD
	[uri]$RegistrationServiceAppIdUri = "https://proxy.cloudwebappproxy.net/registerapp"

	#endregion

	#region GetAuthenticationToken

	# Set AuthN context
	$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" `
	-ArgumentList $AadAuthenticationEndpoint

	# Build platform parameters
	$promptBehavior = [Microsoft.IdentityModel.Clients.ActiveDirectory.PromptBehavior]::Always
	$platformParam = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters" -ArgumentList $promptBehavior

	# Do AuthN and get token
	$authResult = $authContext.AcquireTokenAsync($RegistrationServiceAppIdUri.AbsoluteUri, `
	$ConnectorAppId, `
	$ConnectorRedirectAddress, `
	$platformParam).Result

	# Check AuthN result
	If (($authResult) -and ($authResult.AccessToken) -and ($authResult.TenantId) ) {
	$token = $authResult.AccessToken
	$tenantId = $authResult.TenantId
	}
	Else {
	Write-Output "Authentication result, token or tenant id returned are null"
	}

	#endregion

	# Create a secure string from token
	$secureToken = $token \| ConvertTo-SecureString -AsPlainText -Force

	# Register connector with secure token and tenant guid
	Set-Location "C:\Program Files\Microsoft AAD App Proxy Connector"
	.\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" `
	-moduleName "AppProxyPSModule" -Authenticationmode Token -Token $SecureToken -TenantId $tenantId `
	-Feature ApplicationProxy

view raw

RegisterAppProxyConnectorOfflineToken.ps1

hosted with ❤ by GitHub

So to recap, after installing the Application Proxy Connector silently on the Windows Server 1709, and then registering the connector, I can now verify in the Azure AD Portal that the connector is available for use. I can see it has a status of Active, from my home IP address, and I have already placed it in a Connector Group.

I’m now ready to publish Azure AD Proxy Apps using this connector, and in my next blogpost I will publish the Project Honolulu management website using this!

Here is the Gist source for the above linked PowerShell commands:

	# Register Azure AD App Proxy Connector
	# PS! Using Credential Object cannot be used with MFA enabled administrator accounts, use offline token

	$User = "<username of global administrator>"
	$PlainPassword = '<password>'
	$SecurePassword = $PlainPassword \| ConvertTo-SecureString -AsPlainText -Force
	$cred = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User, $SecurePassword

	Set-Location "C:\Program Files\Microsoft AAD App Proxy Connector"
	.\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" `
	-moduleName "AppProxyPSModule" -Authenticationmode Credentials -Usercredentials $cred

view raw

RegisterAppProxyConnectorCredential.ps1

hosted with ❤ by GitHub

	# Get Offline Token for Azure AD App Proxy Register Connector
	# Then Register Connector with that Token

	# Locate AzureAD/AzureADPreview PowerShell Module
	# Change Name of Module to AzureAD or AzureADPreview after what you have installed
	$AADPoshPath = (Get-InstalledModule -Name AzureADPreview).InstalledLocation
	# Set Location for ADAL Helper Library
	$ADALPath = $(Get-ChildItem -Path $($AADPoshPath) -Filter Microsoft.IdentityModel.Clients.ActiveDirectory.dll -Recurse ).FullName \| `
	Select-Object -Last 1

	# Add ADAL Helper Library
	Add-Type -Path $ADALPath

	#region constants

	# The AAD authentication endpoint uri
	[uri]$AadAuthenticationEndpoint = "https://login.microsoftonline.com/common/oauth2/token?api-version=1.0/"

	# The application ID of the connector in AAD
	[string]$ConnectorAppId = "55747057-9b5d-4bd4-b387-abf52a8bd489"

	# The reply address of the connector application in AAD
	[uri]$ConnectorRedirectAddress = "urn:ietf:wg:oauth:2.0:oob"

	# The AppIdUri of the registration service in AAD
	[uri]$RegistrationServiceAppIdUri = "https://proxy.cloudwebappproxy.net/registerapp"

	#endregion

	#region GetAuthenticationToken

	# Set AuthN context
	$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" `
	-ArgumentList $AadAuthenticationEndpoint

	# Build platform parameters
	$promptBehavior = [Microsoft.IdentityModel.Clients.ActiveDirectory.PromptBehavior]::Always
	$platformParam = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters" -ArgumentList $promptBehavior

	# Do AuthN and get token
	$authResult = $authContext.AcquireTokenAsync($RegistrationServiceAppIdUri.AbsoluteUri, `
	$ConnectorAppId, `
	$ConnectorRedirectAddress, `
	$platformParam).Result

	# Check AuthN result
	If (($authResult) -and ($authResult.AccessToken) -and ($authResult.TenantId) ) {
	$token = $authResult.AccessToken
	$tenantId = $authResult.TenantId
	}
	Else {
	Write-Output "Authentication result, token or tenant id returned are null"
	}

	#endregion

	# Create a secure string from token
	$secureToken = $token \| ConvertTo-SecureString -AsPlainText -Force

	# Register connector with secure token and tenant guid
	Set-Location "C:\Program Files\Microsoft AAD App Proxy Connector"
	.\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" `
	-moduleName "AppProxyPSModule" -Authenticationmode Token -Token $SecureToken -TenantId $tenantId `
	-Feature ApplicationProxy

view raw

RegisterAppProxyConnectorOfflineToken.ps1

hosted with ❤ by GitHub

Azure AD B2B Users and Access to Azure AD Application Proxy Apps

5 Replies

The purpose of this blog post is to show a practical approach and some guidelines for publishing Azure AD App Proxy applications to guest users using Azure AD B2B.

To keep this blog post short and to the point, I will make the following assumptions:

You have an on-premises AD and Azure AD Connect set up for synchronizing users and groups to Azure AD.
You have already set up Application Proxy connectors and connector groups (if you want a walkthrough on this, see this blog post https://gotoguy.blog/2017/09/24/secure-access-to-project-honolulu-with-azure-ad-app-proxy-and-conditional-access/
You have published one or more Azure AD App Proxy applications.
Your tenant is configured for allowing Azure AD B2B users and you have invited one or more guests.

Demo scenario

I will first give a quick overview over the demo scenario for this blog post:

I will use my tenant elven.onmicrosoft.com, where I have configured a custom domain elven.no.
I have invited an external user: [email protected] to the elven.onmicrosoft.com tenant. This user has accepted the invitation and can access resources that will be shared.
I have published some App Proxy applications, and in this scenario I will use Cireson Portal, which is a Self Service Portal for SCSM.

In this blog post I will use both single sign-on disabled with forms based authentication, and single sign-on with windows integrated authentication for this guest user, but lets first verify that the guest user can log on to my application panel.

Using Azure AD Access Panel as Guest User

When I log on to the Azure AD Access Panel at https://myapps.microsoft.com as external account I will se all my published applications at my company Skill AS, and since I have been added as a Azure AD B2B guest to the Elven Azure AD tenant, I can switch to that tenant like this:

I will then be redirected to the Elven Azure AD tenant and all my published applications will show (but for now this is none):

So lets start by adding this external guest to a published application without single sign-on and Windows Integrated Authentication enabled.

Without Single Sign-On

First, this is the guest user I will add to the application:

Then I go to the App Proxy Application, and in the properties I have required that any user must be assigned to access the application:

Under Application Proxy I will require pre authentication with Azure AD, so that users can not access the URL without being logged on to the tenant (in this case as a guest):

In this first scenario single sign-on with Azure AD and Windows Integrated Authentication is disabled:

Then I add my guest user as an assigned user to the application:

In the meantime I have configured the Cireson Portal to use Forms Based Authentication, and now we can test the guest user:

In the Access Panel my guest user can now see and launch the Cireson Portal published application:

And my guest user can successfully get to the web application which now presents a user login form, which will require a on-premises AD user with access rights to the Cireson Portal.

In my on-premises AD I have created just that, a user with the account name jan.vidar.guest:

And I can successfully log on with the guest user:

So far we have seen that an Azure AD B2B user can successfully launch an Azure AD App Proxy application, and in the next step log on with a local AD user with access to the application.

I the next section we will see how we can provide single sign-on with Azure AD and Windows Integrated Authentication.

PS! I will also change the Cireson Portal to use Windows Authentication before this next step!

Azure AD Single Sign-On and Windows Integrated Authentication

First I will need to change the settings for the Azure AD App Proxy application.

Under Single sign-on I will change to Integrated Windows Authentication, specify a SPN for Kerberos Constrained Delegation, and specify to use User principal name for delegated login identity:

By now you might have realized that for single sign-on to work with windows integrated authentication in a Azure AD B2B guest user scenario, you will need to have a “shadow” AD user for this external scenario. In my first test above, I had created a “jan.vidar.guest” user. Remember that I chose to use User principal name as a delegated login identity. So I will need a UPN that will be a link between my Azure AD guest user account ([email protected]) and the local AD user. If that link is missing, you will see the following in the Application Proxy Connector Log:

So this error message tells us exactly what user principal name is expected from the guest user. The error message below provide more details from this error:

Web Application Proxy encountered an unexpected error while processing the request.
Error: The user name or password is incorrect.
(0x8007052e)

Details:
Transaction ID: {00000000-0000-0000-0000-000000000000}
Session ID: {00000000-0000-0000-0000-000000000000}
Published Application Name:
Published Application ID:
Published Application External URL: https://selfservice-elven.msappproxy.net/
Published Backend URL: http://azscsmms3/
User: jan.vidar.elven_skill.no#EXT#@elven.onmicrosoft.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299
Device ID: <Not Applicable>
Token State: NotFound
Cookie State: NotFound
Client Request URL: https://selfservice-elven.msappproxy.net/Home/NavigationNodes
Backend Request URL: <Not Applicable>
Preauthentication Flow: PassThrough
Backend Server Authentication Mode: WIA
State Machine State: OuOfOrderFEHeadersWriting
Response Code to Client: 500
Response Message to Client: Internal Server Error
Client Certificate Issuer: <Not Found>
Response Code from Backend: <Not Applicable>
Frontend Response Location Header: <Not Applicable>
Backend Response Location Header: <Not Applicable>
Backend Request Http Verb: <Not Applicable>
Client Request Http Verb: POST

So, lets change the UPN of my local shadow user to that. You can either add the UPN suffix to your Active Directory Forest, or change the user principal name with AD PowerShell like:

Set-ADUser jan.vidar.guest -UserPrincipalName jan.vidar.elven_skill.no#EXT#@elven.onmicrosoft.com

Generally you will need to add Azure AD B2B users with user principal name in the form of:

<emailalias>_guestdomain#EXT#tenantdomain

So, lets try to launch the Cireson Portal again now, this time with Azure AD Single Sign-On and Windows Integrated Authentication:

And now the user will be logged directly into the Cireson Portal with SSO:

So now we have seen that we can successfully use Azure AD B2B Guests in an Azure AD Application Proxy published application scenario, with or without Single Sign-On, and that we require a link with the delegated identiy with a “shadow” user in the on-premises AD.

NB! Before you think that you should create that user as a disabled account, this is what happens:

This means, you have to enable the AD user account, but the password can be anything and don’t have to be shared with the external user.

Update: Require MFA from Guest Users

I have had some questions on how requiring MFA would affect guest users when accessing published applications, and decided to update the blog post on this.

First of all you would need to create an Azure AD Conditional Access Policy where you:

Target the policy to your guest users, for example by creating a group (assigned or dynamic) with all guest users in your tenant.
Target the policy to your selected published Azure AD App Proxy Apps.
Setting the policy to require MFA.

Your guest users will have to set up their security verification methods in your tenant before they can authenticate with MFA as guests to your published application. They will be prompted to do that if they haven’t done it before at first time, but they can also do that by accessing their profile in your tenants myapps.microsoft.com. See below picture where my guest user can set up preferred methods for MFA in the elven tenant:

In this example I have set up Microsoft Authenticator on my mobile phone, and note the #EXT# identity which is the guest user for Elven tenant:

I can the select to launch the application as a guest user, and will be prompted authenticate with my selected method for MFA:

In my mobile phone I can approve, again I can see that I authenticate with my #EXT# guest account (most text in Norwegian, but you get the idea;)

See notes under for license requirements for MFA and guest users.

Notes and tips

Although Azure AD B2B is a free feature, creating local users in Active Directory and accessing resources like web servers, database servers and any third party applications you publish are not free and you will have to check your licensing requirements.

You shouldn’t synchronize your shadow guest users to Azure AD with Azure AD Connect.

Using Azure AD Conditional Access for require MFA is an Azure AD Premium feature, so you need EMS E3 or Azure AD Premium P1 licenses. You can then use up to 5 Azure AD B2B guests per EMS E3/AADP1 license you own, in a 1:5 ratio. So for example if you internally have 100 EMS licenses, you can require MFA for up to 500 Azure AD B2B guests.

And finally, Microsoft has noted that there will be guidance and documentation coming for best practice and governance for these Azure AD and on-premises AD guest users, as there can be a lot more complex enviroments than my example here, see this link: https://techcommunity.microsoft.com/t5/Azure-Active-Directory-B2B/AAD-Application-Proxy-and-B2B-Users/td-p/85249

Secure Access to Project Honolulu with Azure AD App Proxy and Conditional Access

2 Replies

Last week Microsoft announced Project “Honolulu”, the new Windows Server remote management experience, and now you can download a technical preview to install in your own data center, read here for more details: https://blogs.technet.microsoft.com/windowsserver/2017/09/22/project-honolulu-technical-preview-is-now-available-for-download/.

As the management is browser based, I thought this was a perfect fit for using Azure AD and publishing the management portal using Azure AD Application Proxy, and even better to secure the access using Azure AD Conditional Access. Consider the following diagram, where you instead of just publishing DNS and open Firewall to access the management server directly, I would instead use Azure AD App Proxy for secure access.

So lets get started setting this up!

Install and configure Project “Honolulu” technical preview

I will not get into great detail on installing Project “Honolulu” here, you can just follow the technical deployment documentation, but in my environment I have installed some servers running as Azure Virtual Machines joined to a single-forest, single-domain Active Directory. I have “on-premises” AD users and groups, and I’m running Azure AD Connect with Password Hash Synchronization.

On one of these Azure VM’s, I’ve downloaded and installed the Project “Honolulu” technical preview, with the following configuration:

Management Port: 6516
Self-signed Certificate

I’m now able to access the web based management internally, using https://azhon1.elven.local:6516. I can now proceed with publishing this externally with Azure AD App Proxy.

Configure Azure AD Application Proxy

Before you can publish applications using Azure AD Application Proxy, you have enable the feature in your Azure AD tenant, and install and configure one or more servers running Azure AD App Proxy Connector, and configure those in a connector group to use for the application. If you already have this configured, you can proceed to the next section. If you want more details, see this previous blog post, and the first sections on enabling App Proxy and innstalling connectors: https://gotoguy.blog/2017/02/21/publish-the-cireson-configuration-manager-portal-with-azure-ad-application-proxy/

Publish the Project Honolulu as an Azure AD App Proxy App

In the Azure AD management blade in the Azure Portal, select Enterprise Applications and click to add a new application. Select On-premises application:

Specify a Name for your application, and the Internal Url where you installed the Project Honolulu technical preview, including port number as shown below. If you want you can change parts of the External Url, even using your own domain and SSL certificate. I will just use the default here. I will use Azure Active Directory as Pre Authentication, meaning that no-one can access this website without beeing authenticated with Azure AD first. And last, I select my Connector Group of Azure AD App Proxy Connector Servers. PS! Remember that these servers need to be able to access the Internal Url directly, in case you have any Firewalls, NSGs or other components that might block traffic.

After adding the application, I have to do some more configurations. First, optionally, you can select a custom logo:

User assignment is required in this configuration, so next I need to assign some users to the application. Here I have added a normal domain user and a domain admin user. Both these users are synchronized from my local AD.

Next I wan’t to configure Single Sign-On, so that users that authenticate with Azure AD automatically will be signed in to the Project Honolulu management site. I select Integrated Windows Authentication for sign-on mode, and then I specify the internal application SPN for which is needed for Kerberos Constrained Delegation.

After that I have one more important step, and that is to configure delegation at my Application Proxy Connector servers. In my local Active Directory, open the Computer object for every server that acts as Azure AD App Proxy Connectors, and on the Delegation tab, add the server that you installed the Project Honolulu on, selecting http as the service. In my environment, I have added this now. I have some previous delegations for others servers as well.

We are now ready to test the application publishing via Azure AD!

Access Application using Azure AD

You now have basically two options for accessing the application:

Accessing the External Url directly, in my example this is https://projecthonolulu-elven.msappproxy.net/
Access the application using Azure AD Access Panel, https://myapps.microsoft.com

When using the Azure AD Access Panel, if your users has been assigned access, you will see the application published:

When launching that, I will be automatically logged in to the Project Honolulu web site, configured via SSO and Windows Integrated Authentication:

And I can start managing my configured servers:

So, now we have successfully configured an Azure AD App Proxy Application, and can connect securely from external url using SSO with Windows Integrated Authentication and Azure AD Pre Authentication. The application also requires that only assigned users can access the application.

In the next section I will configure Conditional Access for the application.

Configuring Conditional Access

When publishing this server management tool for external access, I wan’t to secure access as much as possible. For example, if one of my admins credentials have been leaked, I want that extra layer of security that users have to use Azure Multi-Factor Authentication when accessing the Project Honolulu application. I will configure that using Azure AD Conditional Access. On the application, I select Conditional Access as shown below:

I select to create a new policy, giving it a name:

I then select this to apply for all users:

Confirm that this policy applies to the Project Honolulu application:

On Conditions I can optionally configure conditions for sign-in risk, device platforms, locations and client apps, but I will just let this policy apply for all conditions for now, so I’m leaving Conditions as it is.

Under Access Control I select to Require Multi-Factor Authentication, and the set to Enable the policy. Note that I can select additional controls for even more secure access, but for now I just want to require MFA:

So, save the policy, and lets test how accessing the application works now.

If I either go directly to the external url, og via the Access Panel, I will now be prompted for MFA:

That concludes this blog post. I’m very excited for this new preview for Project “Honolulu”, and using the great Azure AD Application Proxy feature I can securely publish and access the management site from external locations and clients. And even better with Azure AD Conditional Access, I can create a policy that sets access control for multi-factor autentication requirements, and if I want I can even control which device clients and what apps they use to access.

Hopefully this has been helpful for you, if you have any questions reach out to me on Twitter or use the comments below this blog post 🙂

	Simon does How to Te… on Automatic Provisioning and Dep…
	Respond in bulk usin… on Blog Series – Power…
	Build your own Secur… on Add Graph Application Permissi…
	BM on Connect to Microsoft Graph in…
	The latest technolog… on Connect to Microsoft Graph in…

GoToGuy Blog

A Blog about Enterprise Mobility + Security, Azure AD, Datacenter Management, Service Delivery, Automation, Monitoring, Cloud OS, Azure and anything worthwhile sharing with the Cloud and Datacenter community.