ADFS

Cookies – IE – ADFS – MSIS7001

Recently we had some strange issues with an ADFS login. Everything worked, but it didn’t. On some sites we got the following error:

“MSIS7001: The passive protocol context was not found or not valid. If the context was stored in cookies, the cookies that were presented by the client were not valid. Ensure that the client browser is configured to accept cookies from this website and retry this request”

One of my colleagues pointed out that all sites with the error contained the underscore (“_”) character, so we started digging into this and found out indeed IE has some issues with the underscore chars in the URL. More accurately the way IE is designed, makes it incapable of creating cookies, if the URL contains an underscore in the domain name.
We found this QandA on Internet Explorer and cookies:
http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx

Snowballing further from that link leads to the following KB:
https://support.microsoft.com/kb/316112/

“Security patch MS01-055 prevents servers with improper name syntax from setting cookies names. Domains that use cookies must use only alphanumeric characters (“-” or “.”) in the domain name and the server name. Internet Explorer blocks cookies from a server if the server name contains other characters, such as an underscore character (“_”).
Because ASP session state and session variables rely on cookies to function, ASP cannot maintain session state between requests if cookies cannot be set on the client.
This issue can also be caused by an incorrect name syntax in a host header.”

Basically the above security patch is implemented as part of Internet Explorer and the way it handles domain names and cookies.
So far this has been tested on the following versions of of Internet Explorer; IE8, IE9, IE10 and IE11.
This is not a problem for Chrome or Firefox – I have not tested with other browsers or versions.

Advertisements

ADFS 2.0 – Office365 – Signout

A client reported some problems with their Sign out functionality of their Office365 solution. They were using TMG as ADFS proxy and a load balancer, so I was expecting one of those components to be the root cause. Luckily I was able to quickly cut them out of the equation by using host files for name resolution. It all came down to updating the preferred authentication method for my ADFS site, from Windows Integrated to Forms based. Now it works. User can sign out and sign in with another user, without taking over any previous sessions.
So navigate to your ../ADFS/LS site physical location and open the web.config and modify the section as below. The change is on the Forms and Integrated sections switched places. Hopefully this will save you some annoyance for your Office365 implementations.

web.config:

     <localAuthenticationTypes>
      <add name="Forms" page="FormsSignIn.aspx" />
      <add name="Integrated" page="auth/integrated/" />
      <add name="TlsClient" page="auth/sslclient/" />
      <add name="Basic" page="auth/basic/" />
    </localAuthenticationTypes>      

Update 24-April-2014
The below link describes the above for AD FS 3.0
http://blog.auth360.net/2014/01/07/first-impressions-ad-fs-and-window-server-2012-r2-part-ii/

SharePoint with Azure Access Control Service

This article describes the installation process of using Azure Access Control Service (ACS) as an identity provider for SharePoint. This article uses Windows Live-ID as test.

This article uses ACS as the first federator after the consuming application with reference to the below architecture.

IdentityFederation

Prerequisites:
1: Administrative access to the Azure ACS. (https://manage.windowsazure.com/)
2: Access from SharePoint solution to Azure ACS url. (Internet browsing available)
3: Access to public URL of SharePoint solution. (SharePoint exposed to the internet)

Installation SharePoint with Azure Access Control Service

Identity Federation Infrastructure – Overview

The below should give a simple overview to the infrastructure of identity federation. The approach is generic, however my experience is vastly within the Microsoft portfolio of identity federation products. The following description is from an infrastructure perspective and does not cover the solution specific elements like the claim specification e.g.

Illustrated
IdentityFederation
Directory Services: Active Directory, eDirectory, Red Hat Directory Server
Consumer: SharePoint, CRM
Federator: Active Directoy Federation Services, Azure Account Control Service, Novell Access Manager

Explained
A federator(Identity Provider) can federate its own organization identities to either another federator or to a consumer.
The relying party is created from either the consumer or another federator, to the federator providing the identities.
A federator can federate one or more organizational identities to the same consumer.

Installation SharePoint 2013 with Web Application Proxy and ADFS – Kerberos

Installation of SharePoint 2013 with Web Application Proxy and ADFS – Kerberos
Had some issues trying to piece together all the parts of the puzzle in order to get Web Application Proxy, ADFS and Kerberos to work together with a SharePoint 2013 Web Application hosting a Business Intelligence site, the linked guide should outline the most relevant points required. The rest should be read from references.

Link to doc:
Installation SharePoint 2013 with Web Application Proxy and ADFS – Kerberos guide (Location on Google Drive)

References
Step 3: Publish Applications using AD FS Preauthentication
http://technet.microsoft.com/en-us/library/dn383640.aspx

SharePoint and the Web Application Proxy Role
http://thesharepointfarm.com/2014/02/sharepoint-and-the-web-application-proxy-role/

Understanding the AD FS 2.0 Proxy
http://blogs.technet.com/b/askds/archive/2012/01/05/understanding-the-ad-fs-2-0-proxy.aspx