Publishing Work Folders with Web Application Proxy

Work Folders and the Web Application Proxy are probably two of the most exciting new features in Windows Server 2012 R2 and Windows 8.1. These features create a whole lot of new possibilities for Bring Your Own Devices to provide controlled access to data stored on the corporate network. I had already checked out Work Folders and the Web Application Proxy. But what about using these together? This enables corporations to use the Web Application Proxy for claims based pre-authentication and to add Multi Factor Authentication.

A few weeks ago I started building the lab environment setup for AD FS and Connect to applications and Services with Web Application Proxy as described on TechNet. As an addition to these walkthroughs, I published a walkthrough how to setup a PKI for the Workplace Join Lab.

The resulting topology of these very useful step-by-step articles looks like this:

If this is all working, you have the ideal start for the final goal of this article. Only the Work Folders server is still missing.

Important note:
For the entire setup, ensure that you are using Windows Server 2012 R2 and Windows 8.1 with at least the following hotfixes installed:

  • KB2887595
  • KB2883200

Please make sure that you have the previous labs working before you proceed.

For the rest of this article I got lots of information from the Windows product team that also publishes on FileCab. Without their help this article would have never seen the day of light. Checkout FileCab for more information about Work Folders and other Microsoft storage technologies.

Step 1: Setup a Work Folder share with SSL encryption

As this article is about publishing Work Folders, you also need to setup a Work Folders server on the internal network. The step-by-step for setting up Work Folders on TechNet describes how to setup Work Folders without SSL. Without SSL Work Folders cannot be published with the Web Application Proxy, as the Web Application Proxy can only publish https and not http.

You can still use the guide to setup a Work Folders server to publish externally, but skip the section “Lab testing specific settings” that enables the client to use http instead of https to connect to the Work Folders share.

Configure the Work Folders Server with SSL

  • Obtain and install an SSL Certificate for the Work Folders server. Make sure the certificate contains DNS entries for both the server FQDN and for the Work Folders host in your domain. My DNS entries looked like:
    • Filesrv.nextxpert.com
    • Workfolders.nextxpert.com
  • Get the certificate Thumbprint of the certificate in PowerShell. Start PowerShell and type the following command:
    • Get-childitem –Path cert:\LocalMachine\My
  • Bind the certificate to the Work Folders service from the Comand prompt. Start an elevated Command prompt and run the following command, replacing <Cert thumpprint> with the value you just obtained:
    • netsh http add sslcert ipport=0.0.0.0:443 certhash=<Cert thumbprint> appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=My

Now test if you can access the Work Folders from a client on the internal network as described in “Step 11: Work Folders setup” from step-by-step for setting up Work Folders on TechNet.

The topology should now look like this:

Configure the Work Folders Server for AD FS Authentication

In order to publish Work Folders with Web Application Proxy, the Work Folder server must use AD FS (OAuth2) authentication instead of Windows Authentication.

On the Work Folders Server, open Server Manager and browse to File and Storage Services | Servers. Right click the server name and select Work Folders Settings.

In the Work Folders Settings Dialog, under Authentication, select Active Directory Federation Services. Type the FQDN of the ADFS server as the Federation Service URL, and click OK.

You can also use PowerShell to configure the Work Folder Server for AD FS authentication using the following command:

  • Set-SyncServerSettings -ADFSUrl <AD FS URL>

Step 2: Configure the ADFS Server

This was the hardest part of building this infrastructure. At this point I expected to find an XML somewhere, defining the Relying Party Trust (RP) to import on the AD FS server. Just like the procedure used to create the RP for claimapp in the AD FS lab. Unfortunately there is no such file, and we have to use a PowerShell script to create the RP.

The Relying Party settings must include the UPN in the claims since the Work Folders will use it to impersonate as the user.

Here is the script I used:

 

$ECSIdentifier = "https://Windows-Server-Work-Folders/V1";
$ECSDisplayName = "EnterpriseClientSync";
$TransformRuleString = '@RuleTemplate = "LdapClaims" @RuleName = "Ldap" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"), query = ";userPrincipalName,displayName,sn,givenName;{0}", param = c.Value);' ;
$AuthorizationRuleString = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit",Value = "true");' ;
Add-ADFSRelyingPartyTrust -Identifier $ECSIdentifier -Name $ECSDisplayName -IssuanceTransformRules $TransformRuleString -IssuanceAuthorizationRules $AuthorizationRuleString -EncryptClaims:$false -EnableJWT:$true -AllowedClientTypes Public;

 

Notice that the RP Identifier is hardcoded as https://Windows-Server-Work-Folders/V1. There is no need to reference the identifier to the actual server running Work Folders. A reference to the actual server is only needed when the server is being published from the Web Application Server as described in the following section.

Step 3: Configure the Web Application Proxy

First obtain the SSL certificate for publishing the Work Folders server. If you already have a wildcard certificate on the Web Application Proxy, you can use that to publish Work Folders. Otherwise you require a certificate that contains at least the entries as described for the Work Folders Server.

Now, obtain the SSL certificate thumbprint you will use to publish the Work Folders server. You will need the thumbprint later to publish Work Folders with PowerShell.

You can use PowerShell to obtain the thumbprint. Start PowerShell and type the following command:

  • Get-childitem –Path cert:\LocalMachine\My

Copy the thumbprint from the certificate that you will use to publish Work Folders.

Check the Web Application Proxy configuration for the existence of the OAuth URL. Work Folders can only be published using OAuth2. This requires the existence of the OAuth URL.

You can use PowerShell to obtain the current value of the OAuth URL. Start PowerShell and type the following command:

  • Get-WebApplictionProxyConfiguration

Check if the value of OAuthAuthenticationURL looks like https://$farmFqdn/adfs/oauth2/authorize

Now you can use PowerShell to publish the Work Folders Server with OAuth. Start PowerShell and run the following script, replacing *.nextxpert.net with the CN of your public certificate and filesrv.nextxpert.net with the FQDN of your file server:


$cert = Get-childitem –Path cert:\LocalMachine\My | Where-Object -Property Subject -EQ -Value "CN=*.nextxpert.net"
$WAPAppName = "EnterpriseClientSync"
$ExternalURL = "https://filesrv.nextxpert.net/"
$BackEndServerURL = "https://filesrv.nextxpert.net/"
Add-WebApplicationProxyApplication -Name $WAPAppName -ExternalURL $ExternalURL -ExternalCertificateThumbprint $cert.Thumbprint -BackendServerUrl $BackEndServerURL -ExternalPreauthentication ADFS -ClientCertificateAuthenticationBindingMode None -BackendServerCertificateValidation None -ADFSRelyingPartyName EnterpriseClientSync -UseOAuthAuthentication

AutoDiscovery

Just like Exchange, Work Folders has an AutoDiscovery mechanism that refers users to their appropriate Work Folders Server. AutoDiscovery works out of the box on the corporate network, when a CNAME record named ‘workfolders’ is created in DNS that links to the Work Folders server.

Publication of AutoDiscovery requires an extra rule on the Web Application Proxy. I tested this with a single Work Folders server on the corporate network. It enables a user to connect to his/her Work Folder by only supplying the users’ UPN. Without the extra rule, the user must address his/her specific Work Folders Server URL.

You can use the following PowerShell script to publish AutoDiscovery. The publishing rule refers to the http url of the Work Folders server. As this is traffic on the internal network it is not considered as an additional risk.

$WAPAppName = "WorkFoldersDiscovery"
$ExternalURL = "https://workfolders.nextxpert.net/"
$BackEndServerURL = "http://filesrv.nextxpert.net/"
Add-WebApplicationProxyApplication -Name $WAPAppName -ExternalURL $ExternalURL -ExternalCertificateThumbprint $cert.Thumbprint -BackendServerUrl $BackEndServerURL -ExternalPreauthentication ADFS -ClientCertificateAuthenticationBindingMode None -BackendServerCertificateValidation None -ADFSRelyingPartyName EnterpriseClientSync -UseOAuthAuthentication

DNS

When services like Work Folders and Device Registration are published outside of the corporate network, it is required to use a split-DNS setup. This means that you will be using the same hostnames on the outside as you are using on the inside. Only on the outside the IP addresses will differ from the addresses on the inside. The outside addresses will typically refer to addresses hosted on the external interface of the Web Application Proxy. As the Web Application Proxy supports Single Name Indication (SNI), you are now able to host multiple SSL hostnames on a single IP address.

In my demo environment the external DNS zone currently looks like this:

Hostname Type Data
filesrv

A

133.38.10.1
workfolders

CNAME

filesrv.nextxpert.net
adfs

A

133.38.10.1
deviceregistration

CNAME

adfs.nextxpert.net
corpweb

A

133.38.10.1

If DNS for you domain contains the required records, you should now be able to access Work Folders through the Web Application Proxy.

The final topology should now look like this:

Troubleshooting

During the process, I found out that things will go wrong. When something goes wrong you should check for details in the event logs. Most of the times these log entries will provide the extra information required to fix your issues. If the message doesn’t make sense, ensure that you installed the required updates.

These are my most consulted event logs:

  • On the client
    • Applications and Services Logs\Microsoft\Windows\WorkFolders\Operational
  • On the Web Application Proxy
    • Applications and Services Logs\Microsoft\Windows\Web Application Proxy\Admin
  • On the AD FS Server
    • Applications and Services Logs\AD FS\Operational

This takes me to the end of my longest blog article ever. Many thanks to the Windows product team for helping me to work this out.

Advertisements
This entry was posted in Security, Web Application Proxy, Windows 8.1, Windows Server 2012 R2, Work Folders. Bookmark the permalink.

7 Responses to Publishing Work Folders with Web Application Proxy

  1. Excellent work, thanks for this!

    Do you know if this is only supposed to work with username/password and not with x.509 cert auth? I’m getting EventID 516: The sync server needs the user’s current username and password when I use a cert.

    • rayc25 says:

      Fredrik, you’re welcome!

      I have not yet tested with x.509 cert auth. I expect that it is possible. Are you using a Smart Card for x.509 cert auth? I have to look into this.

      • Yes, we’re using SmartCards. I can Workplace Join using the SmartCard, and we can successfully auth to services both external and internal like Dropbox, Sharepoint and others so I know that our AD FS configration is working, but not with workfolders unless I enable Forms auth and use a username/password combo.

      • rayc25 says:

        Frederik, I gave your scenario some thought. But, how usefull is it to require cert based authentication for Work Folders? The credentials will be reused in the background after the initial configuration, which can be a challenge for cert authentication based on Smart Cards. I wouldn’t be surprised if non-support of cert based authentication for Work Folders is ‘by design’. Microsoft will probably push to other authentication factors (in claims) to force the additional authentication factor.

        Can you post your findings in the TechNet forums? Hopefully this will lead to an official statement from someone at Microsoft.

  2. Anthony says:

    Excellent guide. I set up a Lab environment with the topology above and followed the links, but I have problem getting internet on my corpweb, corpdc and Adfs server. My edge (Web application Proxy) has two network cards, one facing internet (WAN) and the other Corp Network(LAN).

    internet facing card IP: 131.107.0.2
    Corp Network IP: 10.0.0.2
    How can I configure my edge (Web application Proxy) server to allow internet to my Corp network?

    I will be glad if you can help me out.

    Regards

    • rayc25 says:

      Anthony, if you have a single entry point to the Internet, then I recommend to use a single network interface on the Web Application Proxy and publish that on the Internet router. I don’t think it’s a good idea to use the Web App Proxy both for incoming and outgoing Internet traffic.

  3. Pingback: Create DNS records for Microsoft Intune including Workplace Join & Work Folders | System Management

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s