Certain legacy features in SharePoint Online — Explorer view, for example — leverage legacy technologies like Windows WebDAV. WebDAV makes use of the browser's authentication cookie. Because of security concerns, WebDAV cannot access session cookies; only cookies that are written to disk are accessible by WebDAV. This means that in order for WebDAV to access the authentication cookie, the cookie needs to be persistent (persistent cookies are written to disk)*.
The easiest way to ensure cookie persistence is to check the "Keep Me Signed In" box on the Office 365 Home Realm Discovery Page before entering your username and password. However, some customers who have Auto-Acceleration enabled in their tenancies will not be presented with a home realm discovery page. Other administrators may wish to issue persistent cookies across the organization, or a subset of the organization, and not have to bother with user education or extra steps in order to streamline user workloads and ensure capabilities. Typically, these Administrators have federated identity providers (such as ADFS.) If you have ADFS using WS-Fed Federation with Office 365, you can direct Azure Active Directory to issue a persistent cookie by including certain claims rules in your Relying Party Trust**.
Previously, if your ADFS Properties were set to allow the Keep Me Signed In Enabled and Persistent SSO Enabled attributes (Set-Adfsproperties -KmsiEnabled and -PersistentSSOEnabled, respectively) then the Persistent SSO claim was present in the claims pipeline, and administrators could pass that claim through to the service. However, a fix was recently (August 2017) released that only issues the PSSO claim on the pipeline if the KMSI option is checked at the identity provider's Forms Based Authentication page. Therefore, customers may have noticed that they are no longer being issued persistent cookies in SharePoint Online. To work around this fix, ADFS Administrators can add or edit their issuance claims rules for the Microsoft Office 365 Identity Platform relying party trust to include the PSSO claim as follows:
=> issue(Type = "http://schemas.microsoft.com/2014/03/psso", Value = "true");
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"] => issue(claim = c);
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"] => issue(Type = "http://schemas.microsoft.com/2014/03/psso", Value = "true");
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "[SID OF GROUP]", Issuer == "AD AUTHORITY"] => issue(Type = "http://schemas.microsoft.com/2014/03/psso", Value = "True", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);
Your organization's administrator for Active Directory Federation Services will know how to access the Office 365 Relying Party Trust; however, for completeness, here is how one would implement the claims rules above.
In ADFS, open the ADFS Management Console (In Server Manager > Tools > ADFS Management)
In the left hand navigation pane of the ADFS Management Console select ADFS > Trust Relationships > Relying Party Trusts. There you will see the trusts that have been configured. By default, the Office 365 Relying Party Trust Display Name is "Microsoft Office O365 Identity Platform" and the Identifier is "urn:federation:MicrosoftOnline"
Right click the Microsoft Office O365 Identity Platform and select Edit Claims Rules. The rules above are Issuance Transform Rules. You can add them by clicking the Add rule and choosing the "Send Claims Using a Custom Rule" Option:
Here is an example of a simple issue of the PSSO Claim:
Click Finish, and the Claims Rule will be added to the pipeline. Please note that order matters; if you decide to issue the PSSO claim based on another claim (such as the InsideCorporateNetwork Claim, above), that claims rule must be present before the PSSO claim.
*: Administrators should use caution when deciding if and how to issue these cookies. Currently, there is no check if a specific setting has changed; so long as the user has a valid FedAuth cookie, they are allowed access to SharePoint resources and do not have to re-authenticate. For example, someone who issues a persistent cookie based on a machine being inside the corporate network (Example above), who then takes their laptop down the street and access SPO from the corner coffee shop, will still be able to access SharePoint Resources.
It is up to the administrator to understand and manage the kinds of risks using these cookies can incur.
**: As of right now, AAD does not support SAML based use of the Persistent Single Sign On Claim / SAML attribute.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.