First published on TECHNET on Jul 07, 2014
Michael has posted a blog
on how to build a topology with Work Folders and ADFS, it provides really good step by step guide, as well as the scripts. I want to build on that, to show you some insight of Work Folders using ADFS authentication.
Work Folders supports 2 different authentications:
Windows integrated authentication
ADFS using OAuth 2.0 (ADFS using Windows Server 2012 R2)
When the Work Folders server is configured to use Windows integrated authentication, the client will use Kerberos when the device is logged on with the user domain credentials and connected on the corpnet, if the machine is connected over the internet, or logged on using a local account, Work Folders will prompt for user credentials using Digest.
When the Work Folders server is configured using ADFS, the admin needs to provide the ADFS Url (which is the Url for the federation service name). Admin needs to configure the Work Folders relying party on the ADFS server first, this is covered in this blog
, and I’ll skip the details here.
Work Folders admin can configure the authentication method in the server setting page, or running the following cmdlet:
Set-SyncServerSetting -ADFSUrl "<Url for federation service>"
ADFS authentication workflow
When the Work Folders server is configured using ADFS, the client needs to authenticate with the ADFS server, and obtain a token which will then be provided to the Work Folders server to get access. The diagram below shows the sequence:
Client request sync
Work Folders server asks for ADFS access token, also pass back ADFS Url
Client request access token from ADFS server
Based on the policy, ADFS prompts user for auth page
Client sends credentials
ADFS server gives back access token
Client request sync using the access token
Work Folders server will impersonate the user using the token (just like other auth)
The benefit of using ADFS authentication in Work Folders is to allow administrators take advantage to enforce device registration before accessing corporate resources, and/or using multi-factor authentication for the access. These benefits are supported by Workplace join on the client and Server 2012 R2 ADFS. To do so, the ADFS admin configures the Work Folders relying party, and specify if the device is required to be registered (Workplace joined) to access that resource.
In addition to the benefit, the Work Folders client authentication frequency is also different when the device is Workplace joined. The access token (acquired in step #6 illustrated in the above Workflow) has a lifetime of 8 hours. When the access token is expired, the user will be prompt for authentication, and sync stops. If the device is Workplace joined, when the ADFS server gives the access token, it will also send a refresh token. The lifetime of refresh token is configurable, and has a default value of 7 days. With a valid refresh token, user doesn’t need to be prompt for credentials, Work Folders client will take the refresh token and authenticate with the ADFS server to get the access token. When the refresh token expires, user will then be prompted, and authentication workflow cycles again.
This cmdlet adds the “MS_WorkFoldersClient” to a list which ADFS recognizes, and will allow the application (in this case it is the Work Folders) to use Windows Integrated auth to authenticate using the logged on user credentials. In short, if the user is logged on the device using the domain credentials, and the device is connected to the corpnet, sync will not require user to enter credentials.
I hope this blog post helps you to understand how ADFS authentication is supported by Work Folders. The supported ADFS server release by Work Folders is Windows Server 2012 R2. Want to try it out? You will find this setup guide
post come handy. As always, if you have questions not covered here, please raise it in the comments so that I can address it with upcoming postings.