Authenticating Sharepoint 2013 on-premise with Azure AD - azure

Question

Our client has an Azure AD containing all users in his company located in multiple locations around the world. He would like his users to be able to sign into our SP app using their Microsoft Accounts which are on Azure AD.
Obviously, since Azure AD uses SAML 2.0, and SharePoint uses Ws-Fed (which is similar to SAML 1.1), we need to convert these claims from 2.0 to Ws-Fed (or SAML 1.1).
This used to be done using Azure's Azure Control Services, which is going to be deprecated at the end of the year (2018), so there's no point in developing a solution that uses it.
As such, we found a number of guides here and here which detail how a Claims Provider Trust can be created between Azure AD and ADFS, and a Relying Party Trust be set up between AD FS and SharePoint.
In theory this works in the following way:
User logs into his Microsoft Account which is on the Azure AD, and the SAML 2.0 token with claims is sent from Azure AD to AD FS
All claims are passed to AD FS, since we configured our rules in this way (as instructed here)
AD FS converts these from SAML 2.0 to Ws-Fed (or SAML 1.1)
AD FS maps the necessary claims to the UPN (as instructed here) and sends the result to SharePoint
We seem to be encountering an issue in the conversion step.
We have debugged the process using Fiddler, to see requests to and from the AD FS server. Azure AD claims are successfully sent to AD FS, but an error is encountered when AD FS is issue new claims (supposedly in Ws-Fed or SAML 1.1).
The following is the stack trace from AD FS:
Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.ServiceModel.FaultException: MSIS3127: The specified request failed.
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
--- End of inner exception stack trace ---
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, UInt32 lifetime, Uri& replyTo)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolResponse(FederationPassiveContext federationPassiveContext)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
System.ServiceModel.FaultException: MSIS3127: The specified request failed.
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
We've also done internal testing, whereby we logged in to the SharePoint site using the the local AD, in order to make sure that the setup between AD FS and SharePoint is correct. This worked as expected, and SharePoint received the claims as configured in step 4.
Any help with the "conversion" process from SAML 2.0 to Ws-Fed (or SAML 1.1) would be greatly appreciated.
Help me Obi-Wan Kenobi, you're my only hope!

Answer 1

Set AD FS' PreventTokenReplays param to false
In our case, this is what had us stuck for days. There was no mention of this anywhere that we read, and we only found out about it after going to the AD FS server's event viewer and going through the logs.
Open up PowerShell, and add the AD FS snapin using the following:
Add-PSSnapin Microsoft.Adfs.PowerShell
Then, get your AD FS properties, using the following:
Get-adfsproperties
Check the value for the PreventTokenReplays param. If it's set to false, you should be good.  If it's set to true, then flip it to false using the following command:
Set-adfsproperties -PreventTokenReplays $false
Now, you'll need to restart your AD FS service. Just go to services.msc, find AD FS 2.0 Windows Service, right click it, and hit restart.

Answer 2

Configuration Overview
Create a new Azure AD tenant and namespace.
Add a WS-Federation identity provider.
Add SharePoint as a relying party application.
Create a rule group for claims-based authentication.
Configure the X.509 certificate.
Create a claim mapping.
Configure SharePoint for the new identity provider.
Set the permissions.
Verify the new provider
You can follow this blog for step by step process
https://www.sharepointcollabs.com/2017/03/using-microsoft-azure-active-directory.html