Published
Apr 10 2019 03:49 AM
2,375
Views
First published on TECHNET on Jul 07, 2014
Michael has posted a blog post 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:
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 post , 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>"
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:
Workplace join is a new feature introduced in Windows Server 2012 R2. The details about the feature can be find here: http://technet.microsoft.com/en-us/library/dn280945.aspx .
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.
Workplace join was introduced to Windows 8.1, and just released for Windows 7. You can find more here: http://technet.microsoft.com/en-us/library/dn609827.aspx
As a background process (sync), user just expects it works. With ADFS, domain joined devices can take advantage of the ADFS support of the Windows authentication. For details about the ADFS user agent see here: http://technet.microsoft.com/en-us/library/dn280949.aspx
With Work Folders, you can add the Work Folders as the supported user agent by running the following cmdlet on the ADFS server:
Set-AdfsProperties -WIASupportedUserAgents ((Get-AdfsProperties).WIASupportedUserAgents + 'MS_WorkFoldersClient')
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.
You can find the KB on Windows 8.1 client here: http://support.microsoft.com/kb/2976918
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 blog 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.
Michael has posted a blog post 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.
Overview
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 post , 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)
Workplace join
Workplace join is a new feature introduced in Windows Server 2012 R2. The details about the feature can be find here: http://technet.microsoft.com/en-us/library/dn280945.aspx .
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.
Workplace join was introduced to Windows 8.1, and just released for Windows 7. You can find more here: http://technet.microsoft.com/en-us/library/dn609827.aspx
Suppress credential prompt for domain joined client
As a background process (sync), user just expects it works. With ADFS, domain joined devices can take advantage of the ADFS support of the Windows authentication. For details about the ADFS user agent see here: http://technet.microsoft.com/en-us/library/dn280949.aspx
With Work Folders, you can add the Work Folders as the supported user agent by running the following cmdlet on the ADFS server:
Set-AdfsProperties -WIASupportedUserAgents ((Get-AdfsProperties).WIASupportedUserAgents + 'MS_WorkFoldersClient')
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.
You can find the KB on Windows 8.1 client here: http://support.microsoft.com/kb/2976918
Conclusion
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 blog 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.