Citrix ShareFile

How to setup Citrix ShareFile with Microsoft AD FS 3.0 for Integrated Windows Authentication



Setting up Citrix ShareFile with AD FS 3.0 (Active Directory Federation Services) is probably one of the most common deployments for single sign-on (SSO) in an Enterprise environment. To my knowledge it is the only solution that currently supports Integrated Windows Authentication (IWA) where whatever credentials the user is logged into their PC with get passed to ShareFile and automatically logs them in. No login prompts, a super smooth single sign-on experience for both the ShareFile website as well as the numerous plugins like the ShareFile Outlook Plugin and ShareFile Sync for Windows client. I spoke about using a NetScaler as a SAML IdP provider a few months back here:

and there are some pros and cons I touched on when using it. For most production environments, I recommend using AD FS if you can. Now let me go over how AD FS 3.0 works with ShareFile.

AD FS (also spelled ADFS by many), stands for Active Directory Federation Services. It started out as a download you would have to install on Windows Server 2003 R2 and later became a full blown server role. AD FS allows an organization to extend it’s enterprise beyond it’s own network. Over the years it has become a core service in many enterprises to provide SaaS and cloud services to the organization. It allows you to use single sign-on to apps both inside and outside the company. So an Active Directory user id “federated” with another external party providing a single identity to the user that can access anything they are permitted to access.

The current version is AD FS 3.0 which ships with Server 2012 R2. Now in the year 2016, it’s such a fundamental services for Enterprises to allow an easy seamless single sign-on user experience to external services like Office 365, SharePoint Online,, and of course ShareFile. Internet and cloud based software services are growing at an exponential rate. Your business apps are not just about authentication within the datacenter anymore.

AD FS is a claims-based authentication method so that means there is a token being passed between your organization and the external organization’s service, in this case the ShareFile control plane in the Amazon Web Services (AWS) cloud. In a nutshell you build a trust between Active Directory and the external service via AD FS. AD FS acts as a intermediary. When an authentication request is made to ShareFile it talks to AD FS, verifies you, then passes a token back up to ShareFile which logs you in. Simple right?

As I said AD FS is a server role, so let’s start there:

1. On your Windows Server 2012 R2 box, go to Server Manager and install the role and just hit Next all the way through:


2. Once done click the little flag in Server Manager and click “Configure the federation service on this server.”:


3. Since it’s the first server in the federation server farm go ahead and hit Next:


4. Provide domain administrator account credentials:


5. Create Federation Service name and display name. You will need an SSL cert. In this example I’ll use


6. Give it a service account:


7. Now create a database, you can use SQL if you trust it. But if you don’t want to rely on an external point of failure and believe your sizing falls in line with local, go for a local Windows Internal Database. Hit Next to Review and finish the install.


8. Now the actual config. Open up the AD FS console and click on Authentication Policies. You’ll want to select Forms Authentication for Extranet and Window Authentication for Intranet:


9. Now go to Trust Relationships and click “Add Relying Party Trust” on the right hand size. In this example we’ll use as your ShareFile domain. We need to create the trust relationship with this domain:


10. Select the manual option and hit Next:


11. Now you can type in and notes if you like:


12. Leave the default AD FS profile


13. Ignore the cert, just hit Next.


14. Now type in your ACS URL. This is the Assertion Consumer Service that is the same no matter what kind of SSO authentication you are trying to setup with ShareFile. It’s basically what you’re going to talk to in AWS. You get this from the SSO section within the ShareFile console but it’s pretty much the same for everyone:


15. Now add your ShareFile domain as an identifier:


16. We don’t care about MFA so hit Next:


17. Permit all users to access the relying party:


18. Hit Next to add the Trust:


19. It should open up the Edit Claim Rules once you are done. Hit Add Rule:


20. Hit Next, we’re going to send LDAP attributes as Claims:


21. Call the Claim rule name anything you like, in this example “E-mail Address” since that’s what users are going to log into ShareFile with. Select Active Directory as the attribute store. Then choose “E-Mail Addresses” in the first column and “E-Mail Address” in the second column:


22. Now add another rule:


23. Select Transform an Incoming Claim:


24. Call the rule anything you like, in this example “E-mail address to Name ID”. For the incoming claim choose E-mail Address, outgoing claim as Name ID, and the outgoing name ID format as Email. This is what maps the email address to the Name ID:


25. Now double click the relaying part trust you just created ( to edit it’s properties. Click on the Endpoints tab and hit “Add SAML”


26. You’re adding a logout link for users are properly logged out of ShareFile when they are done. Choose SAML Logout, binding should be POST, and the Trusted URL should be the adfs signout link so:


27. Now go to Certificates in the AD FS console under Service. Under Token-signing, double click your cert and hit Copy to File:


28. Choose Base-64 for the export. Give it a file name and export the .cert to your local hard drive.


29. Open up the .cer in Notepad and copy and hit Ctrl+A > Ctrl+C and paste that into the ShareFile control plane. Log into ShareFile with admin credentials and go to Admin, then “Configure Single Sign-On”. You’ll want to paste it exactly as is into the X.509 Certificate section. The other settings you will need are below:

Basic Settings

  • Check the box to allow SAML.
  • ShareFile Issuer, enter in
  • Your IDP Issuer, enter in again
  • X.509 Certificate, once you paste it it should say Saved
  • Login URL, this will be
  • Logout URL, this will be

Optional Settings

  • Require SSO Login so all users will need to use AD FS to login (except admins)
  • Set the SP-Initiated SSO certificate to HTTP Redirect with no signature, but you can specify a cert here if needed
  • You can choose to check or uncheck the Enable Web Authentication. Since the purpose of this article is to use Integrated Windows Authentication, I left this unchecked.
  • Set SP-Initiated Auth Context to Unspecified and Minimum. This will make sure both Integrated Windows Authentication and any others you decide to use in the future will all work.



Now if you have already set the split logon page as I showed you here:


then go ahead and try your Employee login on the left side. You should see your web browser for a split second hit the page as NTLM passthrough kicks in and then immediately log you in. Bam you’re in! With Internet Explorer make sure you set a GPO to add the AD FS url to your Trusted Sites if it doesn’t work for you. Now logout and verify it successfully logs you out.

If you’re using Firefox or Chrome, NTLM passthrough is disabled by default. There are tricks with either to add it. Like using about:config for Firefox and setting network.negotiate-auth.trusted-uris and network.automatic-ntlm-auth.trusted-uris. It’s easier to control Integrated Windows Authentication at the AD FS server level. Plus the added benefit is Integrated Windows Authentication will work with all other SaaS services you might use AD FS for such as Office 365, SalesForce, etc.

With older versions of AD FS there were some IIS tricks you can do. Since IIS is no longer used for AD FS it’s all up to PowerShell to achieve the same affect. On your AD FS server:

1. Open up a an administrative PowerShell prompt (by right clicking the PowerShell icon and hitting Run as Administrator):


2. Type in:



3. Then type in:


you should see a setting called:

ExtendedProtectionTokenCheck : Allow

You’ll also notice the “WIA” Windows Integrated Authentication Supported User Agents is looking pretty slim:


4. We need to change Extended Protection Authentication (EPA) to none. You do that by typing in this:

Set-ADFSProperties –ExtendedProtectionTokenCheck None

5. Then you have to add your browser user agents. Let’s do them all:

6. Now restart the “Active Directory Federation Services” Windows service and try your browser of choice. It should pass you right through.

I’ve showed you how to setup AD FS 3.0 from scratch and how to integrate it with ShareFile. Other services besides ShareFile you might integrate in the future all work pretty much the exact same way. I hope this guide helps you out, please leave a comment below if you have any questions. 🙂

About Jason Samuel

Jason Samuel lives in Houston, TX with a primary focus on strategic advisory and architecture of end-user computing, security, enterprise mobility, virtualization, and cloud technologies from Citrix, Microsoft, & VMware. He also has an extensive background in web architecture and networking over his 20+ year career in IT. He is an Author, Speaker, and Local User Group Community Leader. He is certified in several technologies and is 1 of 63 people globally that is a recipient of the prestigious Citrix Technology Professional (CTP) award. He is 1 of 42 people in the world that has been awarded as a VMware EUC Champion and VMware vExpert. He is a featured author on DABCC which provides the latest IT Community News on Cloud, Data Center, Desktop, Mobility, Security, Storage, & Virtualization. In his spare time Jason enjoys writing how-to articles and evangelizing the technologies he works with. Disclaimer: The content and opinions expressed in articles and posts are his own and are by no means associated with his employer.

Recommended for you


  1. Kent Soderlund

    December 25, 2016 at 5:29 AM

    GREAT article! Thanks! Will try this during the weekends
    One question – this setup requries a port opening from Internet to your adsf server? Or can you use Netscaler to protect that?


  2. Paulius Mantulovas

    February 27, 2017 at 1:09 PM

    Hi, really impressive article with extremely good explanations on each step. Your shared knowledge was good inspiration for our implementation, however we have one question.
    We have configured ADFS as IDP for ShareFile everything works perfectly on workstation, however we identified problem for mobile MDX client – we are not using XenMobile as IDP obviously and looks like that causes problem.
    ShareFile mobile MDX client cannot automatically identify controlpane (subdomain) for some reason. User needs to click Add account and type in subdomain, when it’s done SAML SSO works fine.
    This problem persists only if we are using AD FS as IDP, if we are using XenMobile as IDP ShareFile mobile client identifies our subdomain automatically.
    Question is how to provide subdomain configuration to ShareFile MDX app if we want to use ADFS instead of XenMobile as IDP? For some odd reason ShareFile MDX policies not allows to set subdomain from XenMobile.

  3. Broom

    March 9, 2017 at 11:51 AM

    Very good article. If anyone is looking to take this one step further take a look at:

  4. Michael

    June 21, 2017 at 12:37 PM

    Thank you for providing such wonderful article. We are in the process helping our customer doing POC. What is the best way to implement multi-domain login? That’s say each country has their own Active Directory. How can I let them login sharefile in HQ by using their own domain account? I am not quite sure if we want to reach real SSO for Domain joined computer. Do I have to use ADFS only? Can I use NetScaler as a SAML?

Leave a Reply

Your email address will not be published. Required fields are marked *