Trying to configure TLS on my MSSQL connections following this article: https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-encrypted-connections?view=sql-server-2017
The server-side configuration seems pretty straight-forward with minor differences in the container environment (e.g. systemctl doesn't exist so I kill/respawn pod):
systemctl stop mssql-server
cat /var/opt/mssql/mssql.conf
/opt/mssql/bin/mssql-conf set network.tlscert /var/opt/mssql/ssl/mssql.pem
/opt/mssql/bin/mssql-conf set network.tlskey /var/opt/mssql/ssl/mssqlprivkey.key
/opt/mssql/bin/mssql-conf set network.tlsprotocols 1.2
/opt/mssql/bin/mssql-conf set network.forceencryption 0
systemctl start mssql-server
So I took my PFX from my Windows CA and extracted the key and the client cert to key and pem files, added them to the location for persistent storage (/var/opt), ran the commands (seen above) and sql came back up.
I installed mssql-tools on a different machine and configured it in the trust-anchors to trust my CA.
However, when trying to test the connection (sqlcmd -N -S tcp:1.1.1.1,1433 -U user -P password), I get the error: SSL Provider: [error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:subject name does not match host name]
When I change the connection string to the DNS name, it works (sqlcmd -N -S tcp:mssql.mydomain.com,1433 -U user -P password) -- even though the IP address is listed as a subject alternative name on the cert.
Why are secure connections not working using the IP? What am I missing?
Different TLS client tools differently handle IP Address Subject Alternative Name type. Most Microsoft tools ignore iPAddress name type completely and require IP addresses to be listed as dNSName name type. Try to add IP Address to SAN extension as dNSName name type, it should work.
Related
``
Hello
I am migrating an Ubuntu Bionic 18.4 Linux server to a windows domain
I followed the steps below:
1- update packages first.
2- install the required packages.
sudo apt -y install realmd sssd sssd-tools sssd-ad libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
sudo apt-get install -y krb5-user sssd-krb5
pam ????
3- Server Network config
create file 99_config.yaml (/etc/netplan/99_config.yaml)
configure IP , DNS server and domain
Change server hostname to a fully qualified domain name
sudo hostnamectl set-hostname serverName.mydomain
change /etc/hosts
add or update line 127.0.0.1 serverName.mydomain
apply change : sudo netplan apply
4- Discover the domain
realm discover mydomain (work fine)
5- Keberos config
REALM (EN MAJUSCULE)= mydomain
kdc = my domaine Active Directory Server IP
admin_server = my domaine Active Directory Server Name
6- Join ubuntu server to the domain
realm join MyNameServerIP mamadi.fofana (work fine)
7- Modify pam to automatically create a home directory for AD users
pam-auth-update
Check “activate mkhomedir”.
8- Test to see if the integration is working correctlyPermalink
id myuserName#myDomain
getent myuserName#myDomain
groups myuserName#myDomain
All those 3 above commands work fine
9- Admin config
Update sudoers file to include your domain administrators security group with full sudo access:
sudo nano /etc/sudoers.d/admins
Add the necessary lines to it. For example:
user ALL=(ALL) ALL
%Domain\ Admins ALL=(ALL) ALL
To avoid adding the domain name to the username every time, configure this.
sudo nano /etc/sssd/sssd.conf
Change the ‘use_fully_qualified_names’ value to False.
Restart and check:
sudo systemctl restart sssd
allow authorization for some AD users or groups
sudo realm permit myUserName#myDomain, someUserName#myDomain
sudo realm permit -g 'Domain Admins'
Login using SSH via another terminal:
ssh -l myuserName#myDomain MyUbuntuServerIP
At first it worked; several domain users managed to connect with ssh , fileZilla and directly on the server
with their domain credential.
The only concern was that the resolution didn't work with the ubuntu server name; we used the IP address
To fix the name resolution problem, I had to install and configure samba and nmbd
Suddenly after a few days, I couldn't connect to the server with the domain accounts
with SSH I have the message
Connection closed by ServerIP port 22
directly on the server
i have the message
Sorry that didn't work, please try again
I am however sure of the password, and other users have failed to connect
Do you have an idea of the origin of the problem or a way to debug to identify the source of the problem?
the migration worked at first, then stopped recognizing domain user passwords
I specify that although the users of the domain cannot connect,
the following commands still work and show correct outputs
realm discover mydomain (work fine)
id myuserName#myDomain
getent myuserName#myDomain
groups myuserName#myDomain
Please assist
8- Test to see if the integration is working correctlyPermalink
id myuserName#myDomain
getent myuserName#myDomain
groups myuserName#myDomain
All those 3 above commands work fine
I tried to connect to oracle db 11 in docker (https://hub.docker.com/r/sath89/oracle-xe-11g/).
Started docker with command:
docker run -d -p 8080:8080 -p 1521:1521 -e DEFAULT_SYS_PASS=sYs-p#ssw0rd sath89/oracle-xe-11g
From this description:
hostname: localhost
port: 1521
sid: xe
username: system
password: oracle
made an url - jdbc:oracle:thin:#192.168.99.100:1521:xe
With squirrel-sql have an error:
class java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-12705: Cannot access NLS data files or invalid environment specified
But if I try to connect with SQLplus thats ok:
docker exec -ti oracle_id sqlplus bash
sqlplus
The SquirrelSQL needs to have some NLS variables set before logging in. For the Docker connection, note that you have "bash" at the end of your command. This not only tells the connection that you'll be using bash shell, it sets up the environment to connect using the bash_rc, (and possibly a profile, too). You're coming from your local machine vs. an SSH, so the local machine is being used instead of the SSH.
I believe there is a squirrel-sql.bat file that could unset and then set the environment or better yet, let's just unset it in the registry and let the local connection take its course:
On your Windows maching:
Do a search for an NLS_LANG subkey in the registry: \HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE, rename it, save the change, reboot and retry.
I’m not familiar with Squirrel SQL, but you may also be missing a proper set up of the jar files. Look and see if your jar files are configured correctly, depending on your version, its going to look something like this:
%Oracle_\jdbc\lib\ojdbc.jar
I need to have additional instance for our production server.
Is it possible?
Where to begin?
Using Postgresql 9.1 on Windows Server
If you already have the binaries, then adding a second instance ("cluster") is done by running initdb and then registering that new instance as a Windows service.
(I will not prefix the name of the executables with the path they are stored in. You need to either add the bin directory of the Postgres installation to your system wide PATH, use fully qualified names, or simply change into the bin directory to make it the current directory)
To do that, open a command line (cmd.exe) and use initdb to create the instance:
initdb -D c:\Data\PostgresInstance2 -W -A md5
-W makes initdb prompt you for the name and password to be used as the superuser of that instance - make sure you remember the username and passwords you have given. -D specifies where the cluster should be created. Do NOT create that under c:\Program Files.
Once the instance (cluster) is initialized edit c:\Data\PostgresInstance2\postgresql.conf to use a different port, e.g. port = 5433. If the instance should be reachable from the outside you also need to adjust listen_addresses.
You can check if everything works by manually starting the new instance:
pg_ctl start -D c:\Data\PostgresInstance2
Once you have change the port (and adjusted other configuration parameters) you can create a Windows service for the new cluster:
pg_ctl register -N postgres2 -D c:\Data\PostgresInstance2
The service will execute with the "Local Network Account", so you have to make sure the privileges on the data directory are setup properly.
#NewSheriff
Your start command for your second server needs to use the port you specified in config
e.g. if using port 5433 instead of port 5432
then adding:
-o "-p 5433"
to the end of your start-up command should get past the error message you mentioned
I have started the pgpool using the command
sudo pgpool -n &
it started giving the following message on the terminal:
2012-05-04 10:54:29 LOG: pid 4109: pgpool-II successfully started. version 2.3.2.1 (tomiteboshi)
But when I try to run the following command:
createdb -p 9999 bench_replication
I get the following error message:
createdb: could not connect to database postgres: could not connect to server: No such file or directory.
Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.9999"?
When I change the port from 9999 to 5432, a database bench_replication is created on the local node only, not on slave nodes. But, tutorial say to mention port 9999 in this command in order to create database bench_replication on all slave nodes through pgpool.
To confirm whether pgpool is really running or not, I stop the pgpool using command
2012-05-04 10:58:50 LOG: pid 4109: received smart shutdown request
stop request sent to pgpool. waiting for termination...done.
[1]+ Done sudo -A pgpool -n
which confirms the pgpool was actually running. What am I doing wrong? I have changed all my pgpool configuration file as mentioned in the standard tutorials on net.
Try this command :
createdb -p 9999 -h 127.0.0.1 bench_replication
By default PostgreSQL try to use the socket.
Late response but useful for future generations:
When you run
createdb -p 9999 bench_replication
under root, this generates the following error in log:
no pg_hba.conf entry for host "12.34.56.78", user "root", database
"postgres", SSL off
This means you should explicit mention username just like this:
createdb -U postgres -p 9999 bench_replication
Then you will get another error:
no pg_hba.conf entry for host "12.34.56.78", user "postgres", database
"postgres", SSL off
So you were blocked by second node on HBA level.
In this case either you should allow on second node access from first (in pg_hba.conf):
host all postgres 12.34.56.77 trust
or you should set password:
createdb -U postgres -p 9999 bench_replication -W SoMeP4Ssw0rD
If this is not clear enough - just check for your logs.
I want to install postgresql for use as the backend to a Windows application.
This seems to be no problem if postgresql is not already installed on the system.
If postgresql is already installed then unless the command line parameters contain the superpassword etc of the existing installation then the install fails.
As I will likely never know the superpassword or other account details of any pre-existing postgresql instances and the machine owners may not either it seems that this will frustrate any attempt to install postgresql in such a situation.
I believe it is possible to install completely independent instances of sql server but is this possible for postgresql?
BTW:
If the command line does contain the correct superpassword then the install just seems to overwrite the existing install and ignores parameters like --prefix etc .
I used init db to create a new database cluster before doing a second install but this new cluster was ignored?
In general you can have multiple independent instances of PostgreSQL. Strictly speaking it's database cluster with separate:
data directory
configuration (e.g. postgresql.conf, pg_hba.conf)
listening TCP/UDP port (default 5432+)
owner user and superuser role
locale and default encoding
log file
postmaster server process (on Windows postgres.exe)
Perfect well-done example is Debian with easy to use postgresql-common infrastructure (pg_ctlcluster, pg_lsclusters, pg_createcluster, pg_dropcluster, included SSL, log rotation and so on).
EDIT:
I found it's rather easy to install second, third, etc. instance of same versioned PostgreSQL under Windows with EnterpriseDB's installer, no need to use initdb and pg_ctl (assuming 64-bit installation, probably you need to use Program Files (x86) for 32-bit installation):
Open cmd with admin privileges (Run as Administrator)
Execute: cd "C:\Program Files\PostgreSQL\9.0\installer\server"
Create new database cluster (press Enter on every step): initcluster.vbs postgres postgres 12345 "C:\Program Files\PostgreSQL\9.0" "C:\Program Files\PostgreSQL\9.0\data2" 5433 DEFAULT
Register as Windows Service: startupcfg.vbs 9.0 postgres 12345 "C:\Program Files\PostgreSQL\9.0" "C:\Program Files\PostgreSQL\9.0\data2" postgresql-x64-9.0-2
Run newly created service postgresql-x64-9.0-2 using services.msc and you have second server
Change 12345 to your password specified during PostgreSQL installation. You don't have to use data2 directory, use whatever you like (but of course not existing data directory).
On Windows 7 I had success following these steps. You'll need the PsExec.exe utility available in the Sysinternals Suite. I assume here that the path to the Sysinternals Suite and the path to the bin folder of your existing PostgreSQL installation are in your PATH environment variable.
Open a cmd.exe window and enter the following command to open a prompt as the Network Service account.
psexec -i -u "nt authority\network service" cmd.exe
The Network Service account won't have access to your PATH, so cd 'C:\PostgreSQL\9.3\bin' and then enter the following command to initialize a data directory for your new instance. I've called mine "data2". It doesn't have to be in the postgres directory, but that's where the default data directory goes, so it's a reasonable choice.
initdb "C:\PostgreSQL\9.3\data2"
Edit C:\PostgreSQL\9.3\data2\postgresql.conf so that port = 5433 (the default instance uses 5432, and you shouldn't have two instances on the same port)
Leave the Network Service cmd prompt and in your standard prompt enter the following command to register the new service. Here I've named my new instance "pg_test"
pg_ctl register -N pg_test -U "nt authority\network service" -D "C:\PostgreSQL\9.3\data2"
Run the following command to start the service.
net start pg_test
The database owner role will be 'YOURMACHINENAME$'. If you want to change this to the standard 'postgres', you have to first create a new super user role that can rename the owner. From the command prompt, enter the following to create this super user.
createuser -s -r -l -i -P -h localhost -p 5433 -U YOURMACHINENAME$ mysuperuser
Finally, connect to the server with psql (psql -U mysuperuser -h localhost -p 5433 postgres) and enter the following commands to rename your database owner and add a password.
ALTER USER "YOURMACHINENAME$" RENAME TO postgres;
ALTER USER postgres WITH PASSWORD 'yourpassword';
Something like this should work (if not it's probably bug):
postgresql-9.0.4-1-windows_x64.exe ^
--mode unattended ^
--prefix c:\postgres\9.0-second ^
--servicename postgresql-x64-9.0-second ^
--serviceaccount postgres2 ^
--servicepassword <password> ^
--serverport 5433 ^
--superaccount postgres ^
--superpassword <password>
EDIT: after a couple of tests I believe it's not possible to create different Postgres instances of the same version using the One-click installer. Sorry.
OTOH you could always play with initdb and pg_ctl and use the existing installation to create a new instance. It would not be as easy as just starting the installer but it's doable.