You need to sign in to do that
Don't have an account?
Romeo Ngo 1
SSO issue - InResponseTo must be empty for Idp-init Browser POST Profile
Hi,
This is a Single Sign On with Microsoft Azure AD issue.
I'm setting it up on a sandbox and getting an error when tried to log in.
I'm looking at the SSO SAML Validator and see these errors below. I think #4 can be ignore but #6 may cause an issue. Do you know how to resolve this issue?
Thanks,
This is a Single Sign On with Microsoft Azure AD issue.
I'm setting it up on a sandbox and getting an error when tried to log in.
Login Error Your login attempt using single sign-on with an identity provider certificate has failed. Please contact your salesforce.com administrator for more information.
I'm looking at the SSO SAML Validator and see these errors below. I think #4 can be ignore but #6 may cause an issue. Do you know how to resolve this issue?
Thanks,
Results Last recorded SAML login failure: 2015-03-24T21:10:51.428Z Unexpected Exceptions Ok 1. Validating the Status Ok 2. Looking for an Authentication Statement Ok 3. Looking for a Conditions statement Ok 4. Checking that the timestamps in the assertion are valid Current time is after notOnOrAfter in Conditions Current time is: 2015-03-24T21:23:53.412Z Time limit in Conditions, adjusted for skew, is: 2015-03-24T21:18:51.884Z Timestamp of the response is outside of allowed time window Current time is: 2015-03-24T21:23:53.412Z Timestamp is: 2015-03-24T21:10:51.884Z Allowed skew in milliseconds is 480000 Timestamp of the assertion is outside of allowed time window Current time is: 2015-03-24T21:23:53.412Z Timestamp is: 2015-03-24T21:10:51.869Z Allowed skew in milliseconds is 480000 5. Checking that the Attribute namespace matches, if provided Not Provided 6. Miscellaneous format confirmations InResponseTo must be empty for Idp-init Browser POST Profile 7. Confirming Issuer matches Ok 8. Confirming a Subject Confirmation was provided and contains valid timestamps Ok 9. Checking that the Audience matches Ok 10. Checking the Recipient Ok Organization Id that we expected: 00Dq00000009EyE Organization Id that we found based on your assertion: 00Dq00000009EyE 11. Validating the Signature Is the response signed? false Is the assertion signed? true Is the correct certificate supplied in the keyinfo? true Ok 12. Checking that the Site URL Attribute contains a valid site url, if provided Not Provided 13. Looking for portal and organization id, if provided Not Provided 14. Checking if session security level is valid, if provided Ok Subject: [[[My User Email]]] Unable to map the subject to a Salesforce.com user AssertionId: _6f0bcc79-a407-46db-bf31-b7b5394a2ce3
We did get this working on Production since we allow users to log in with both SSO and their normal login and it doesn't interupt anyone while testing this on production.
My thought is the problem with email in sandbox different from production since they change the login email on sandbox (adding .sandboxname to the end of email) and this is what's causing the issue. Just a theory, haven't got a chance to test this out yet.
Good luck.
I have the same issue. Can't you add a more unique identifer? Such as automatically adding/mapping the Org ID?
As for handling Azure SSO to sandboxes, you can update your SSO user attribute for the sandbox to a join() value for the nae attribute. Set the first string to be the email address, the second string is the sandbox name (you'll have to set up a different Salesforce Sandbox application in Azure for each sandbox), and the separator is a period.
The resolution for this is -
Federation ID is case sensitive with Email ID.
i.e. for example if email ID is like Ramana.Reddy@XXXXX.com them the Federation ID on Single Sign-On should be setup as same Ramana.Reddy@XXXXX.com
Thank you.
Ramana.