I have service provider application http://sp.example.com/sp and when user accesses it through a browser, user is redirected from my SP application to IdP server which is configured on PingFederate server with an SP connection(http://sp.example.com/sp) as entity id. User is redirected through SAML protocol with SAML AuthnRequest to IdP. But on Ping server I keep getting this error which says
unable to lookup idp connection metadata for entityid='http://sp.example.com/sp'
Does anyone have face similar error before with Ping? This is SP-initiated SSO.
Request I am sending to PingFederate
<?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://sp.example.com/sp" Destination="https://idp.com/sp/ACS.saml2" ForceAuthn="false" ID="_93313f7882ff7b3274da46502c4cf072" IsPassive="false" IssueInstant="2014-04-29T15:15:04.666Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Version="2.0"><samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.example.com/sp</samlp:Issuer><saml2p:NameIDPolicy xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AllowCreate="true" SPNameQualifier="https://sp.example.com/sp"/><saml2p:RequestedAuthnContext xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact"><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml2p:RequestedAuthnContext></samlp:AuthnRequest>
You can find possible solutions to your problem in Ping's support center:
https://www.pingidentity.com/support/solutions/index.cfm/SSO-fails-with-Unable-to-lookup-sp-or-idp-connection-metadata-for-entityid
In the server.log, the error "Unable to lookup sp connection metadata
for entityid" is seen. This is usually an indication that there is a
mismatch between the Partner Entity ID (Connection ID) configured in
the IDP-side PingFederate SP Connection and the actual entity ID of
the partner, and therefore PF cannot determine which SP Connection to
use when a SAML AuthnRequest comes in from the SP in the SP-initiated
SSO use case.
https://www.pingidentity.com/support/solutions/index.cfm/Unable-to-lookup-sp-connection-metadata-for-entityid
Since Entity ID is case sensitive, if there is a mismatch between the
value entered for the Partner's Entity ID (Connection ID) field in the
PingFederate Administrative Console and what the partner is sending in
the SAML protocol message, then the SSO attempt will fail with the
"Unable to lookup sp (or idp) connection" error message.
The solution is to verify the Partner's Entity ID (Connection ID)
setting matches exactly what is sent by the partner in the SAML
messages.
Related
Need to connect SFDC Sandbox to Azure Data Factory but getting the following error when setting up the linked service and testing the connection:
Error code9603
DetailsERROR [HY000] [Microsoft][Salesforce] (80) Unknown error received from SOAP response, potentially a problem with user privileges. ERROR [HY000] [Microsoft][Salesforce] (80) Unknown error received from SOAP response, potentially a problem with user privileges. Activity ID: ba13abc8-5490-4d7a-afd4-cf4d5ddf5e86.
I confirm the security token for this account has been reset, the SFDC account has been assigned a profile of privileges where 'API enabled' is selected. I have also tried to pass the credentials through Azure Key Vault when setting up the linked account in Data Factory.
Are there any other permissions in Salesforce required so that we can check if everything is selected?
How can we find out what this unknown SOAP error is?
As API Enable is checked, there must be a problem with user access or organization access.
Follow the steps below:
Goto Setup -> Permission sets -> Check the name -> Goto systems permissions -> click on manage assignments
Check whether the integration user is added to those permissions or not. If not, add now.
If the integration is not possible, then mostly your organization or the account using for the operation is not having the API access.
Check whether the organization or the account which is being used for this operation is having API access or not, by visiting Organization Edition
My SNOWFLAKE database is SSO login enabled and the SSO connectivity works perfectly fine when I connect through my chrome browser.
When I try to connect to SNOWFLAKE database using DBeaver (external browser) I get the below error .
NOTE : I can confirm that I am able to see the identity verification (through explorer browser) page and the identity has also been verified. I feel the issue happens when the explorer browser confirms the identity verification back to DBeaver.
Can anyone please help ?
The above error is a generic message and could be seen due to misconfigurations either at the identity provider end or at the service provider end.
It is recommended to verify the configurations for your identity provider and make sure all the steps are performed correctly.
Below could be the common reasons for this error, However, there might be other improper configs as well which could lead to a similar error message.
a. Mismatch in user configuration details at Idp(Identity provider) and Snowflake.
b. SSO certificates are incorrect.
Solution
a. Username configured at the Identity provider end should match with the login_name at snowflake end for that user. For instance, If the SAML response shows NameID as abc#xyz.com. Then login_name configured at Snowflake end should be same as abc#xyz.com
SAML response snippet:
abc#xyz.com
Set the login_name same as the NameID configured at the identity provider side.
alter user set login_name='abc#xyz.com';
b. SSO certificate configured at Snowflake end should match with the certificate configured at the identity provider end.
Note:
The certificate value contains a number of new lines. Remove the new lines, forming a certificate value with a single line.
If the above suggestions did not help then please check the error codes for the failed login attempt in Snowflake Information Schema using the below query. And check the reason for that error code here. The below query retrieve up to 100 login events of every user your current role is allowed to monitor in the last hour and you can modify it appropriately.
select * from table(information_schema.login_history(dateadd('hours',-1,current_timestamp()),current_timestamp())) order by event_time
I have an AAD/AD Federated tenant setup. Obviously AAD in Azure, local AD is lab setup with VMs. I've gone through a few permutations of the AADConnect setup, but I always end up with this same error. Looking it up, it seems usually associated with SQLServer, but I don't think that applies here. I'm simply trying to use IWA to authenticate to this AAD federated app but cannot escape this exception.
Local AD
Domain: vandelay.local
ADDS,ADFS,DNS: WIN-H9QGD6BJ2IN.vandelay.local
ADFS DNS: adfs.ad.vandelay.local
Alternate UPN: vandelay.firstresponse911.net
AAD Connect setup with Federation and Password Hash Sync
AAD
AADConnect setup appears to be happy (see screenshot)
App added with globally granted admin consent for app (does not require user interaction to grant permission)
Users synced with AADConnect appear in portal with permission for App.
Code
// Signed into machine as steve.doe#vandelay.firstresponse911.net
static void Main(string[] args)
{
app = PublicClientApplicationBuilder.Create(CLIENT_ID)
.WithAuthority(AzureCloudInstance.AzurePublic, TENANT_ID, false)
.Build();
while (true)
{
var result = _retry.Execute((ctx) => GetToken2().GetAwaiter().GetResult(), new Context("acquireToken", new Dictionary<string, object>() { { "userId", "paul.seabury#vandelay.local" }, { "password", "AGF11nfn" } }));
Console.WriteLine($"IdTok: {ComputeSha256Hash(result.IdToken)}, Exp: {result.ExpiresOn}");
Thread.Sleep(1000 * 60 * 2);
}
}
private static Task<AuthenticationResult> GetToken2()
{
var upn = System.DirectoryServices.AccountManagement.UserPrincipal.Current;
var cachedResult = app.AcquireTokenByIntegratedWindowsAuth(scopes).WithUsername(upn.UserPrincipalName).ExecuteAsync().GetAwaiter().GetResult();
return Task.FromResult(cachedResult);
}
}
Exception
Microsoft.Identity.Client.MsalClientException: 'The target principal name is incorrect.'
This is accompanied on the same client machine by an EventLog Entry:
The Kerberos client received a
KRB_AP_ERR_MODIFIED error from the server fsgma$. The target name used
was HTTP/win-h9qgd6bj2in.vandelay.local. This indicates that the
target server failed to decrypt the ticket provided by the client.
This can occur when the target server principal name (SPN) is
registered on an account other than the account the target service is
using. Ensure that the target SPN is only registered on the account
used by the server. This error can also happen if the target service
account password is different than what is configured on the Kerberos
Key Distribution Center for that target service. Ensure that the
service on the server and the KDC are both configured to use the same
password. If the server name is not fully qualified, and the target
domain (VANDELAY.LOCAL) is different from the client domain
(VANDELAY.LOCAL), check if there are identically named server accounts
in these two domains, or use the fully-qualified name to identify the
server.
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-Security-Kerberos" Guid="{98E6CFCB-EE0A-41E0-A57B-622D4E1B30B1}" EventSourceName="Kerberos" />
<EventID Qualifiers="16384">4</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2020-10-30T15:24:32.660502800Z" />
<EventRecordID>3393</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>DESKTOP-BJ6P4H4.vandelay.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="Server">fsgma$</Data>
<Data Name="TargetRealm">VANDELAY.LOCAL</Data>
<Data Name="Targetname">HTTP/win-h9qgd6bj2in.vandelay.local</Data>
<Data Name="ClientRealm">VANDELAY.LOCAL</Data>
<Binary />
</EventData>
</Event>
Http Traffic
It looks like the MSAL code successfully asks AAD to Authenticate for this app, which via discovery sends the response back to talk to the locally federated ADFS server. After getting the local metadata, the MSAL code attempts 3 times to get a token from the windowstransport endpoint. The first attempt with no Authorization header, the 2nd and 3rd attempt have differing Authorization(Negotiate) headers with encoded data, but they all fail with 401.
The posted request looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<wsa:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
<wsa:messageID>urn:uuid:42420a0c-3505-455f-914d-639c5685b43d</wsa:messageID>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:To s:mustUnderstand="1">https://adfs.ad.vandelay.local/adfs/services/trust/2005/windowstransport</wsa:To>
</s:Header>
<s:Body>
<wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsa:EndpointReference>
<wsa:Address>urn:federation:MicrosoftOnline</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wst:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType>
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>
and the sequence looks like this:
It looks like you are using a CNAME in DNS to resolve the adfs farm name -->you should use an Host A Record
Kerberos Clients will first resolve the name of the web service to the A Record before requesting the Kerberos Service Ticket
This would explain the kerberos error you see
"The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server fsgma$. The target name used was HTTP/win-h9qgd6bj2in.vandelay.local. "
I have a service broker configured in two different databases on two different servers. The problem is that I can't receive message because I have the problem:
Connection handshake failed. The login 'public' does not have CONNECT permission on the endpoint. State 84.
I have endpoints with certyficates, I gave permission to connect to a specific user who has a certificate(I did it on two servers because it is always on availability group), while looking for a problem I noticed that the certificate from the initiating server is different from the certificate from the target server:
-initiator - signature algorithm: sha1RSA, key length: 1024 (sql ver. 11.0.7 ...)
-target - signature algorithm: sha256RSA, key length: 2048 (sql ver. 15.0.4 ...)
When I grant permission:
grant connect on endpoint :: BrokerEndPoint to PUBLIC
Servers communicate but this does not solve the problem.
Can different types of certificates be a problem?
grant connect on endpoint :: BrokerEndPoint to PUBLIC
Doing this basically bypasses authorization, as everybody is authorized to connect. I think you should try to fix the user/roles permission.
I noticed that the certificate from the initiating server is different from the certificate from the target server:
This shouldn't make any difference.
It looks like the problem is you somehow misconfigured the users/login/certs chain. Is so darn complicated that is easy to break... Here is a redux of the proper setup:
There are two layers of security: conversation security (between services in DBs) and transport security (between endpoints in instances). You are now talking about transport security (endpoint to endpoint).
Endpoint security is always between the SQL instances involved. If you have AGs then each node needs to be separately configured, as the endpoints are instance level concepts and do not follow AG failovers.
An endpoint will use the certificate configured (CREATE ENDPOINT ... FOR SERVICE_BROKER (AUTHENTICATION = CERTIFICATE <certname>)). The certificate must have an accessible private key to be usable (ie encrypted with a key that can be opened from the service master key, usually via the master database master key).
During handshake, the authentication and authorization is mutual. Say to instances, S1 and S2 need to connect, then:
S1 will use certificate C1, S2 uses certificate C2
S1 needs to have C2 (public key only) in its master database, and S2 needs to have C1 (public key only) in its master.
The C2 certificate in S1 master is owned by a database user (a database principal), say it's US2. This user has a login (a server principal, say UL2). The login UL2 must be granted CONNECT permission on the S1 endpoint.
Vice-versa: the C1 certificate in S2 master is owned by an user (US1) that has a login (UL1). This login UL1 needs to be granted CONNECT permission on S2 endpoint.
For troubleshooting, enable the "Audit Broker Login" event in Profiles (in the Security Audit group). This event will fire with details of why a handshake fails, when it fails.
Ty for your time, I checked the connection and data again and found no problem anywhere. As I was bothered by the fact that maybe it was a problem that I wrote about so for the test I created another connection but this time on the server with SHA256 certificate and as I thought it is a problem here. To confirm my theory, I replaced the certificate on the initial server about which I wrote earlier to SHA256 (I deleted and re-created the endpoint with this certificate) and on the target server I replaced this certificate and the problem was solved. So it's like I thought certificates must have the same type of encoding.
I have a problem with Database mail, which we are currently trying to change accounts for a database mail with a gmail account.
The problem is when I try to send an email with the wrong email account, the sent_status is always "Sent" in the log.
whereas before, when we used local e-mail, always showed a failed status when we tried it with the wrong e-mail.
SQL Server will just trigger the mail through SMTP, But if you wanna track the delivery status then you should check on SMTP server, which has been used in Mail configuration.