I am trying to link two SQL Servers (2008R2 and 2014) which are running in two separate (!) Active Directory domains.
The problem is that I can login into the remote server only with a Windows Account from the remote domain. So the challenge is to pass on the credentials to the remote server, but here I am stuck.
Local Domain (local network infrastructure): dom8, Server: dom8\sql2008, SQL (!) Login: localuser
Remote Domain (Microsoft Azure): dom14, Server: dom14\sql20148, Windows (!) Login: dom14\import
Server dom8\sql2008 wants to connect to dom14\sql2014 in order to pull some data.
Here is what I have tried on the local server: (logged into dom8\sql2008 as sa) :
-- Create a credential for the remote Windows login:
create credential cred_import WITH IDENTITY= 'dom14\user14',
SECRET = 'password' ;
-- Alter the local SQL login and add the created credential:
alter login local_user with credential = cred_import ;
-- Create the Linked Server entry:
exec sp_addlinkedserver
#server='dom14\sql2014',
#srvproduct='SQL Server'
-- Add the credential to the linked server:
exec sp_addlinkedsrvlogin
#rmtsrvname ='dom14\sql2014',
#useself = 'FALSE',
#locallogin=local_user,
#rmtuser = [cred_import], -- trying to pass on the credential
#rmtpassword = NULL
However, it does not work. Whenever user localuser tries to connect to the remote server through the local server, then it gets an error login failed.
By the way, I can connect to the remote domain by using SQL Server Studio as follows:
runas /netonly /user:dom14\user14 "C:\...\Ssms.exe"
So obviously I can create a credential of the remote side on the local side. Only a remote server link does not work.
You will need a trust between the two domains in order to log into a domain A machine with a domain B password.
Once the trust is in place, you can then go to the domain A machine and grant permissions to the domain B user ID the permissions needed to do what your wanting to do.
However, it looks more like your trying to use local accounts, not domain accounts based on your script. I suspect the way you have the domain referenced, versus the server it's self may be the cause.
Looking at lines:
-- Create a credential for the remote Windows login:
create credential cred_import WITH IDENTITY= 'dom14\user14',
SECRET = 'password' ;
Is DOM14 the name of your domain? Or the name of the server your trying to connect to?
exec sp_addlinkedserver
#server='dom14\sql2014',
#srvproduct='SQL Server'
A server in another domain would be XYZ.DOMAIN.COM where XYZ is the actual server name, and domain.com is the domain that server is in. Also, you will need to make sure the server has access to read the other domains DNS tables.
From server A, you should be able to go to a CMD prompt and ping the other server by name (FQDN may be needed depending on Suffix Search list). Not concerned if the ping fails, as long as the IP address for the server is returned. If you don't get an IP address back, you have a more basic problem of name resolution between domains (you may need a forwarder in Domain A's DNS server pointing Domain B's name to a DNS server in Domain B), and vice versa (A to B, B to A, etc).
Related
I am looking to connect my existing PostgreSQL instance on Azure to PG-Admin. Following the advice here, however I get a Unable to connect to server: could not translate host name error. To the best of my knowledge, the host name should be correct. I am taking it from the overview page on Azure, and can confirm it follows the right format of "servername.postgres.database.azure.com". I have also confirmed that that password and usernames are correct, and SSL Mode is set to require (see screenshot, with dummy variables).
In addition, I have tried this on a seperate database in Azure with the same result. No doubt its a mistake I'm making with the hostname/address field in PG-Admin, but I've no idea how to correct.
Prerequisites for connecting PostgreSQL server
Connectivity method: public if we allow for all traffic, private if we restrict traffic via VNet.
Add the IP address where PgAdmin4 is running to the firewall rule.
Step1:
Created a new PostgreSQL server
Step2:
Updated network firewall setting as fallows and saved
Verification from PgAdmin4
Step1:
copy the server's name, user and password from the server setting
Step2:
Open PgAdmin4 portal and click on register server information
On General Tab, enter
- Name: "Any Name"
On Connection Tab:
HostName : "Server Name from the portal"
User Name: "Server admin login name from portal"
Password: "Enter Admin Password"
Database: "Enter DB name else keep same name"
On SSL Tab:
Keep SSL Mode as "Require" and click on SAVE
Upon Save.
NOTE: Make sure firewall should allow and SSL should be Require.
I have 2 systems. system A and system B and both are DB2 servers. I want to be able to access system B database from system A. Both have a database called TESTDB. I am trying to run the following command to create a server.
CREATE WRAPPER "drdawrapper"
LIBRARY 'libdb2drda.so'
OPTIONS (DB2_FENCED 'Y'
);
db2 "CREATE SERVER "PRD_SERVER_SSL_FLEX" TYPE DB2/UDB VERSION '11' WRAPPER "drdawrapper" AUTHORIZATION "xyz" PASSWORD "xyz" OPTIONS (DB2_CONCAT_NULL_NULL 'Y',DB2_VARCHAR_BLANKPADDED_COMPARISON 'Y',DBNAME 'TESTDB',HOST '169.62.253.230',NO_EMPTY_STRING 'N',PORT '50001',SECURITY 'SSL',STRING_UNITS 'S');"
But I keep getting:
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL1101N Remote database "TESTDB" on node "<unknown>" could not be accessed
with the specified authorization id and password. SQLSTATE=08004
Node directory:
db2 list node directory
Node Directory
Number of entries in the directory = 1
Node 1 entry:
Node name = TESTNODE
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = 123.21.23.12
Service name = 50001
The credentials are correct. I am not sure what node is it looking for. Any pointers?
Your question is more about configuration than programming.
As you appear to be encrypting the federated connection it can be wise to first verify that the encrypted connection works at the command-line, separately from federation. This irons out a lot of the detail and is easier to troubleshoot. After you get that working, you can then begin on encrypting the federated connection.
Please follow the detailed instructions here (choose the correct Db2-version):
You have to know in advance which kind of SSL/TLS trust verification you want (i.e. either single cert (client trusts the server - simplest and easiest), or multiple certs (both sides trust the other - more setup, arguably more secure), because this determines the configuration.
Ensure both of your Db2 instances and databases are properly configured for SSL.
Catalog the remote-node locally with security SSL (db2 catalog tcpip node ... remote ... server ...security ssl)
Catalog the remote-database locally on the new node name (db2 catalog database ... at node ...) followed by db2 terminate .
Verify a command-line connect to the remote database using the federated credentials, using the configured db2dsdriver.cfg if using SSLSERVERCERTIFICATE method, or using the keystore/stash configuration ( db2 connect to remotedb user ... using ... ). Use the same userid/password that you will use later in the create server command.
Once that command-line connect works, you can proceed with the encrypted federation link, via db2 create wrapper... and db2 create server....
There's no need to use quotes around the wrapper name, just let it fold, otherwise quotes are just annoying redundant noise, although it is not a mistake.
Inside the script for create server command options instead of AUTHORIZATION "xyz" PASSWORD "xyz" use AUTHORIZATION \"xyz\" PASSWORD \"xyz\" (i.e. escape the quotes).
For one-sided trust, use SSL_SERVERCERTIFICATE in the create server options clause and ensure the value is accurate (fully qualified path to the remote-db2instance-certificate-file), and that the file/directory permissions are valid.
For mutual trusts, use both SSL_KEYSTORE and SSL_KEYSTASH keywords with correct values, in the create server options clause (having previously ensured your keystores are properly populated, as verified by a command-line connect above).
You may also want to consider create user mapping depending on the requirements.
Finally you can create your nicknames, and test out the federated link by querying those nicknames.
I need to use MySQL to send queries to a Google Cloud SQL database set up. I already have an instance created and a user, and I am able to access the database through the Cloud Shell. I can't seem to find the credentials to log into the database (host name, username, password, port and socket), and I'm not sure how to access them through the shell.
You can find the available methods to connect to your Cloud SQL instance here.
Connecting from an IP address without SSL is probably the easiest one:
In the Cloud Console, go to the cloud SQL instances screen and click on your instance’s name.
In the overview tab, take note of the Primary IP Address, you’ll use it instead of a hostname.
In the users tab, you can create a new user or reset the password of an existente one, including the root user.
In the authorization tab, add the ip or ip range where you are attempting the connection from, so Cloud SQL accept connections from your client (more on this here).
Start your mysql client as follows (note the port is not necessary as the default one is used):
mysql --host=[INSTANCE_IP_ADDR] --user=[USER_NAME] --password
I can't seem to connect to Cloud SQL with Workbench. I keep getting this error.
Failed to Connect to MySQL at CLOUD-SQL-IPv4:3306 with user root
Access denied for use 'root'#'WHITE-LISTED-IP-ADDRESS' (using password: YES)
I have white listed my IP.
I have set an IP for the SQL instance.
I have checked the username and Password several times.
Any idea why this is happening?
It seems you have to create a new user in the Google Cloud Console with the host name set to %(any host). You can't seem to connect using the root user.
Is it possible to connect with the #root user but after you finish the setup you have to restart the sql server.
What is important to set up an SSL certificate if you connect to you production database, but if you only try it out you can allow unsecured connection. Another important thing is to add your IP to the Authorised Networks in the Connection tab.
After installing the standard Tryton packages in Ubuntu 12.04, I can start the client and create a new database. But the client refuses to connect to the database. It will display the locally created databases, but will fail to add the localhost profile.
If I try to add a new profile, the client will show the installed databases, but on clicking ok will fail silently back to the start screen, without adding the new profile.
New profile setting was:
Hostname: localhost
Port: 8000
Database: [Correctly displays the list of created Dbs]
Username: [I've tried everything from tryton, admin, test to root]
I have also tried to connect directly in the Tryton client without adding a new profile, then it will always yield "Bad user or password", no matter how exact I re-enter the tryton user with his password, or any other user (admin, root) for that matter.
I have followed the procedure in the documentation (Readme.debian: adding database user in /etc/trytond.conf and so forth, have registered tryton user with postgres and in trytond.conf).
Do I need to be logged in as tryton on Remote Desktop maybe?
The client was started on the Ubuntu desktop via Remote Desktop, logged in as root.
Tried to log in as tryton, too. That will get to the desktop, but somehow not show the Terminal window. Hence I can't start the Tryton client. Terminal will blink for a second and then vanish.
When you create a dabatase from the tryton client it ask you the admin password. You must enter with the 'admin' username and with the admin password you used on the database creation step.
Once you enter the system you will see and step to create additional User. You can skip it if you want, as they can be created at any time from Administration -> Users -> Users menú.
You must never use the passwords entered on etc/trytond.conf as this credentials are used from the tryton server to conect to the database. User logins are managed by tryton server.