I'm configuring a Service Provider to connect to ADFS, and looking up the error we get says:
The Federation Service encountered an error while processing the SAML authentication request.
Microsoft.IdentityModel.Protocols.XmlSignature.SignatureVerificationFailedException: MSIS0037: No signature verification certificate found for issuer 'myapp.domain.com'.
at Microsoft.IdentityServer.Protocols.Saml.Contract.SamlContractUtility.CreateSamlMessage(MSISSamlBindingMessage message)
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.Issue(IssueRequest issueRequest)
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.ProcessRequest(Message requestMessage)
I'm just the client / SP, I don't have access to the ADFS server, its managed by a different company, in a different country. So, like Jon Snow, I know nothing.
The internet seems to suggest that perhaps these two Microsoft KB's might be relevant:
KB2843638 (a security update that causes an issue)
KB2896713 (a follow up patch)
Is the metadata not trusted by the IDP, or that would be a different issue?
I have seen this error when the request and the Relying Party identifier registration on ADFS (2.1) did not match in casing. For instance the error would occur if the request said: urn:MyRPId and the ADFS registration was urn:myrpid.
Related
I implement my ASP.Net Web Application SSO with Azure AD. Everything work fine my testing server which has an internet connection.
My customer policy does not allow internet connection on their server and the SSO failed when validate the token from the Microsoft after user authenticated. The error is "IDX20803: Unable to obtain configuration from: [PII is Hidden]".
I add the Microsoft.IdentityModel.Logging.IdentityModelEventSource.ShowPII = true; to my Startup.cs class, the error more detail: "IDX20803: Unable to obtain configuration from: 'https://login.microsoftonline.com/MYTENANTID/.well-known/openid-configuration'".
My question is: I will request my customer open their firewall to allow only login.mirosoftonline.com. Does it enough? Does it need to allow another requests? And what are another requests?
according to microsoft, https://learn.microsoft.com/en-ca/office365/enterprise/urls-and-ip-address-ranges#microsoft-365-common-and-office-online
I believe category 56 is for identity and authentication, whether you need them all, I'm not sure, but Microsoft seems to think so?
56 Allow
Required Yes *.msappproxy.net, *.msftidentity.com, *.msidentity.com, account.activedirectory.windowsazure.com, accounts.accesscontrol.windows.net, adminwebservice.microsoftonline.com, api.passwordreset.microsoftonline.com, autologon.microsoftazuread-sso.com, becws.microsoftonline.com, clientconfig.microsoftonline-p.net, companymanager.microsoftonline.com, device.login.microsoftonline.com, graph.microsoft.com, graph.windows.net, login.microsoft.com, login.microsoftonline.com, login.microsoftonline-p.com, login.windows.net, logincert.microsoftonline.com, loginex.microsoftonline.com, login-us.microsoftonline.com, nexus.microsoftonline-p.com, passwordreset.microsoftonline.com, provisioningapi.microsoftonline.com
20.190.128.0/18, 40.126.0.0/18, 2603:1006:2000::/48, 2603:1007:200::/48, 2603:1016:1400::/48, 2603:1017::/48, 2603:1026:3000::/48, 2603:1027:1::/48, 2603:1036:3000::/48, 2603:1037:1::/48, 2603:1046:2000::/48, 2603:1047:1::/48, 2603:1056:2000::/48, 2603:1057:2::/48
I am working to understand the SAML request process using PingFederate.
I am making the SAML RST request in order to gain access to a SharePoint Online instance. PingFederate SSO is successfully set up and users must login through ping in order to get to sharepoint online.
Now I want to make a Saml RST to PingFederate STS using the Java STS SDK 1.1.
I have a working STS endpoint: https://my.ping.endpoint/sp/sts.wst
And my SharepointOnline endpoint is: https://mydomain.sharepoint.com
I am trying to figure out what to use as AppliesTo in this scenario.
Definition:
The Relying Party realm the token is to be issued for.
I've tried setting it to anything we can think of. But no luck. I was fairly sure I could use: https://tenantname.sharepoint.com/_forms/default.aspx?wa=wsignin1.0 but it didn't work. I keep getting a SOAP Fault from ping STS:
Unable to determine partner SP connection by AppliesTo: http://my-AppliesTo-url-here
Is this some URL I need to get from the PingFederate admin UI? How can I find this?
Under your "SP Connection", "WS-Trust STS", "Protocol Settings" there is a place to enter the "PARTNER SERVICE IDENTIFIER (CORRESPONDS TO APPLIESTO IN RST)"
I've encountered a challenge regarding internet-facing deployment installation for CRM using a AD FS server. After the setup is complete, users are able to access the CRM server - but when trying to run custom pages the following error message is prompted:
"The authentication endpoint Kerberos was not found on the configured Secure Token Service!"
I've found several solutions on the internet for this issue:
First I found a KB article from Microsoft providing a possible
solution, this involves updating MEX endpoints by running a provided
PowerShell script.
(https://support.microsoft.com/en-us/help/2828015/configuring-ad-fs-2.1-with-microsoft-dynamics-crm-2011).
But this doesn't seem to be the issue.
Another solution could be to update the CRM rollup version (currently have version 14 installed, latest is version 18) - this is something that I want to avoid as it might lead to further issues.
Have anybody else encountered a similar issue, and in that case how did you solve it?
I have just spent last few days to figure this exact same error message and it turned out that it was the "Domain" attribute in crm connection string. Copied my answer to my own question at the Microsoft Dynamics CRM community forum here:
"Well, I found the culprit - it was the Domain attribute in the connection string:
For connecting from outside the domain, it does not like to have a Domain in the connection string:
Connection string format 1 (without Domain attribute): "Authentication Type=Passport;Server=https://devcrm.myco.com;Username=devuser#myco.com;Password=pwd" - this works both inside and outside the domain "myco.com"
Connection string format 2 (with Domain attribute): "Authentication Type=Passport;Server=https://devcrm.myco.com;Domain=myco;Username=devuser#myco.com;Password=pwd" - this only works inside the domain myco.com but NOT outside (exception: The authentication endpoint Kerberos was not found on the configured Secure Token Service!)
The key is in the Xrm.Client.CrmConnection.ClientCredential:
If Domain is NOT specified in the connection string, when connecting from outside domain, Xrm.Client.CrmConnection.ClientCredentials.UserName is populated whereas the ClientCredentials.Windows.ClientCredentials.UserName is empty.
But if the Domain is specified, Xrm.Client.CrmConnection.ClientCredentials.UserName becomes null and Xrm.Client.CrmConnection.ClientCredentials.Windows.ClientCredentials.UserName populated, which led to the service trying to authenticate user as a Windows AD user so of course it would fail when running app from outside Windows domain. And it explains why the same app works inside the domain even with Domain specified in the connection string.
For more detail, refer here for my original post asking for help in Dynamics CRM Forum
This error is getting me crazy for two days!.
I have a web server and an adfs server (both windows server 2012). I configured adfs correctly. I can see the adfs/ls authentication page and I can log on using an AD user from the adfs server. When I try to reach adfs/ls authentication page, from the web server, is redirecting correctly to the adfs server so I can enter my username and password. When is coming back I receive this error on the page:
There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
Authentication failed. Close the browser and try again, or contact your administrator for more information.
Reference number: 8949f368-ee3b-4c94-a749-63950dfc42b9
and on the adfs server I have this event id 111:
The Federation Service encountered an error while processing the WS-Trust request.
Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
Additional Data
Exception details:
Microsoft.IdentityServer.Framework.SecurityTokenService.FailedAuthenticationException: MSIS3055: The requested relying party trust 'http://myserver.com/MyApplication' is unspecified or unsupported. If a relying party trust was specified, it is possible the user does not have permission to access the relying party trust. ---> Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'http://myserver.com/MyApplication' could not be located.
--- End of inner exception stack trace ---
at System.IdentityModel.AsyncResult.End(IAsyncResult result)
at System.ServiceModel.Security.WSTrustServiceContract.ProcessCoreAsyncResult.End(IAsyncResult ar)
at System.ServiceModel.Security.WSTrustServiceContract.EndProcessCore(IAsyncResult ar, String requestAction, String responseAction, String trustNamespace)
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'http://myserver.com/MyApplication' could not be located.
Relying party trust are configured in both servers, also certificates are correct but apparently something is missing or wrong. Any help would be much appreciated!
The normal reason for this is that the WIF realm in the app. web.config does not match the string in the ADFS RP Identifiers tab.
And that includes the trailing slash!
You have:
http://myserver.com/MyApplication in ADFS
Did you configure it as:
http://myserver.com/MyApplication/ in WIF?
I am trying to validate a SAML response which is coming from Siteminder IDP from a third party. I have installed the certificate provided by them. When I call the ValidateToken method (System.IdentityModel.Tokens) to create claims, I get following error :
WIF10201: No valid key mapping found for
securityToken:'System.IdentityModel.Tokens.X509SecurityToken' and
issuer: 'issuer uri'
I dug in deep to find the error and its being thrown by method GetIssuerName (System.IdentityModel.Tokens).
Where is the problem? I googled for this issue but didn't find anything specific to my case. Does the SAML token from my client have a problem or there is something I am missing in implementation. I am fairly new to federated auth so please excuse any inaccuracy with the terminology used.
Gaurav
Ok found the solution but could't quite understand the readon behind it (complete noob, will update the answer when I know more).
Followed this approach of converting the SAML2 response to WSFed response, then on that new token I ran my code, now the error is gone.
http://blogs.msdn.com/b/bradleycotier/archive/2012/10/28/saml-2-0-tokens-and-wif-bridging-the-divide.aspx
Note : you still have to override the validate token method (which I had originally done) to avoid the following error :
“ID4154: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an InResponseTo value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.”
Thanks.
You are probably missing a configuration that maps the issuer name (as specified inside the token) to the certificate (probably specified with a thumbprint). I guess you solve this with some configuration in your web.config. Have a look at p.e. Microsoft validating issuer name registry The page contains some sample configuration. Setting this up correctly depends entirely on your situation.
I wanted to make a note for future reference, since I also ran into this error but my resolution was different. I got the WIF10201 error in a custom MVC application that is using ADFS (3.0) claims-based authentication under Windows Server 2012. In the web.config of the MVC application, the thumbprint of the ADFS token signing key is recorded. It turns out, when the signing certificate is about to expire, ADFS creates a new key. The new key is marked "primary" and the old key is marked as "secondary" in the ADFS console (under AD FS/Service/Certificates). So in my web.config there was, of course, still the thumbprint of the old (secondary) key. As soon as I replaced it with the thumbprint of the new (primary) key, the error disappeared.