Puncte:1

Probleme la adăugarea CentOS EC2 la Windows AD

drapel cn

Încerc să adaug mașina mea CentOS EC2 la Windows AD. Directorul meu Windows Active este configurat pe Instanța EC2 într-un alt cont. Există două instanțe AD (Multi-AZ) care sunt configurate și replicarea etc. este configurată de administratorul AD pe servere. Mi-a creat un utilizator și mi-a împărtășit datele de acreditare. Am efectuat următorii pași conform acest Documentația AWS pentru a adăuga mașina CentOS EC2 la Windows AD.

Totuși, enumerez pașii pe care i-am executat pe serverul meu.

  • sudo yum -y actualizare
  • cat /etc/hostname Ieșire: ip-1-7-2-6.xyz.local
  • sudo yum -y instalează sssd realmd krb5-workstation samba-common-tools
  • sudo realm join -U [email protected] XYZ.local --verbose
    Comanda de mai sus mi-a dat o eroare:
    * Rezolvare: _ldap._tcp.xyz.local
    * Rezolvare: xyz.local
    * Niciun rezultat: xyz.local
    tărâm: Nu s-a găsit un astfel de tărâm

Așa că am făcut următoarele intrări în sudo vi /etc/hosts după cum este menționat în acest legătură. gazdă Cele două IP-uri de mai sus sunt ale serverelor mele AD

Am facut si modificari la /etc/resolv.conf după cum urmează : introduceți descrierea imaginii aici

Apoi am folosit sudo realm descoperă XYZ.local comanda pentru a verifica dacă tărâm este capabil să descopere domeniul:

introduceți descrierea imaginii aici

Pot vedea detaliile. După aceasta, când am încercat din nou să mă alătur domeniului, mi-a dat următoarea eroare:

realm: Nu s-a putut alătura realm: Pachetele necesare nu sunt instalate: oddjob, oddjob-mkhomedir, sssd, adcli

Așa că am instalat și pachetele de mai sus. Am încercat încă o dată și de această dată eroarea s-a schimbat în:

Eroare:
! Nu s-a putut obține biletul Kerberos pentru: [email protected]: Nu s-a găsit KDC pentru domeniul „XYZ.local”
adcli: nu s-a putut conecta la domeniul XYZ.local: nu s-a putut obține biletul Kerberos pentru: [email protected]: nu s-a găsit KDC pentru domeniul „XYZ.local”
 ! Nu s-a putut alătura domeniului
realm: Nu s-a putut alătura domeniului: Nu s-a putut alătura domeniului

Am găsit o soluție la problema de mai sus acest link și a executat comanda încă o dată. De data aceasta are succes. Iată rezultatul: introduceți descrierea imaginii aici

Ieșire pentru lista de tărâmuri:

introduceți descrierea imaginii aici

am incercat id comanda pentru a verifica uid-ul și gid-ul utilizatorului id user-shivkumar, dar acest lucru nu a reușit cu mesajul Nu există un astfel de utilizator.

Totuși, am continuat cu documentul AWS pentru a finaliza toți pașii și apoi verificați încrucișați.
sudo vi /etc/ssh/sshd_config
Autentificare prin parolă da
sudo systemctl reporniți sshd.service
sudo service sshd restart
sudo visudo
## Adăugați grupul „AWS Delegated Administrators” din domeniul example.com. %AWS\ Delegated\ [email protected] ALL=(ALL:ALL) ALL

Iată detaliile mele /etc/sssd/sssd.conf
introduceți descrierea imaginii aici

Totuși, nu pot accesa instanța EC2 folosind acreditările AD. Se spune Acces interzis.

Nu reușesc să înțeleg ce alte configurații trebuie făcute?

Puncte:1
drapel cn

Acest lucru a fost întotdeauna dureros de fiecare dată când l-am încercat! Am sfârşit prin a săpa Pagini RedHat deoarece acestea sunt adesea cele mai precise informații.

Doar pentru că ai condus tărâm comanda, nu înseamnă că PAM este configurat corect pentru a utiliza AD ca sursă de identitate pentru a identifica utilizatorii. Cred că mai sunt încă de făcut după rularea alăturarea tărâmului comanda.

Cred că vrei să te uiți la amenajări sssd folosind informațiile de pe paginile astea?

De asemenea, uneori am avut mai mult noroc (mai ușor) folosind adcli.

Shivkumar Mallesappa avatar
drapel cn
Singurul lucru pe care l-am găsit diferit este `ldap_id_mapping = false`, așa că m-am alăturat domeniului folosind `realm --verbose join --user=user-shivkumar XYZ.local --automatic-id-mapping=no`. De data aceasta sub `/etc/sssd/sssd.conf` `ldap_id_mapping = false`, dar tot atunci când fac `id [email protected]` arată același mesaj
Puncte:0
drapel cn

Finally, I was able to add my CentOS EC2 Machine to Windows AD. The root cause was the time zone. My CentOS machine timezone was in UTC whereas the AD Server timezone is in IST. Unfortunately none of the blogs which I referred given the detailed steps from start.

Still to complete the answer I am posting all of the steps which I have performed on my machine.

  • sudo yum -y update To update the packages and system
  • ping X.X.X.X This is a very important step in order to check if you can reach your AD Server. I have executed ping on both of my servers to check they are reachable
  • sudo timedatectl set-timezone Asia/Kolkata As I mentioned above this is the root cause in my case, the timezone. Make sure the timezone are the same on your machine and the AD machine.
  • date to check the current time and verify the above command is executed successfully
  • sudo yum -y install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python Install the necessary packages for realm
  • Edit the /etc/hosts file as follows (replace your AD Server IP):
    sudo vi /etc/hosts
    X.X.X.X xyz.local MYAD
    X.X.X.X xyz.local MYAD
  • cat /etc/hosts Recheck the host entires
  • Edit the /etc/resolv.conf file as follows (replace your AD IP): Comment out the existing nameserver entry and add the following entries (replace your AD Server IP)
    nameserver X.X.X.X
    nameserver X.X.X.X
  • nslookup xyz.local To test the name resolution for your domain controller. Authentication Services relies on DNS (Domain Naming Service) to locate the Key Distributions Center (KDC) which in AD is a domain controller, so if your DNS is not properly configured for your domain it will fail.

If everything is correct till the above step you should be able to see the output from nslookup. You are almost set to add your machine to AD.

  • kinit -V [email protected] Test login to the domain. Typically if you are a member of the Domain Administrators group you should be fine. If not ask the AD admins to give you the privilege to join machines to the domain. In my case user-shivkumar has the privilege to join machine to domain. Once you execute this command, it will ask you for the password. If everything is fine you should be able to see Authenticated to Kerberos v5 message or it will show no message and return to the terminal. This means your domain credentials are working for log in. This step will fail if the DNS is not correctly configured or resolvable or if the network connectivity to the ADC is broken. You may see some messages like kinit: Cannot find KDC for realm "XYZ.LOCAL" while getting initial credentials. The other reason for the error might be incorrect username. Also, pay attention to the domain name. It is in capital. The kinit command fails for user authentication because Kerberos is case-sensitive.Here is the right syntax kinit [email protected]. Ensure the domain name is in all CAPS, or else you will get an error.
  • sudo realm join -U [email protected] xyz.local --verbose Add machine to domain. If everything is correct you will see the message Successfully enrolled machine in realm
  • sudo realm list This command will help you to verify whether the server has joined the Windows domain or not
  • id [email protected] With id command on Linux we can verify the user’s uid and gid and their group information. At this point in time, our server is now the part of the Windows domain. Use the id command to verify AD users details. Once you get the output for id command then this means everything is correctly configured.

Now the last thing, set the SSH service to allow password authentication.

  • sudo vi /etc/ssh/sshd_config Open this file to enable password authentication
  • PasswordAuthentication yes Set the PasswordAuthentication setting to yes.
  • sudo systemctl restart sshd.service Restart the SSH service. You can also use the alternate command
  • sudo service sshd restart to restart the SSH service.

Now ideally you should be able to login into the machine using your domain credentials. In my case, I am able to log in using [email protected] credentials.

I hope this will help someone.
Happy learning.

References:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.