C:\inetpub\wwwroot\Citrix\StorageCenter\cifs\AppSettingsRelease.config

Add the following line the config:

<add key="disable-folder-permission-verification" value="1" />

Once added, recycle the StorageCenterAppPool in IIS as below: I have it on strong authority this will be resolved in a future build, but no promises. A big thank you to Dan Brinkmann, George Christophi and Citrix Support for this fix.

Trying to find which Domain’s and URL’s were being used and called in order to categorise them was a royal pain in the ass inside of a secure virtual desktop, so here’s the list below if you’re facing the same task:

1. <yourdomain>.sharefile.com (or .eu)
2. yourinternalstoragezonename*
3. g.sf.api.com
4. secure.sf-api.com (and/or .eu)
5. <yourdomain>.sf-api.com (and/or.eu)

if you want a sweeping statement, just whitelist sf-api.com and sf-api.eu.

Note, if you want full compatibility with all IE versions, also stick the domains in trusted sites.

* The external DNS name of your storage zone controller

The end result of this activity will allow you to login to sharefile using a native account (think Guest) or an active directory account (think internal user).

What you will need in order to follow this guide:

• An enterprise Sharefile account.
• A local domain.
• An active directory service account. (standard user rights are fine)
• A windows 2012 server to host ADFS (windows 2008 r2 is fine, but you’ll need to install ADFS 2.0 manually).
• This windows server must be accessible via https (443) from the internet. (Netscaler SSL works fine).
• An external trusted certificate for the web server hosting saml (e.g. adfs.yourdomain.com). For this walk through, I’ll assume you have already done this. *
• A copy of the Sharefile User Management Tool.
• About 2-3 hours spare.

* for this, generate a server certificate and import it into the local machines personal certificates.

Steps:

• Installing Active Directory Federated Services.
• Configuring Federated Services.
• Configuring Sharefile for SAML.
• Syncing Active Directory users with Sharefile.
• Testing the saml login.
• COnfiguring the Split Login Page
• Configuring AD FS for google chrome authentication

This blog post is crazy long, 50 pages+. For a pdf, go here.

Credits:

• Juliano from Citrix for this lovely, but a bit lacking blog post: http://blogs.citrix.com/2012/03/19/saml-authentication-with-sharefile-using-ad-fs-2-0/
• The Superstars on the sharefile support team.

Installing Active Directory Federated Services:

Log into your server 2012 machine and fire up server manager. From server manager choose add role:

Choose Role Based or feature based installation, then choose next.

Select the local server and choose next:

Select Active Directory Federation Services:

Accept the Pre Requisits by pressing Add Features, then click next.

On the Features page, don’t select anything additional, just select next:

For ShareFIle, we only require the Federation service, choose this and select next:

On the Web Server role Services page, select the defaults and choose next:

Click to Install:

Assuming all goes to plan, the install should finish correctly. Click Close.

Now head over to the start menu, and open up AD FS Management:

Configuring Active Directory Federated Services:

On the landing page, select the Configuration Wizard:

Choose Create a new Federation Service:

Select New federation server farm:

If you are using a wildcard certificate like me, you’ll need to specify the hostname below. This hostname is the internet facing name of this SAML service:

Specify an active directory service account. A standard user, password never expires is fine. The installer will set the SPN for you.

Review the summary (ya right, click next so fast your mouse flies across the room).

Assuming all goes to plan, your screen should be all green and wonderful, click close.

Creating ShareFile SAML trust:

Now that we’re up and running, under ADFS > Trust Relationships, right click Add Relying Party Trust..

Skip the welcome screen, choose Start

Choose enter data about the relying party manually:

Add a Display name and optionally a description, then choose Next.

Choose an AD FS Profile, then Next.

Ignore the certificate tab, click Next

Click Enable support for the SAML 2.0 WebSSO protocol and enter the url to your sharefile instance with /saml/acs appended to the end. e.g. https://yourcompany.sharefile.com/saml/acs

You can also verify this url by going to your sharefile instance > admin > configure single sign on:

extra points if you spot this idiots spelling mistake below.

Add the trust identifier you wish, I would recommend a the lowercase string the same as the sharefile instance name. Make note of what you enter here for later.

Select Permit all users to access this relying party, then choose Next.

On the Ready to Add Trust page, click Next:

On the Finish page, select Open the Edit Claim Rules dialog for this relying party when the wizard closes, then click finish.

On the Issuance transform Rules, first we need to tell ADFS what kind of incoming credentials to expect. Click Add Rule.

Select Send LDAP Attributes as Claims, select next.

• Add a descriptive name, e.g. AD to SAML Email.
• Select Active Directory as the attribute store.
• Select Email Addresses as the Attribute
• Select E-Mail Address as the outgoing claim type.
• Click finish to add this rule.

Now we add an additional rule to transform the claim. Click Add again.

Select Transform an Incoming Claim as the claim rule template then click next.

• Configure a descriptive name, e.g. Email to NameID.
• Select E-Mail Address as the Incoming claim type.
• Select Name ID as the Outgoing claim type.
• Select Email as the Outgoing name ID format.
• Click Finish.

Click Finish, we’re done with the rules.

Now right click on your newly created relying party and choose properties.

On The advanced tab, configure the secure hash algorithm to SHA-1.

Click Apply and Ok.

In the ADFS MMC, browse to AD FS > Services > Certficates. Right Click the Token Signing Certificate and choose View Certificate.

On the Details Tab of the certificate, click Copy to File

Select Base-64 encoded X.509 (.CER) and click Next.

Browse to save the certificate to the desktop and name it output.cer

Once Saved, make your way back to your desktop, right click the file and choose Open with…

Select Notepad.

select the contents of the file and copy it to the clipboard:

Configuring Sharefile for SAML integration:

Log into your sharefile instance as an administrator. Choose the Admin Tab, then click Configure Single Sign On.

On the single sign on tab, configure your details as below:

• Use the saved string we mentioned earlier for both Sharefile issuer / Entity ID and Your IDP Issuer / Entity ID.
• configure the login url and log off url as the url to your adfs server as follows:
• Login: https://adfs.yourdomain.com/adfs/ls/
• Log off: https://adfs.yourdomain.com/adfs/ls/?wa=wsignout1.0

Paste the certificate details taken from the ADFS server into the following dialog (clearing its contents first) then click save.

Save again and we should be good to go.

Configuring the User Sync Tool to sync your active directory users:

Grab a copy of the Sharefile User Management tool from the citrix website (current version as of this document is 1.5.10.0)

Run the installer and choose the default options:

On the desktop, launch the ShareFile User Management Tool:

On the login page, enter your sharefile login details:

Note, if it bugs out, just close and open it again.

Enter your domain details, then click connect.

Select the users tab, then browse active directory to find a user you wish to test with. Select the OU containing the user, then click Add Rule

Configure any advanced features your may require on the rule, then click close.

Once created, head over to the rules tab. Highlight the rule you have created and press Commit Now.

You should receive notification this has been complete:

Once this is done, your new user should appear in ShareFile:

Testing ShareFile SAML authentication.

In a browser, head to https://yourdomain.sharefile.eu/saml/login

enter your credentials, e.g. domainusername

Assuming all has gone to plan, you should now be welcomed to sharefile:

If you click log off, you should now also be greeted by your saml service:

Enabling the Split Login page:

<borat> Great success </borat> But how do we enable the fancy split login page I showed you earlier?

email support@sharefile.com and they lovely ladies and gentlemen will walk you through the process. at most it’ll take 10 mins between emails.

Optional: Configuring SAML to work with Google chrome:

By default saml won’t work with chrome. Here’s how to fix it.

open the start menu and open IIS (or start > run > inetmgr).

In IIS manager, browse down to the login site (sites > default website > adfs > ls). Double Click Authentication:

Right Click Windows Authentication, Choose Advanced Settings.

Under Extended Protection, Select Off.

FAQ:

1: When logging into SAML and logging off again, if I don’t close the browser, the user can log in again without credentials.

A: Yep! ask support@sharefile.com about that chestnut.

2: when logging into sharefile for tablet / phone, how should I authenticate?

A: user@domainname and password. Other combinations wouldn’t work for me anyway.

3: How can I tell the difference between a normal user, and a SAML user?

A: browse the user as an administrator, if the user is NOT a saml user, you will get an option to email the password:

Consequently, I’ve not tried reseting the password on a saml user. I wouldn’t imagine it will end well, so don’t do it