Azure Application proxy is an exciting technology that’s available with Azure AD Premium. It allows you to publish internal web applications in a simple and secure manner.

Software Prerequisites

The proxy connector is an application that needs to be installed on a Windows Server 2012 R2 or Windows 8.1 + machine. The application itself is a ~4 MB download and even can be installed on the server that you are trying to publish (although I would not recommend this).

Network Requirements

The server that houses the proxy connector only requires outbound access. Specifically the following ports need to be open:

PORT NUMBER

DESCRIPTION

80

To enable outbound HTTP traffic for security validation.

443

To enable user authentication against Azure AD (required only for the Connector registration process)

10100 - 10120

To enable LOB HTTP responses sent back to the proxy

9352, 5671

To enable communication between the Connector toward the Azure service for incoming requests.

9350

Optional. To enable better performance for incoming requests.

8080

To enable the Connector bootstrap sequence and to enable Connector automatic update

9090

To enable Connector registration (required only for the Connector registration process)

9091

To enable Connector trust certificate automatic renewal



How it works

The proxy connector makes an outbound connection to the Azure proxy in the cloud thus allowing a bi-directional TCP/IP transmission. Before a user can access the internal web application, the user’s account is authenticated against Azure AD (pre-authentication). Afterwards, if Kerberos authentication is enabled for the applications, the users will experience a single-sign on experience. If not, the user needs to authenticate to the application.

Publishing OWA

To test out the proxy, I’ve decided to publish Exchange 2010 OWA which is hosted in my lab without any external presence. My goal is to allow for a single sign on experience. I will need to do the following to meet this requirement:

1) Enable Kerberos authentication for Outlook Web App.

2) I need to ensure SPN’s and Kerberos Constrained Delegation is properly setup.

Enable Kerberos Authentication for OWA

To do this, logon to the Exchange Management Shell (2010)—>Server Configuration—>Client Access

Go to the OWA virtual directory and edit the properties. Change the authentication method from forms-based authentication to “Integrated Windows Authentication”

Now we need to delegate the server that has the connector installed with the rights to request a Kerberos ticket on behalf of the Exchange server. To achieve this, go Active Directory Users and Computers, and double click on the computer that has the Azure connector installed.

Go to the delegation tab and add the services (HTTP) of the Exchange server that can be delegated.

Configure Azure AD Premium

Create a new application in Azure AD:

PreAuthentication Method: Set to Azure Active Directory.

Translate URL In Headers: Set to No since Exchange needs host headers to be preserved.

Internal Authentication Method: Set to Integrated Windows Authentication (Kerberos). If Kerberos is not possible, the user will have to login to the application.

Internal Application SPN: Provide the SPN for the Exchange server.

 

Now navigating to the Azure Application Proxy URL yields this:

https://owapage-jenutest.msappproxy.net/OWA/

Sign into the Azure Portal using your AD credentials (UPN and password).

Once successfully authenticated, you will be redirected to OWA page and logged in using Kerberos authentication.

Recommendation:

Azure Application Proxy is a great tool to publish internal web applications securely. In most environments, publishing an application wouldn’t involve making changes to the firewall since the proxy connector only needs outbound access.

Any application published via Azure Application Proxy can be added to the Application Portal which the users can access from a single page; if they are logged in they would go directly to the OWA page without the need to be authenticated twice. To take this further, multi-factor authentication can be easily leveraged to add another layer of security. To provide a higher level of availability the connector can be installed on multiple machines. In the case one server is down, the application proxy would continue to work.

As part of a recent task to relocate an SCCM database to faster spindles, I went ahead used the detach/attach method to accomplish this. After the database relocation there were no issues until we tried to create a new application. I received the following error:

 

After checking the logs, I found the following event being reported continuously:

After some digging around, I found a Microsoft KB that addresses this exact problem: http://support.microsoft.com/kb/2709082

Part of the issue is that when you detach and attach a database ( a perfectly supported SQL action) the trustworthy database flag is turned to off. As a result, SCCM DLL’s are not successfully loaded. After following the steps outlined in the KB article, I was able to create applications without any issues.

Recommendation: Use backup/restore method to relocate the database than using attach/detach.

I was working at a client with SCCM 2012 R2 OSD configuration and I was getting the error “Failed to Resolve Select Task Sequence Dependencies” every time testing the task sequence. I checked for the usual suspects and ensured that all applications and packages were distributed to the Distribution Points.

Initially, I thought the application that was causing the error was corrupted. So I went ahead and refreshed the content (“Update Content” as it’s formally known”). I attempted to run the task sequence again and then noticed that the same error came up referencing a different application. I began to see a pattern and all the applications that were referenced in the error all had version 1.

To increment all application versions, I used the following script that I pieced together from other sources:

Import-Module ‘C:\Program Files (x86)\Microsoft Configuration Manager\bin\ConfigurationManager.psd1’
CD SiteCode:
$applications=Get-CMApplication |Select-Object ApplicationName,LocalizedDisplayName, CIVersion |Where-Object CIVersion -eq “1”
foreach ($app in $applications)
{
$app=$app.LocalizedDisplayName
Write-host “Application :” “$app” -ForegroundColor DarkCyan

$dpttypes=Get-CMDeploymentType -ApplicationName $app

foreach ($dpt in $dpttypes)
{
$dptname=$dpt.LocalizedDisplayName
Write-Host “Deployment Type:” “$dptname” -ForegroundColor DarkGreen
Update-CMDistributionPoint -ApplicationName $app -DeploymentTypeName $dptname
}
}
Note: Even after changing all versions to 2, I still had one or two apps needed to be incremented before I could proceed with the TS.

After logging into my SCCM 2012 R2 server and running a report, I was getting an error to check network connectivity to the Report Server. After logging into my SQL 2012 SP2 server, I saw the following error message every time I ran a report:

_Log Name: Application
Source: MSSQLSERVER
Date: 12/5/2014 10:32:42 PM
Event ID: 7886
Task Category: Server
Level: Error
Keywords: Classic
_
Description:
_A read operation on a large object failed while sending data to the client. A common cause for this is if the application is running in READ UNCOMMITTED isolation level. This connection will be terminated.
_
I checked the database size and initially thought the autogrowth threshold was low. I was still getting the error after adjusting the autogrowth so I then thought it might be an issue with the database itself and ran a DB check.

ALTER DATABASE ReportServerDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
BEGIN TRANSACTION;
DBCC CHECKDB (‘ReportServerDB’, REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE ReportServerDB SET MULTI_USER;

I had to run these commands couple of times to fix the corruption in the database.