(EDIT: I think this is sufficiently different from
The target principal name is incorrect. Cannot generate SSPI context to not be a duplicate.)
We've got two servers (SQL01 and SQL02) in the same domain. SQL Server on SQL02 can connect to SQL Server on SQL01, but not vice versa. On each node, ping -a and telnet mumble 1433 work fine. I've tried all combinations of non- and fully-qualified server names, with and without port number.
The only difference is that SPN on node 2 has two extra entries (circled in red). Should I delete them from node 2, or add similar records to node 1?
Node 1:
C:\Users\mumble>hostname
EW0VPNYWSQL01
C:\Users\mumble> sqlcmd -E -S EW0VPNYWSQL02.NYEZPCI.LOCAL,1433
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : SQL Server Network Interfaces: The target principal name is incorrect.
.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Cannot generate SSPI context.
Node 2:
C:\Users\mumble>hostname
EW0VPNYWSQL02
C:\Users\mumble>sqlcmd -E -S EW0VPNYWSQL01.NYEZPCI.LOCAL,1433
1
Yes, do the following steps:
Stop SQL Server service + SQL Agent on SQL02
Delete "MSSQLsvc" SPN's manually
Run:
setspn -d MSSQLSvc/EW0VPNYWSQL02.NYEZPCI.com:1433 NYEZPCI\EW0VPNYWSQL02
Run:
setspn -d MSSQLSvc/EW0VPNYWSQL02.NYEZPCI.com NYEZPCI\EW0VPNYWSQL02
Start SQL Server service + SQL Agent on SQL02
I guess that at one time, the SQL Server service has been started with NT SERVICE\MSSQLSERVER, before changing it to a domain service account
Related
When trying to get a psql shell (not using iam user) I am receiving:
> gcloud alpha sql connect pg-instance --database mydb --user myuser --project my-project
Starting Cloud SQL Proxy: [/Users/me/google-cloud-sdk/bin/cloud_sql_proxy -instances my-project:us-central1:pg-instance=tcp:9470 -credential_file /Users/me/.config/gcloud/legacy_credentials/me#me.com/adc.json]]
2022/03/15 14:47:59 Rlimits for file descriptors set to {Current = 8500, Max = 9223372036854775807}
2022/03/15 14:47:59 using credential file for authentication; path="/Users/me/.config/gcloud/legacy_credentials/me#me.com/adc.json"
2022/03/15 14:48:00 Listening on 127.0.0.1:9470 for my-project:us-central1:pg-instance
2022/03/15 14:48:00 Ready for new connections
Connecting to database with SQL user [myuser].Password:
psql: error: connection to server at "127.0.0.1", port 9470 failed: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
I had the same error message when connecting to Postgres(Cloud Sql) using a service account.
In my setup I did run cloud_sql_proxy inside docker container.
In order to make it work I had to add extra configuration defined in step #9 https://cloud.google.com/sql/docs/sqlserver/connect-docker#connect-client
docker run -d \
-v <PATH_TO_KEY_FILE>:/config \
-p 127.0.0.1:5432:5432\
gcr.io/cloudsql-docker/gce-proxy:1.33.1 /cloud_sql_proxy \
-instances=<INSTANCE_CONNECTION_NAME>=tcp:0.0.0.0:5432 -credential_file=/config
The missing bits were: host ip on port mapping and 0.0.0.0: in cloud_sql_proxy command
There are a few things I would like to point out. The best starting point for me would be the About connection options page; both the Overview and the Before you begin sections are very helpful to get the full idea of the process and how to properly configure the user. But the most important part is the Connection Options, for the message connection to server at "127.0.0.1" I’m guessing it is a private IP, but please make sure this section is covered before starting to debug.
In your case, the logs are saying there was an error in the connection to the server…
I used the Troubleshoot guide that includes the Diagnose issues link to get to the Debug connection issues page that has a lot of useful information on how to debug any connectivity issue.
Generally, connection issues fall into one of the following three areas:
Connecting - are you able to reach your instance over the network?
Authorizing - are you authorized to connect to the instance?
Authenticating - does the database accept your database credentials?
Each of those can be further broken down into different paths for investigation.
Once determining the connection method, there are different questions that will help to guide you through the possible troubleshooting paths.
If using these guides doesn’t get you a solution, please make sure to update your answer with the results, steps, and information followed to provide further help. This would be a good example, as it has the same log error, and this other question shows that there are a few different troubleshooting paths for this specific log message, plus they have useful information for you.
Per the Interbase Operations Guide, GBAK allows the IB server location to be specified like this:
-se localhost:service_mgr
Or if we were remoting to a server named "test" we could specify:
-se test:service_mgr
This would restore the data local to server "Test", or in the former example it would restore on the machine you're running the restore on which would give better performance.
How can this be specified in TIBRestore? There is a protocol property with TCP or Local. Does specifying the local protocol use localhost service_mgr? Or is it controlled by passing localhost as the server name?
If you're on a server named "jupiter" restoring to a server named "pluto" over a TCP/IP connection:
gbak -r user -joe -pass blurf# -se jupiter:service_mgr /backup/foo.ibk pluto:/companydb/foo.ib
From what I recall, you can also use a TCP/IP address, instead of the destination server name (i.e., 10.20.30.254 instead of pluto). That part is not really stated as such in the documentation but works on TCP/IP.
See the official examples for examples.
We have a RHEL7 Mongo server configured for kerberos authentication for Mongo connections. The Mongo instance start successfully which tells us the server principal keytab is defined correctly in AD and the KRB5_KTNAME value is correct. A kinit is successful for the id that we want to authenticate with, telling us the user keytab is valid. However when attempting to authenticate "Kerberos server not found" is returned. Looking at the kerberos trace it's reporting "localhost" instead of the fqdn.
Mongo Support reviewed the DNS definitions and they are correct so referred us to Redhat support. The relevant message in the trace is:
Getting credentials userid#DOMAIN -> mongodb/localhost# using ccache FILE: filename (values changed to protect me)
Dpes anyone have an idea why localhost is in this message instead of the fqdn as it should be? Again DNS entries look to be correct. The "server not found" message is issued because localhost isn't defined to AD of course.
Help is appreciated.
Problem solved. When executing the shell on the same host as the Mongo server, you must include the --hostname parameter and not let it default. Kerberos uses the hostname value when sending requests to the KDC.
I'm having issues when trying to connect to my Cloud SQL instance. I created a SQL Server instance, downloaded the cloud sql proxy, and everything seems to start to connect, but I keep getting the following error:
errors parsing config:
invalid "instance-connection-name": unsupported network: unix
I'm specifying the tcp port to use, but it still complains about UNIX. Here is the command I'm using when trying to connect (I replaced the actual instance connection name for privacy/security):
./cloud_sql_proxy.exe -instances=[instance-connection-name]=tcp:3306
Any help would be appreciated.
Thanks!
I tried this and it works
Rename cloud_sql_proxy_xxx to cloud_sql_proxy
Open cmd in your cloud_sql_proxy's location
Run the following command: cloud_sql_proxy -instances=[project:region:instance-name]=tcp:1433 without [ ]
From Connecting to a Cloud SQL for SQL Server using a Cloud SQL Proxy:
Depending on your language and environment, you can start the proxy using either TCP sockets or Unix sockets.
TCP sockets:
Copy your instance connection name from the Instance details page
For example: myproject:us-central1:myinstance.
If you are using a service account to authenticate the proxy, note the location on your client machine of the private key file that was created when you created the service account.
Start the proxy.
Some possible proxy invocation strings:
a) Using Cloud SDK authentication:
./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:1433
The specified port must not already be in use, for example, by a local database server.
b) Using a service account and explicit instance specification (recommended for production environments):
./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:1433 \
-credential_file=<PATH_TO_KEY_FILE> &
I have setup Active directory with kerberos authentication on windows server 2012 r2, set mongodb server on a 2nd machine. Started mongodb with GSSAPI authentication, Now if I try to connect to mongodb using the follwong url
mongo.exe --host Mongo32Test.ihubtest.com.com --authenticationMechanism=GSSAPI --authenticationDatabase=$external -u mongoService#ihubtest.com --verbose
I am getting the following message.
Error: SASL(-1): generic failure: SSPI: InitializeSecurityContext: The specified target is unknown or unreachable
I have installed wireshark and the packet contains this message
"KRB5 167 KRB Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN"
Searching around I figured that it is related to service principle name
mongoService#ihubtest.com is a domain user and is part of $external database in mongodb.
verified the service principle name, it looks fine.
C:>setspn -l mongoService
Registered ServicePrincipalNames for CN=mongo Service,CN=Users,DC=ihubtest,DC=com:
mongodb/Mongo32test.ihubtest.com#IHUBTEST.COM
tried the troubleshooting steps mentioned in this page, https://docs.mongodb.com/manual/tutorial/troubleshoot-kerberos/, am I missing something on Active directory configuration ?
if not yet looked into this ticket MongoDB Team has a closed ticket with some steps
https://jira.mongodb.org/browse/SERVER-13885
I believe in you misquoted your hostname as "Mongo32Test.ihubtest.com.com" instead of "Mongo32Test.ihubtest.com".
Please verify whether the provided hostname is correct or not