Work Folders Part 1: Overview and Requirements

Overview und Benefits

Work Folders – one of the most exciting new feature in Windows Server 2012 R2 that creates a lot of new possibilities for Bring Your Own Devices (BYOD) to provide controlled access to data stored on the corporate network. It provides the following benefits:

  • Users can access only their own Work Folders from their personal computers (or various devices) anywhere from centrally managed file servers on the corporate network
  • Enables users to access work files while offline and sync with the central file server (devices also keep a local copy of the users’ subfolders in a sync share, which is a user work folder)
  • Work Folders can co-exist with existing deployments of Folder Redirection, Offline Files, and home folders
  • Security policies can be configured to instruct PCs and devices to encrypt Work Folders and use a lock screen Password
  • Failover Clustering issupported to provide a high availability solution
  • Work Folders can be published to the Internet using the Web Application Proxy functionality (also new to Server 2012 R2), enabling users to synchronize their data whenever they have an Internet connection, without the need of a VPN or Remote Desktop

Requirements

Work Folders Server – a server running Windows Server 2012 R2 for hosting sync shares with user files:

  • Install the File and Storage Services role
  • Work folders is managed through Server Manager for a centralizing view of sync activity
  • Multiple sync shares can be created on a single Work Folders Server
  • You can grant sync access to groups (by default, administrators don’t have access to files on the sync share)
  • Possibility to define a device policies per sync share
Work Folders in Server Manager

 

User devices – best functionality is given with Windows 10, Windows RT 8.1, or Windows 8.1 operating systems; Windows 7, iPad, and iPhone clients are also supported

  • Files remain in sync across all user devices
  • Users work with their Work Folders like with any other folder. The only difference is that when right-click the Work Folders icon, they got the option to force synchronization with the server, and then to other devices
  • Users can access and use Work Folders from different devices, irrespective of their domain Membership

Written by B. Rajic.

Active Directory Federation Services 3.x Technology Basics

Active Directory Federation Services (AD FS) provides Web single-sign-on to authenticate a user to related external hosted Web applications. AD FS performs this by securely sharing digital identity and entitlement rights or claims across security and enterprise boundaries.

AD FS supports distributed authentication and authorization over the Internet to provide access to resources that are offered by trusted partners.

Another aspect of ADFS technology can be found in providing external access from Internet connections to internal resources. In that case the ADFS server can provide an additional layer of security by offering various pre-authentication methods, while the second part of the ADFS technology, the Web Application Proxy server (WAP) acts as a Reverse Proxy by terminating the incoming SSL connections.

In version 3.0 of the ADFS technology, the WAP server cannot be run without ADFS server in the backend, which stores the configuration of the WAP servers. The WAP servers themselves are “stateless” and therefore easy to scale up behind a Layer 4 Load Balancer.

ADFS Server Farms

The Active Directory Federation Services technology can be scaled out by deploying multiple ADFS servers in a farm model. The servers share the same configuration information which is stored in a database on each server (Windows Internal Database (WID) model) or in a central SQL store. In most of the implementations, the WID model is used.
For using the WID model, the configuration can only be modified on the Primary ADFS server and is then replicated to all other ADFS servers of the same farm.
To find the Primary Server use the command “get-adfssyncproperties” on one of the ADFS servers:

Web Application Proxy server

The Web Application Proxy Server is typically the Internet facing component of the Active Directory Federation Services technology. Located in the DMZ, the Web Application Proxy (WAP) servers act as reverse proxy server and terminate the incoming SSL connects from the Internet to the published applications.
Web Application Proxy servers are N to 1 connected to a specific ADFS server (farm). Multiple WAP servers can be easily configured for Layer 4 Loadbalancing.
Since WAP servers are “stateless”, they do not store any persistent configuration information, but load the information from the Primary ADFS server. Therefore a WAP server cannot exist without underlying ADFS server and needs to be installed after the ADFS farm has been deployed.

When acting as reverse proxy for client access using IWA (Integrated Windows Authentication) or when serving non claims aware application access based on Kerberos, the WAP servers must be able to perform Kerberos Constrained Delegation. The WAP server presents a Kerberos token on behalf of the accessing client or user, which in consequence requires the WAP server to be a member of an Active Directory domain. Unfortunately the domain membership of the WAP server means to open a lot more ports from the DMZ to the internal network, which is a disadvantage from network security perspective.

For that reason, applications that do not require Kerberos Constrained Delegation should always be published on non domain based WAP servers, where the exception is to publish applications on domain based WAP servers.

Example for ADFS Farm structure: