Deploying Work Folders with AD FS and Web Application Proxy (WAP)

Overview

Work Folders is a new component introduced in Windows Server® 2012 R2. It allows Information Workers to sync their work files between their devices. This functionality is powered by the Work Folders service that can be enabled as a Windows Server 2012 R2 File Services sub role.

Web Application Proxy is a new Remote Access role service in Windows Server® 2012 R2. Web Application Proxy provides reverse proxy functionality for web applications inside your corporate network to allow users on any device to access them from outside the corporate network. Web Application Proxy pre-authenticates access to web applications using Active Directory Federation Services (AD FS), and also functions as an AD FS proxy.

Setting up and configuring systems can be some of the most time consuming and tedious part of the job. This blog is aimed at making the deployment of Work Folders, AD FS and Web Application Proxy in Windows Server 2012 R2 to be as easy as possible.

This blog post will provide walk-through instructions on how to set up Work Folders with AD FS and Web Application Proxy (WAP) for production and test environments. The goals of the blog are:

• provide a walk-through of deploying and setting up an environment that will be what most customers will like to setup in a real-world environment
• provide a detailed installation of configuring the environment via the UI
• provide scripts that will let the entire environment be configured in less than 15 minutes.

This blog will be longer than average as one of the goals of the blog is to provide a complete documented end-to-end overview of deploying Work Folders with AD FS and WAP.

A set of powershell scripts are also  provided that automate all of the steps in this blog for a Test environment, which includes creating the self-signed certs needed for AD FS and Work Folders. Once you have received your certificates (from the CA of your choice), the environment can be changed over for production use. Of course, sometimes you just want to setup an environment of product as quickly as possible without waiting to get certificates from a CA or having to setup a certificate server.

The scripts will created the VMs for non-domain joined and domain joined machines using an unattended xml that is dynamically generated using values from the configuration file.

The scripts makes the deployment of the entire environment less than 12 minutes . Of course, your mileage may vary +/- a couple of minutes depending on the hardware that you are using. The test environment consists of AD FS, Work Folders, WAP and two test clients (one domain joined and another non-domain joined). Work Folders will be configured with a default Sync Share that all users added and also setup to use AD FS. The sync share will have SMB access enabled and also have the shares setup to require encryption. AD FS will be setup with the Relying Party information needed to talk to Work Folders. WAP will be setup to use the AD FS endpoints so that clients on the internet/external network can use AD FS.   The scripts are also written to use remote powershell for the deployment of the environment.  This means that the entire environment can be setup non-interactively from the Host machine and you do not need to log into each VM. 

If you are interested in just getting to the powershell scripts and setting up your environment that way, The section on the scripts is located near the end of the blog

Pre-requisite

In this blog post, I’ll provide you with the step by step guide to set up Work Folders with AD FS and WAP. When finished, you will have a complete functioning environment configured with self-signed certificates.

To follow this step by step guide, you will need to have the following computers ready:

• Domain controller: a server with the Active directory Domain Services role enabled, and configured with a domain (for example: Contoso.com) and running Windows Server 2012R2. A Domain controller running at least Windows Server 2012R2 is only needed to support Workplace Join, which will we also be setting up.
• Two servers joined to the domain (Contoso.com). Each machine runs Windows Server 2012 R2 build. (one machine will be for AD FS and another for Work Folders)
• One Server that is not domain-joined. This server will run WAP and will need one network card for the Network domain (Contoso.com) and another network card that will be external domain (Fabrikam.com)
• One domain-joined client computer running Windows 8.1
• One non-domain joined client computer running Windows 8.1 on the Fabrikam’s virtual network

Download Windows Server 2012 R2 eval versions here:

http://technet.microsoft.com/en-US/evalcenter/dn205286.aspx

Download Windows 8.1 Enterprise eval versions here:

http://technet.microsoft.com/en-US/evalcenter/hh699156

The computers can be physical or VMs. In the event that you do not have those computers already, you can run the provisioningEnvironment.ps1 in the attached zip and it will create all of the required VMs needed, with the exception of the Domain Controller. Before running the script, be sure to edit the file vms.txt to update the network information appropriately. Instructions for editing the scripts are that the end of this blog.

Once done, you’ll have a topology that looks like the below:

This blog will focus on setting up WAP, AD FS and Work Folders and WAP. In our scenario, WAP will not being joined to the domain. WAP can be deployed either deployed to a domain or not. There are some deployments in which you need you might wish to have WAP joined to a domain such as using Windows Authentication. If you plan to use Integrated Windows authentication, the Web Application Proxy server must be joined to an AD DS domain and you must also configure Kerberos Constraint Delegation (KCD).

Setup

For setting up the environment we will setup the environment in the following order:

· AD FS

· Work Folders

· Web Application Proxy

· The domain-joined workstation and non-domain joined workstation

We are going to assume you have the following setup before you dive in.

• Active Directory Forest (preferably with DNS enabled, but not required) running Windows Server 2012R2. Windows Server 2012 R2 is only required if you wish to use device registration for Work Place join, otherwise you need can use Windows Server 2012
• A VM/Server for AD FS Server running Windows Server 2012 R2
  • Domain Joined
  • Valid network configuration
• A VM/Server for Work Folders running Windows Server 2012 R2
  • Domain Joined
  • Valid network configuration
• A VM/Server for Web Application Proxy running Windows Server 2012 R2
  • Domain Joined
  • Valid network configuration

The scripts provisionEnvironment and setupEnvironment will do the following:

· create all VMs needed for the lab

· domain join the machines that need to be domain joined

· install and fully configure the respective server roles on AD FS, Work Folders and WAP

· create and install the self-signed certificates on all appropriate machines

The end result is that you will have a completely deployed environment that is configured with self-signed certificates. The two client machines (one domain joined on Contoso corpnet and another non-domain joined on an external network) will be ready to start using Work Folders either on-premise or through WAP. All that remains is for the user to initiate the Work Folders join process.

Setting up AD FS

Pre-Install Work

Before beginning to install AD FS, there are two things that you should do ahead of time that will save you valuable time and make the setup process quicker.

The first item that must be setup is an Active Directory domain administrator account for the AD FS service to run under. For the test environment in the blog we will be using the default contoso\administrator account. Using the default admin account is something not recommended for production. Depending on your company polices, requesting and receiving a domain admin account may take some time, so be sure to get this done up front.

The second item that you will need to successfully setup AD FS is to have a SSL SAN certificate for server authentication. For production you will want to use a publically trusted certificate.

There are many commercial CAs from which you can purchase the certificate from. You can find the CAs trusted by Microsoft on this page: http://support.microsoft.com/kb/931125. Another alternative is to get a certificate from the company Enterprise CA.

To purchase certificate, you need to visit the CA’s website, and follow the instructions on the website. Each CA has a different procedure on certificate purchase.

For our test environment we will be using a self-signed certificate. It is important to note that AD FS does not support CNG certificates, which means that you cannot create the self-signed certificate using the powershell cmdlet New-SelfSignedCertificate. The attached zip file contains a powershell script called makecert.ps1 which will create a self-signed certificated that will work with AD FS and prompt for the SAN names that will be needed to create the certificate.

Creating AD FS Self-signed certificate

1. Copy the file makeCert.ps1 to the AD FS machine.
2. Open a Admin PowerShell window
3. Set the execution policy to unrestricte
   1. PSC:\temp\scripts>.\makecert.ps1C:\temp\scripts>Set-ExecutionPolicy–ExecutionPolicy  Unrestricted
4. Change to the directory where the script was copied
5. Execute the makeCert script
   1. PSC:\temp\scripts>.\makecert.ps1
6. When prompted to change the subject certificate, enter the new value for the subject. In our case it will be blueadfs.contoso.com.
7. When prompted to enter SANS, enter Y and then enter the SAN names (one at a time)i.e. blueadfs.contoso.com <return> enterpriseregistration.contoso.com. When all of the SAN names have been entered, press return on an empty line
8. When prompted to install the certificates to the Trusted Root Certification Authority, press Y

The AD FS certificate needs to be a SAN certificate with the following values:

<AD FS service name>.<domain>

enterpriseregistration..<domain>

<machine name>.<domain>

e.g.

blueadfs.contoso.com

enterpriseregistration.contoso.com

2012R2-ADFS.contoso.com

The enterpriseregistration SAN is needed for Work Place join.

Setting up Server IP address

Change your Server IP to static IP, for this blog I’m using IP class A which is 192.168.0.160 / subnet mask : 255.255.0.0 / Default Gateway : 192.168.0.1 / Preferred DNS : 192.168.0.150 (the IP address of your Domain Controller)

Install AD FS

Log into the VM or machine that you plan to install AD FS and open the Add Roles and Features Wizard.

To install AD FS, select the Active Directory Federation Services Role under Server Roles and click next

If you plan on using your AD FS server as part of a Hybrid Deployment and will be using DirSync, select install the .Net Framework 3.5 features. To install .Net 3.5, you’ll need to mount the Windows Server ISO as a DVD drive in your VHD.

On the confirmation page you will see a note informing you that the Web Application Proxy role cannot be installed on the same computer as AD FS. Click Next.

If you did not choose you install .Net 3.5, you’ll see a confirmation screen that looks like the below.

If you choose to install .Net 3.5, you’ll see a confirmation screen that looks like the below. Make sure to provide an alternate source path to the Windows Server 2012 R2 iso. i.e. d:\sources\SxS

If you do did not mount the Windows Server 2012 R2 iso, you’ll receive an error screen like the below and you will need to restart the entire install process for AD FS.

To accomplish the equivalent install of AD FS through powershell, use the below commands:

Configuring AD FS

The next step is to configure AD FS.

Select the Warning Flag at the top of Server manager and click on the link that says “Configure the federation service on this server”.

The link will launch the Active Directory Federation Services wizard. The first page after the Welcome screen will be for the domain administrator account that will be used as the dedicated AD FS account.

Enter the subject name of the SSL certificate to be used for AD FS communication and set the name of the Federation Service Name. It is important to note that for the Federation Service name to not use the name of an existing server in the environment. If you do use the name of an existing machine, the AD FS installation will fail and will need to be restarted again.

Enter the name that you would like to be used for the Managed Service Account.

Select use the Windows Internal Database and press Next.

The review screen will show you an overview of the options you have selected. Press next.

The next screen will be the Pre-requisites check page. If everything shows as good, press Configure.

If you did you the name of the AD FS server or the name of another existing machine, you’ll receive the below error message. You should start the install over and choose a name other than the name of the AD FS machine or any existing machine.

When the configuration completes successfully you’ll see the below screen indicating that AD FS was successfully configured.

Here’s how to accomplish the same via powershell:

Install AD FS

Create the Managed Service Account

Setup the AD FS Farm

Setting up the AD FS will use the Managed Service account used above and the certificate you created in the pre-configuration steps.

AD FS Post-configuration

There are four post configuration work after setting up and configuring AD FS. They are:

• Configuring DNS entries
• Setting up Relying Trust for Work Folders
• Exporting the AD FS certificate to install on the other machines
• Configuring access to the private key

Configure DNS entries

You will need to create two DNS entries for AD FS. These are the same two entries that were used in the Pre-Configuration steps when the SAN certificated was created.

<AD FS service name>.<domain>

enterpriseregistration..<domain>

<machine name>.<domain>

e.g. for our setup

blueadfs.contoso.com

enterpriseregistration.contoso.com

Create the A/Cname records on AD for AD FS

On your DC, open up the DNS manager

Expand the Forward Lookup Zones, right click on your domain and select New Host (A).

The New Resource Record form will open. Enter in the alias for AD FS in the Alias name field. In the lab case it will be “blueadfs”. The alias must be the same as what was used as the subject in the certificate used for AD FS earlier. Ie. If the subject was adfs.contso.com, then the alias entered here must be adfs. In the IP field, enter the IP address for the AD FS Server, i.e 192.168.0.160.

It’s *important* to note that when setting up AD FS via the UI instead of via powershell, you must create an A record instead of a CNAME record. The reason is that the SPN that gets created via the UI will only contain the alias that is used in setting up the AD FS Service as the HOST/.

In the powershell script, we created the SPN by including the alias as the HOST/ but also include setting two HTTP/ entries. These entries allow the SPN to redirect from the alias to the host machine.

Add in another alias (New Alias (CNAME) )name for the ‘enterpriseregistration’ cname. This ‘enterpriseregistration’ alias is used for Device Join and must be called ‘enterpriseregistration.

The powershell command to accomplish the above is below. The command must be executed on your Domain controller.

Add-DnsServerResourceRecord  -ZoneName"contoso.com"-Nameblueadfs-A-IPv4Address192.168.0.160

Setup AD FS Relying Trust for Work Folders

We can setup/configure the Relying Trust for Work Folders, even though Work Folders has not been setup yet. The Relying Trust must be setup for Work Folders to use AD FS. Since we’re setting up AD FS, it is a good time to do this step.

Select AD FS Management

On the Right panel, under Actions, click on Add Relying Party Trust Wizard

The first page of the Wizard is a Welcome screen. Click Next to start the wizard

Select Enter data about the relying party manually

Enter “WorkFolders” In the Display name field and click Next.

Select the AD FS profile option for creating the relying party trust.

Click Next on the Configure Certificates page. These certificates area used as the optional token encryption certificates, and not needed for our configuration.

On the “Configure URL” screen, just click next.

On the “Configure Identifier page”, set the Target identifier to https://windows-server-work-folders/V1 . This identifier is a hard coded value used by Work Folders, and is sent by the Work Folders service when it is communicating with AD FS.

Click Next on the Configure Multi-factor authentation page.

On the Issuance Authorization page, select “Permit all users to access the relying party”

Click Next on the Read to Add trust page.

After the configuration is finished the last page of the Wizard will display and show that the configuration was successful.

Select the checkbox for editing the Claims Rules and press close.

The Edit Claim Rules form will now open.

In the Claim Rules type, select “Send LDAP Attributes as Claims”

On the Transform claim page, do the following:

• Add Transform claim rule Name: WorkFolders
• Select Active Directory for the Attribute Store

Do the following:

Ldap map

User-Principal-Name   UPN

Display Name  –> Name

Surname  –> Surname

Given-Name  –> Given Name

Click Finish when done and you’ll now see your new rule showing up in the Issuance Transform rules page.

Next, click the Issuance Authorization Rules tab and you’ll see that the rule for access is set to “Permit Access to All Users”

Final steps

Once all this is done, we need to finish the configuration by running four commands in PowerShell. This four commands set needed for Work Folders to successfully communicate with AD FS. These options on the Relying Partying cannot be set through the UI. The options

• enable the use of JWT
• disable encrypted claims
• enable auto-update
• sets issuing Oauth refresh tokens to All Devices.

Enabling Work Place Join

To enable device registration for Work Place join, you will need to run the following three powershell calls, which will configure device registration and set the global authentication policy.

Exporting Certificate

The self-signed AD FS certificate will need to be exported and installed on the following machines in the test environment:

• Work Folders
• Web Application Proxy
• Domain joined Windows 8.1 client
• Non-domain joined Windows 8.1 client

To export the certificate:

· 1.  Click Start, and then click Run.
2.  Type MMC.
3.  On the File menu, click  Add/Remove Snap-in.
4.  In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.
5.  Select Computer account, and then click Next.
6.  Select Local computer: (the computer this console is running on), and then click Finish.
7.  Click OK.
8.  Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
9.  Right-click Certificates, click All Tasks, and then click Export...

Go through the Certificate Export Wizard

Export the private key

Use the default options

Enter in a password for the certificate. Remember what password you use as you’ll need to use the pass later when you import the certificate to the other devices.

Enter in a location and name for the certificate and then finish the wizard.

Managing Private Key Setting

The AD FS service account needs the permissions to access the private key of the new certificate. You should do this again when you replace the communication certificate after it expires. To do this, follow these steps:

1. Click Start, and then click Run.

2. Type MMC.

3. On the File menu, click  Add/Remove Snap-in.

4. In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.

5. Select Computer account, and then click Next.

6. Select Local computer: (the computer this console is running on), and then click Finish.

7. Click OK.

8. Expand Console Root\Certificates (Local Computer)\Personal\Certificates.

9. Right-click Certificates, click All Tasks, and then click Manage Private Keys.

10. Add the account that is running the AD FS Service, and then give the account at least read permissions

If you do not have the option to manage private keys, you may have to run the following command:
certutil -repairstore my *

Screenshots

Verifying AD FS is Operational

1. https://blueadfs.contoso.com/federationmetadata/2007-06/federationmetadata.xml.

In your browser window, if you can see the federation server metadata without any Secure Socket Layer (SSL) errors or warnings, your federation server is operational.

2. You can also browse to the AD FS sign-in page where your federation service name is appended with adfs/ls/idpinitiatedsignon.htm, for example, https://blueadfs.contoso.com/adfs/ls/idpinitiatedsignon.htm. This entry displays

Setting up Work Folders

Pre-Install Work

• A VM/Server for Work Folders running Windows Server 2012 R2
  • Domain Joined
  • Valid network configuration

For our test environment, we have joined the VM that will be running Work Folders to the Contoso domain and setup the network interface as below. If you are setting up VMs, remember that the Default Gateway is the IP address of the Virtual Network adapter on the Host Machine (192.168.0.1 in our case)

Setting up Server IP address

Change your Server IP to static IP, for this blog I’m using IP class A which is 192.168.0.170 / subnet mask : 255.255.0.0 / Default Gateway : 192.168.0.1 / Preferred DNS : 192.168.0.150 (the IP address of your Domain Controller)

Create the cname records on AD for Work Folders

On your DC, open up the DNS manager

Expand the Forward Lookup Zones, right click on your domain and select New Alias (CNAME)

The New Resource Record form will open. Enter in the alias “workfolders” in the Alias name field. In the Fully qualified domain name field, enter the fully qualified domain for the Work Folders Server, i.e 2012R2-WF.contoso.com

The powershell command to accomplish the above is below. The command must be executed on your Domain controller.

Install AD FS certificate

Copy the AD FS certificate that was created to when setting up AD FS and install the AD FS certificate into the local computer certificate store. To do this, follow these steps:

1.  Click Start, and then click Run.
2.  Type MMC.
3.  On the File menu, click  Add/Remove Snap-in.
4.  In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.
5.  Select Computer account, and then click Next.
6.  Select Local computer: (the computer this console is running on), and then click Finish.
7.  Click OK.
8.  Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
9.  Right-click Certificates, click All Tasks, and then click Import.

For our test environment we will be using a self-signed certificate. It is important to note that AD FS does not support CNG certificates, which means that you cannot create the self-signed certificate using the powershell cmdlet New-SelfSignedCertificate. The attached zip file contains a powershell script called makecert.ps1 which will create a self-signed certificated that will work with AD FS and prompt for the SAN names that will be needed to create the certificate.

Creating Work Folders Self-signed certificate

1. Copy the file makeCert.ps1 to the AD FS machine.

2. Open a Admin PowerShell window

3. Set the execution policy to unrestricted

PSC:\temp\scripts>Set-ExecutionPolicy-ExecutionPolicyUnrestricted

4. Change to the directory where the script was copied

5. Execute the makeCert script

PSC:\temp\scripts>.\makecert.ps1

6. When prompted to change the subject certificate, enter the new value for the subject. In our case it will be workfolders.contoso.com.

7. When prompted to enter SANS, enter Y and then enter the SAN names (one at a time)i.e. workfolders.contoso.com <return> 2012R2-WF.contoso.com <return> . When all of the SAN names have been entered, press return on an empty line

8. When prompted to install the certificates to the Trusted Root Certification Authority, press Y

The Work Folders certificate needs to be a SAN certificate with the following values:

workfolders.<domain>

<machine name>.<domain>

e.g.

workfolders.contoso.com

2012R2-WF.contoso.com

Install Work Folders

Start the "Add Roles and Features Wizard” and select Next.

Select Role-based or feature based installation

Select the current server and press Next.

On Server Roles, open the File and Storage Services Role, expand the File and iSCSI Services role and select Work Folders.

Optionally also install the IIS Management tools. These tools will provide some powershell management scripts that will make binding the Work Folders certificate easier. Binding the Work Folders certificate to the port being used for SSL will require using powershell or the cmdline.

One the Role Services page for IIS, just enable the Management scripts and Tools.

On the confirmation page, press Install

Configure Work Folders

After Work Folders has been installed, we will need to complete the setup by configuring Work Folders.

Open Server Manager, Select File and Storage Services and Work Folders.

Click on the link in the Work Folders window to create a sync share.

Click next on the first screen.

Select the server and enter a path for the Work Folders data to be stored.

If the path does not exist, you’ll be prompted if you want to create it.

On the User Folder Structure page, select User alias and then press Next

On the Sync Share Name tab enter the name for the sync share. For our example we used “WorkFolders”. Press Next

On the Sync Access page, add in the users or groups to have access to the new Sync Share. For our example we have granted access to all domain users. Press Next when done.

On the Device Policies page, select Encrypt Work Folders and Automatically lock screen and require a password. Press Next.

On the Confirmation page, press Create to finish configuring Work Folders.

Post-Install Work

To finish setting up Work Folders there are two additional steps that will need to be done.

· Binding the Work Folders cert to the SSL port

· Configuring Work Folders to use AD FS authentication

· Exporting Work Folders certificate (if using a self-signed certificate)

Binding Cert

Work Folders only communicates over SSL and will need to have the self-signed cert created earlier (or your CA issues certificate) bound to the port.

To bind the certificate to the port by powershell there are two methods. One method is to use the IIS cmdlets and another is to use nethsh

Binding with netsh

To use netsh in powershell you need to pipe the command to netsh .  Below is an example that will find the cert with the subject, “workfolders.contoso.com” and bind it to 443 with  netsh

Binding with IIS cmdlets

A second way that it can be done is with the IIS management cmdlets, which can be used if you installed the web-management tools and scripts.  Note that this does not enable full IIS on the Work Folders machine and only enables the management cmdlets.  There are some possible benefits towards doing this, say if you are looking for cmdlets to provide what you get from netsh..   When the cert gets bound to the port via the New-WebBinding cmdlet, it is bound to the port and the binding is not dependent on IIS in any way.  After doing the binding you can even remove the Web-Mgmt-Console feature and the cert will still be bound to the port, and verifiable via netsh by typing netsh http show sslcert.

Below is an example that works with Work Folders using New-WebBinding that will find the cert with the subject, “workfolders.contoso.com” and bind it to 443

Setup AD FS Authentication

To configure Work Folders to use AD FS for authentication you will need to open Server Manager. Select Servers, select your Server in the main panel and right click on the Server to bring up the context menu. On the context menu select Work Folders Settings.

On the Work Folder Settings window, select Active Directory Federation Services and type in the Federation Service URL and click apply. In our example it is

The cmdlet to accomplish via powershell is:

Set-SyncServerSetting-ADFSUrl"https://blueadfs.contoso.com"

If you are setting up AD FS with self-signed certs, you may receive the below error message about Federation Service URL being incorrect, unreachable or a relying party trust has not been setup.

This error can also happen if the AD FS cert has not been installed on Work Folders or if the CNAME for AD FS was not setup correctly.

Exporting Certificate

The self-signed Work Folders certificate will need to be exported and installed on the following machines in the test environment:

• Web Application Proxy
• Domain joined Windows 8.1 client
• Non-domain joined Windows 8.1 client

To export the certificate:

· 1.  Click Start, and then click Run.
2.  Type MMC.
3.  On the File menu, click  Add/Remove Snap-in.
4.  In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.
5.  Select Computer account, and then click Next.
6.  Select Local computer: (the computer this console is running on), and then click Finish.
7.  Click OK.
8.  Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
9.  Right-click Certificates, click All Tasks, and then click Export...

Go through the Certificate Export Wizard

Export the private key

Use the default options

Enter in a password for the certificate. Remember what password you use as you’ll need to use the pass later when you import the certificate to the other devices.

Enter in a location and name for the certificate and then finish the wizard.

Setting up Web Application Proxy

Pre-Install Work

Install AD FS and Work Folder certificates

Copy the AD FS and Work Folders certificate that were respectively created to when setting up AD FS and Work Folders to the machine to install the Web Application Proxy Role and install the certificates into the local computer certificate store. To do this, follow these steps:

1.  Click Start, and then click Run.
2.  Type MMC.
3.  On the File menu, click  Add/Remove Snap-in.
4.  In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.
5.  Select Computer account, and then click Next.
6.  Select Local computer: (the computer this console is running on), and then click Finish.
7.  Click OK.
8.  Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
9.  Right-click Certificates, click All Tasks, and then click Import.

10.  Expand Console Root\Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates.
11.  Right-click Certificates, click All Tasks, and then click Import.

Install Web Application Proxy

On the Server that you plan to install the Web Application Proxy, open Server Manager and start the Add Roles and Features Wizard.

Click Next on the first page of the wizard

Click Next on the Second page of the wizard

Select you server on the third page of the wizard and click Next

On the Server Roles Page, select the Remote Access Role

On the Role Services page, select Web Application Proxy

A confirmation dialogue will immediately pop-up, press Add Features.

Configure Web Application Proxy

To configure the Web Application Proxy, select the Warning flag at the top of Server Manager which will show a link to open the Web Application Proxy Wizard

On the Welcome screen press Next

On the Federation Server enter the address of the Federation Service name. For our example it is blueadfs.contoso.com.

The wizard also asks for the credentials of local administrator account on the federation service account. Do not enter in domain credentials i.e. contoso\administrator, but local credentials i.e. just administrator

On the AD FS Proxy certificate page, select the AD FS certificate that was imported earlier and press Next.

In our case it is blueadfs.contoso.com

A confirmation page will display showing the powershell command that will execute to configure the service. An option for enabling the Web Application proxy to use OAuth is not available through the Wizard and needs to be done via powershell. The step is shown in the post-configuration section.

If OAuth is not enabled on the Web Application Proxy, your clients connecting to the Web Application Proxy will receive an error stating that the “Data in the stream is not in the proper format (0x80c81000)”

The results page will display once configuration is complete. Close the window.

The next step is to publish the Work Folders Web Application.

On Server Manager, go to Tools, Remote Access to open the Remote Access Management Console.

Select Web Application Proxy under configuration on the left side of the management console and then click Publish under Tasks on the right. The Publish New Web Application Wizard will open.

Publish Work Folders Web Application

On the Welcome page, click Next.

On the Preauthentication page of the Wizard, select Active Directory Federation Services.

On the Relying Party, Select Work Folders and press Next. This list is published to the Web Application proxy from AD FS.

On the Publishing Settings page, enter the following:

• the name you would like for the Web application
• the external URL for Work Folders
• Select the Work Folders certificate
• The back-end URL for Work Folders

By default, the wizard will make the back-end URL the same as the external URL.

For our example we will use the following values:

Name: WorkFolders

External URL: https://workfolders.contoso.com

External certificate: the Work Folders certificate installed earlier

Backend server URL: https://workfolders.contoso.com

The confirmation page will show the equivalent powershell script to do the configuration. Press Publish to finish publishing the Work Folders Web Application.

If the publishing is successful, you’ll see a confirmation page like below.

Post-Install Work

To finish setting up the Web Application Proxy there is one additional step that must be done. The Web Application Proxy must be configured to use OAuth. To do so, open up an admin powershell window on the Web Application Proxy machine and execute the following command.

For our example, use the following command.

As mentioned earlier, failure to do so will cause applications connection through the Web Application Proxy an error that “Data in the stream is not in the proper format (0x80c81000)”.

Setting up Domain Joined Windows 8.1 client

Pre-Install Work

Install AD FS and Work Folder certificates

Copy the AD FS and Work Folders certificate that were respectively created to when setting up AD FS and Work Folders to the machine to install the Web Application Proxy Role and install the certificates into the local computer certificate store. To do this, follow these steps:

1.  Click Start, and then click Run.
2.  Type MMC.
3.  On the File menu, click  Add/Remove Snap-in.
4.  In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.
5.  Select Computer account, and then click Next.
6.  Select Local computer: (the computer this console is running on), and then click Finish.
7.  Click OK.
8.  Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
9.  Right-click Certificates, click All Tasks, and then click Import.

10.  Expand Console Root\Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates.
11.  Right-click Certificates, click All Tasks, and then click Import.

Configuration

Open Control Panel and select Work Folders.

Select Set up Work Folders

Work Folders can then be setup using either the user’s email address (mbutler@contoso.com) or with the Work Folders URL (https://workfolders.contoso.com). Setup up Work Folders by the mechanism of your choice and press Next.

You will then be presented with a credentials prompt from AD FS. When on-prem, the prompt will be done using Windows Integrated Authentication. The challenge screen from off-prem clients will be with OAuth and users will see a different screen.

After you have authenticated, the Introducing Work Folders windows will display. On this page you can change the Work Folders document location. Press Next.

You will then see a window displaying the security policies that we had setup on Work Folders. Press Next.

You will then see a message that Work Folders has started syncing with your PC. Press Close.

The manage Work Folders panel will open showing you the amount space, sync status, etc. On this panel you can re-enter your credentials if needed. Go ahead and close the window.

Your Work Folders folder will also automatically open. From here you can start adding content to sync between your devices. We’ll go ahead and add in a Test file on the domain joined machine and setup Work Folders on our non-domain joined machine.

Setting up non-domain Joined Windows 8.1 client

Pre-Install Work

Install AD FS and Work Folder certificates

Copy the AD FS and Work Folders certificate that were respectively created to when setting up AD FS and Work Folders to the machine to install the Web Application Proxy Role and install the certificates into the local computer certificate store. To do this, follow these steps:

1.  Click Start, and then click Run.
2.  Type MMC.
3.  On the File menu, click  Add/Remove Snap-in.
4.  In the Available snap-ins list, select Certificates, and then click Add. The Certificates Snap-in Wizard starts.
5.  Select Computer account, and then click Next.
6.  Select Local computer: (the computer this console is running on), and then click Finish.
7.  Click OK.
8.  Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
9.  Right-click Certificates, click All Tasks, and then click Import.

10.  Expand Console Root\Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates.
11.  Right-click Certificates, click All Tasks, and then click Import.

Update Hosts file

The hosts file on the non-domain joined client will need to be updated for our demo environment.

The hosts file will need entries put in for:

workfolders..<domain>

<AD FS service name>.<domain>

enterpriseregistration.<domain>

For our example we will put in the following values:

10.0.0.10 workfolders.contoso.com

10.0.0.10 blueadfs.contoso.com

10.0.0.10 enterpriseregistration.contoso.com

Work Folders can then be setup using either the user’s email address (mbutler@contoso.com) or with the Work Folders URL (https://workfolders.contoso.com). Setup up Work Folders by the mechanism of your choice and press Next.

You will then be presented with a credentials prompt from AD FS. The challenge screen for the non-domain client will be using OAuth and be different from what users will see on-prem.

After you have authenticated, the Introducing Work Folders windows will display. On this page you can change the Work Folders document location. Press Next.

You will then see a window displaying the security policies that we had setup on Work Folders. Press Next.

You will then see a message that Work Folders has started syncing with your PC. Press Close.

The manage Work Folders panel will open showing you the amount space, sync status, etc. On this panel you can re-enter your credentials if needed. Go ahead and close the window.

Your Work Folders folder will also automatically open. From here you can start adding content to sync between your devices. What you will also see is that the file from our domain joined PC has already synced to the device.

And that’s it for setting up Work Folders, AD FS and WAP from the UI (mostly ).

Setting up Work Folders, AD FS and WAP via attached scripts.

The attached scripts will enable to you setup and deploy the entire environment is less than 30 minutes. If you already have VMs/machines setup (i.e. domain joined, network setup, etc), then the configuration is less than 12 minutes. The whole process is IO bound so your mileage may vary. A colleague of mine has a very powerful laptop (i7 ivy bridge with 32gb of memory and a SSD) and his setup time is less than 4 ½ minutes.

The scripts were written with the assumption that you are starting from a clean environment and already have a DC setup. The scripts are designed to run from the VM Host machine and use remote powershell to configure all of the machines in the environment, so you do not need to remote into any of the machines to set them up.

There are three main steps/scripts to execute:

· setHostNetworkAdapters.ps1 – this will setup the Virtual Switches on the Host and configure the virtual network adapters as the default gateway for each network

· provisionEnvironment.ps1 – this will create the VMs needed for the environment from the downloaded ISOs and also finish setting up the OS on each machine, which includes setting the VMs network addresses and domain-joining where appropriate using unattended xml files

· setupEnvironment.ps1 – this will setup and configure AD FS, Work Folders, WAP and the two client machines.

Pre-requisites

• Active Directory Forest (preferably with DNS enabled, but not required) running Windows Server 2012R2 populated with users and groups
• ISOs for Windows Server 2012R2 Datacenter
  • http://technet.microsoft.com/en-US/evalcenter/dn205286.aspx
• ISOs for Windows 8.1 Enterprise

o http://technet.microsoft.com/en-US/evalcenter/hh699156

For the scripts, the IP address of the DNS server is set to 192.168.0.150. If your DC has a different IP address you will need to update the scripts accordingly

Configuring Virtual Switches

The script setHostNetworkAdapters.ps1 will create the virtual switches on the Host machine and also set the IP address, subnet and DNS address.

The network adapters should be setup as the gateway address for each of their respective virtual networks. This enables the Host to access the VMs and vice versa. This is essential to run remote powershell scripts from host against the VMs on the network.

The script has a function called setNetworkAdapter that will setup a virtual switch and configure it’s IP addresses, subnet and DNS values.

To call the function you will need to pass in:

· Name of switch to create

· IP address to use as the gateway (the gateway IP should be the first available address in the network, i.e. XXX.XXX.XXX.1)

· The octet for the subnet

· IP address of the DNS server (optional, but should be configured on the VM network where the DC will reside)

The script is currently configured to create switches for Contoso and Fabrikam

After running the scripts, the virtual switches will be created and the network adapters will be configured.

If you already have a DC deployed, then you most likely already have at least one virtual switch and network setup. If that is the case, check to ensure that the IP address on the network adapter that the host is using for the Virtual network is configured as a gateway.

Provisioning the Environment

The script provisionEnvironment.ps1 will:

· Create a base referencing for disks for the Server and Client VMs. The Server base disk will be loaded with Windows Server 2012R2 Datacenter and the Client base disk will be loaded with Windows 8.1 Enterprise.

· Configure the network adapter(s) on each VM

· Domain join – where appropriate

· Enable CredSSP on each VM

You must run this script from a powershell window with Admin privileges or it will not work.

The first time that the script is run, it will take about 8 minutes to create each base differencing disk. On subsequent runs, you can reuse the previously created base VHD with no issue.

After the provisioning is complete you will have a set of differencing disks that look like the below. If you wish to recreate the environment, you can delete the differencing disks based off the base disk and reuse the existing base disk. The base disk is clean and only contains the OS.

The setup and configuration of the VMs is done with an unattended XML file that is loaded onto each VM after

Enabling CredSSP is done by creating and pushing a SetupComlete.cmd file into the directory Windows\Setup\Scripts . When the VM boots, it will execute the setupcomplete.cmd file

Configuring the Script

The script obtains the list of machines to build and the VM information from a csv file called vms.txt.

Here is what the file looks like.

machine,server,DJ,name,memory,network1,ip1,dns1,network2,ip2,dns2

DC,Y,Y,2013R2-DC,1524,ID_AD_NETWORK-FABRIKAM,192.168.0.150/24,127.0.0.1,,,

WAP,Y,N,2012R2-WAP,1524,ID_AD_NETWORK-Contoso,192.168.0.254/24,192.168.0.150,ID_AD_NETWORK-FABRIKAM,10.0.0.10/24,

ADFS,Y,Y,2012R2-ADFS,1524,ID_AD_NETWORK-Contoso,192.168.0.160/24,192.168.0.150,,,

WF,Y,Y,2012R2-WF,1524,ID_AD_NETWORK-Contoso,192.168.0.170/24,192.168.0.150,,,

client1,N,Y,client1,1524,ID_AD_NETWORK-Contoso,192.168.0.120/24,192.168.0.150,,,

client2,N,N,client2,1524,ID_AD_NETWORK-FABRIKAM,10.0.0.20/24,,,,

Here is the definition of the csv structure

Script Variables

In the script there are also variables that are used for:

• Location of the ISO files
• Location to store the base disks
• Location to store the VHDs that will be created
• Domain
• Domain admin name and password
• Local admin name and password for the non-domain joined machines.

Configuring the Environment

The script configureEnvironment.ps1 will:

· Enable CredSSP on all domain joined Servers

· Configure AD FS, Work Folders and WAP

· Configure the two Windows 8.1 clients (one domain joined and one non-domain joined)

You must run this script from a powershell window with Admin privileges or it will not work.

When the script is finished, you will have an environment that looks like the below

Configuring the Script

Servers

The script obtains the list of machines to build the servers from in a csv file called servers.txt.

Here is what the file looks like.

server,name,ip,ip2

WAP,2012R2-WAP.contoso.com,192.168.0.254,10.0.0.10

ADFS,2012R2-ADFS.contoso.com,192.168.0.160

WF,2012R2-WF.contoso.com,192.168.0.170

AD,2013R2-DC.contoso.com,192.168.0.150

Here is the definition of the csv structure

Clients

The script obtains the list of machines to build the clients from in a csv file called clients.txt.

Here is what the file looks like.

client,name,ip

domainjoined,client1,192.168.0.120

nondomainjoined,client2,10.0.0.20

Here is the definition of the csv structure

Script Variables

In the script there are also variables that are used for:

• AD FS Display Name
• AD FS Service Name
• AD FS certificate Subject name
• Work Folders certificate Subject name
• Address to use for enterpriseregistration
• Name of Share to create on Work Folders
• Path of share to create on the Work Folders machine
• Name of Group to add to Work Folders Share
• Relying Party Trust name for Work Folders
• Domain
• Password to use when exporting and importing certs
• User name and passwords for:
  • Web Application Proxy
  • Host Machine
  • Contoso admin
  • Non-domain joined client machine

Setting up AD FS

The setupadfs function will

• Create the CNAME entries (blueadfs.contoso.com and enterpriseregistration.contoso.com) in the DC via remote powershell
• Install AD FS via remote powershell
• Create and install a self-signed SAN certificate for AD FS
• Create the AD FS Managed Service account
• Install the AD FS Farm
• Setup the AD FS Relying Party Trust for Work Folders
• Grant the AD FS Managed Service account permissions to read the certificates private key
• Enable device registration
• Export the created certificate to the host machine

The SAN values for the AD FS certificate are read from the csv file named adfssans.txt. The SAN values for the certificate must contain the AD FS service name and one for enterpriseregistration.

<ADFS Service name>.<domain>

enterpriseregistration.<domain>

The values in the shipped csv are

blueadfs.contoso.com

enterpriseregistration.contoso.com

2012R2-ADFS.contoso.com

Setting up Work Folders

The setupWF function will

• Create the CNAME entry (workfolders.contoso.com) in the DC via remote powershell
• Install the AD FS certificate into the Work Folders VM
• Create and install a self-signed SAN certificate for Work Folders
• Install Work Folders
• Create a Sync Share for the group defined in $WFShareGroup
• Set the Sync Share policies to require encryption and password auto lock
• Enable SMB access on the Sync Share
• Bind the created certificate to port 443
• Setup the Work Folders AD FS URL
• Export the created Work Folders certificate to the host machine

The SAN values for the Work Folders certificate are read from the csv file named wfsans.txt. The SAN values for the W certificate are read from the csv file named adfssans.txt. The SAN values for the certificate must contain the Work Folders: workfolders.<domain>

The values in the shipped csv are

workfolders.contoso.com

2012R2-wf.contoso.com

Setting up Web Application Proxy

The setupWAP function will

• Install the AD FS and Work Folders certificates into the WAP VM
• Install the Web Application Proxy Role configured with AD FS service name and AD FS certificate
• Add a Web Application Proxy for Work Folders using the Work Folders certificate

The values for the Web Application Proxy setting are obtained from the csv file named webapps.txt. The structure of the file looks like this

App,ExternalURL,BackEndServerURL,ADFSRelyingPartyName,subject

WorkFolders,https://workfolders.contoso.com,https://workfolders.contoso.com,WorkFolders,workfolders.contoso.com

Enterprise Registration,https://enterpriseregistration.contoso.com/EnrollmentServer/,https://enterpriseregistration.contoso.com/EnrollmentServer/,pass-through,blueadfs.contoso.com

Here is the definition of the csv structure

Setting up Clients

The setupWorkstation function will

· install the AD FS and Work Folders certificates into the workstation VM

· Disable check for server certificate revocation. This only needed to be done for Work Place join when using self-signed certificates

If the workstation is not domain joined, the function will also update the hosts file on workstation for:

workfolders.<domain>

<ADFS service>.<domain>

Enterpriseregistration.<domain>

And have them point to the IP address of the WAP server.

For our example it will put in the following values:

10.0.0.10 workfolders.contoso.com

10.0.0.10 blueadfs.contoso.com

10.0.0.10 enterpriseregistration.contoso.com

Conclusion

I hope this blog post helps you to get started with AD FS, Work Folders and Web Application Proxy in your test labs and gets you a step closer to a production deployment.