``
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
Related
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.
I want to connect my AWX instance via LDAPs to our MS AD, but where/and how to install the CA root-trusted certificate?
Furthermore, I want to grant a login only from users of a certain group (memberOf), where I do not know how to deposit this attribute
If you're running your AWX instance in docker.
Install the certificates on your machine where you're running docker on. During the installation provide the path to root certs (inventory file in installer dir):
ca_trust_dir=/etc/pki/ca-trust/source/anchors
If you have AWX already installed and don't want to re-deploy - install certificates to awx_web and awx_task containers.
Copy cert and go to the container, e.g.
docker cp cert.crt awx_task:/etc/pki/ca-trust/source/anchors/your_org.crt
docker exec -it awx_task /bin/bash
Finally install the cert:
update-ca-trust enable
update-ca-trust extract
Repeat for the second container (awx_web)
I want to check my supervisord status by nagios.I haven 2 servers 1 nagios and other is client server.In my client server supervisor is running.
I have put my check_supervisord.py file in my /usr/local/nagios/libexec path & on my services.cfg file:
define service {
use generic-service
host_name ubuntuserver
service_description supervisord
check_command check_supervisord!80!hduser!password
}
But it showing me plugin missing error,
Since your other plugins are successfully running I would guess this is a permission issue.
cd /usr/local/nagios/libexec
chmod 755 check_supervisord.py
chown root:nagios check_supervisord.py
Try that and see if the plugin works. If this doesn't work try and see what permissions supervisord needs to run in a script or compare the script permissions to the other plugins that are working on your system.
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.
We are trying to bind a Linux machine (debian 4.0) to W2k3 AD. We have configured kerberos properly so that we can get TGTs. And users authenticate properly. However, PAM seems to be the sticky wicket. For example when we try to SSH to the linux machine as one of the AD users, the authentication succeeds (as per the auth.log) but I never get shell. The default environment is configured properly and PAM even creates the Homedir properly. As a reference we were loosely following:
https://help.ubuntu.com/community/ActiveDirectoryHowto
If you're confident everything but PAM works correctly, I suggest passing the debug option to pam_krb5.so to see if that gives a clue to what's happening.
I'd also suggest verifying that nss-ldap is set up correctly using
getent passwd avalidusername
I have used Likewise to do something similar on our servers. Here is the process we use to configure it:
Install Likewise:
$ sudo apt-get update
$ sudo apt-get install likewise-open
Join the domain (Assuming the domain "domain.local")
$ sudo domainjoin-cli join domain.local Administrator
$ sudo update-rc.d likewise-open defaults
$ sudo /etc/init.d/likewise-open start
Assuming you are using sudo AND want AD users to be able to have sudoer powers, you need to edit the sudoers file. This can be done with following command:
$ sudo visudo
then add the following to the end of the file (this assumes the domain "DOMAIN" and all the users that should have sudo are in a group called "linux_admin" in active directory):
%DOMAIN\\linux_admin ALL=(ALL) ALL
POSIX accounts demand that you have a vaild shell set in the user account. When using LDAP, this is referenced by the attribute loginShell. You need to use PAM and map an appropriate attribute to loginShell in your configuration, or active MS services for UNIX on the DC, which will extend the AD schema to include the needed POSIX attributes.
See http://www.ietf.org/rfc/rfc2307.txt as a reference to RFC2307, which defines this for LDAP.
A simple solution.. pam_krb5+ldap project
A fork of the pam_krb5 PAM module that provides a very easy to use configuration for utilizing linux client authentication against and existing Active directory domain and/or OpenLDAP server.