One of the most common questions we receive from Enterprise customers adopting ShareFile is: how to enable single sign-on with ShareFile using Active Directory credentials. Not surprising: single sign-on is not only a huge boost to user experience, but also enhance IT governance.

Your first option should be CloudGateway. CloudGateway uses SAML for single sign-on, handles account provisioning, provide admin workflows, integrates with Citrix Receiver, and more. We’ve just released a connector for Sharefile that makes this configuration super-easy.

If you can’t use CloudGateway, another option is Active Directory Federation Services 2.0 (AD FS 2.0). ADFS 2.0 is a downloadable component for Windows 2008 and 2008 R2. It is quite simple to deploy, but there are several configuration steps that need specific strings, Certificates, URLs, etc. Getting everything right can be tricky.

I figured a step-by-step guide could save people a lot of time! So here you go: How to configure AD FS 2.0 for SSO with Sharefile.com.

You may skip to Step 4 if you already have AD FS 2.0 deployed.

Step 1: Federation Service Certificate

Each AD FS deployment is identified by a DNS name – I will use adfs.mydomain.com just as an example for the rest of this blog. You will need a Certificate issued to this Subject Name before you begin. This identifier is an externally visible name, so make sure you pick something suitable to represent your company to partners. Also, don’t use this name as a server host name as well – it will cause trouble with Service Princiapal Names (SPN) registration if you do.

There are many methods to generate certificates. The easiest, if you have a Certificate Authority in your Domain, is to use the IIS 7 management console:

  • Open Web Server (IIS) management snap-in
  • Select the server node in the navigation tree, then Server Certificates option
  • Select Create Domain Certificate
  • Enter your Federation Service Name in Common Name: adfs.mydomain.com in my example.
  • Select you Active Directory Certificate Authority
  • Enter a Friendly Name for the Certificate (any identifier will do).

If you didn’t use the IIS console to generate the cert, make sure the certificate is bound to the IIS service in the servers where you’ll be installing AD FS before proceeding.

Step 2: Create a Domain User Account

AD FS servers require a domain user account to run its services. Create a Domain User, no specific groups are required.

Step 3: Install First AD FS Server

  • Download ADFS 2.0 and run the installer. Make sure you run the installer as a Domain Admin – it will create SPNs and other containers in AD.
  • In Server Role, select “Federation Server”
  • Check “Start the AD FS 2.0 Management snap-in when this wizard closes” at the end of the Wizard.In AD FS Management snap-in
  • Click Create new Federation Service
  • Select New Federation Server farm
  • Select the Certificate you’ve created in the previous step
  • Select the Domain user you’ve created in previous steps

Step 4: Configure Relying Party

In this step you will tell AD FS the kind of SAML tokens that Sharefile.com accepts. For the example, assume I have a sharefile account named mydomain.sharefile.com. In AD FS Management snap-in:

  • Select Relying Party Trusts in the navigation tree
  • In Select Data Source, use “Enter data about the relying party manually”
  • Enter a Display name identifier. I’ve used my Sharefile domain name: mydomain.sharefile.com.
  • Select AD FS 2.0 profile
  • Do not select an encryption certificate
  • Check ”Enable support for the SAML 2.0 WebSSO protocol”
  • Enter address to sharefile.com SAML authentication URL. In the example: https://mydomain.sharefile.com/saml/acs
  • In Configure Identifiers, enter the relying party identifier. Take note of the string you’ve entered here: you’ll have to match the same string at Step 5. I’ve used mydomain.sharefile.com
  • Select Permit all users to access the relying party
  • Check Open the Edit Claim Rules dialog… option (default)

The Claims Rules define the content of the SAML token generated by AD FS and submitted to sharefile.com. Sharefile.com requires a Name ID in Email format. We will use Active Directory UserPrincipalName as the attribute source, and convert into the Name ID/Email attribute. You may also use AD Email attribute, if UPN doesn’t match your company Email address.

In the Edit Claims Rules:

  • Select Add Rule…
  • In the new Wizard, choose Send LDAP Attributes as Claims
  • Enter Claims rule name. I’ve used “AD to SAML Email”
  • Select “Active Directory” in Attribute store combobox
  • Select “E-Mail-Addresses” in LDAP Attribute combobox
  • Select “E-Mail Address” in Outgoing Claim combobox
  • Select Add Rule… once again
  • Choose “Transform an Incoming Claim”
  • Claims rule name. I’ve used “Email to NameID”
  • Select “E-Mail Address” in the “Incoming claim type” combobox
  • Select “Name ID” in the “Outgoing claim type” combobox
  • Select “Email” in the “Outgoing name ID” format combobox
  • OK all dialogs to close the wizard.

Note: I’ve edited the steps above to use Email address instead of UPN – UPN only works if your AD DN matches your email address. Many AD setups use different values for Email and UPN, and therefore UPN should not be used.  The goal of the rules above is to get whatever AD property that matches the Email address of the users; and output as a NameID claim to sharefile.com. ADFS is very flexible, you have plenty of options to accomplish this if the above doesn’t work.  The only requirement, as far as ShareFile is concerned, is to receive the employee Email address as NameID for the claim.

You should see the new relying party entry under “Relying Party Trusts”. Last step is to change signature format to SHA-1

  • Right-click on your relying party (e.g., mydomain.sharefile.com), and select Properties.
  • In Advanced, select SHA-1

Step 5: Configure Trust at Sharefile.com

The last configuration step is to tell sharefile.com to accept the SAML tokens generated by your new AD FS service.

  • Go to ADFS Management Console, and in the tree, select “Certificates”.
  • Right-click over the “Token-signing” certificate, then View Certificate.
  • Select the “Details” tab, then Copy to File…
  • In the Certificate Export Wizard, select Base-64 Encoded X.509 (.CER)
  • Select any name, proceed with the export.
  • Open the generated file using Notepad. Select All and Copy to clipboard
  • Go to the Administration console at Sharefile.com Main App (http://mydomain.sharefile.com)
  • Select Admin
  • Select Configure Singe Sign-on
  • Check Enable SAML
  • Use the relying party identifier in “ShareFile Issuer/Entity ID” – must match with the Identifier you’ve chosen in Step 4. In the example: mydomain.sharefile.com
  • Enter https://adfs.mydomain.com/adfs/ls/ as Login URL. This is the address Web Clients will be redirected when accessing SAML login page.
  • Select “Change” in the Certificate line
  • Paste the Base64 certificate in the field.
  • If you want to enable Kerberos authentication to your AD FS server, change the selection in “SP-Initiated Auth Context” to “Minimum”. This specify what kind of authentication sharefile.com accepts.
  • Select “Save”, then “Save Settings”.

Step 6: Testing Single-Server Configuration

At this point you should be able to test the configuration. You must create a DNS entry for the ADFS service identity, pointing to the ADFS  server you’ve just configured, or a network load balancer if you’re using one.

To test Identity Provider-Initiated Sign-on, point your browser to https://adfs.mydomain.com/adfs/ls/IdpInitiatedSignOn.aspx. You should see the relying party identifier in a combobox under “Sign in to one to the following sites:”. To test Relying Party-Initiated Sign-on, point your browser tohttps://mydomain.sharefile.com/saml/login. You should be redirected to the ADFS server, landing in a login window; or login silently to Sharefile if Windows Integrated Auth is used.

That’s it! Lots of steps, but not difficult. AD FS configuration guides have loads of additional info on production setups – using proxies on the DMZ, and multiple AD FS servers for High-Availability. These are not difficult either, but depend on your network topology.