Sự cố khi thêm CentOS EC2 vào Windows AD

Tôi đang cố thêm máy CentOS EC2 của mình vào Windows AD. Windows Active Directory của tôi được định cấu hình trên Phiên bản EC2 trong một tài khoản khác. Có hai Phiên bản AD (Multi-AZ) được cấu hình và sao chép, v.v. được cấu hình bởi Quản trị viên AD trên Máy chủ. Anh ấy đã tạo Người dùng cho tôi và chia sẻ thông tin đăng nhập với tôi. Tôi đã thực hiện các bước sau theo cái này Tài liệu AWS để thêm máy CentOS EC2 vào Windows AD.

Tuy nhiên, tôi đang liệt kê các bước mà tôi đã thực hiện trên Máy chủ của mình.

• Sudo yum -y cập nhật
• con mèo/etc/tên máy chủ Đầu ra: ip-1-7-2-6.xyz.local
• sudo yum -y cài đặt sssd realme krb5-máy trạm samba-common-tools
• tham gia vương quốc sudo -U [email protected] XYZ.local --verbose
  Lệnh trên đã cho tôi lỗi:
  * Đang giải quyết: _ldap._tcp.xyz.local
* Đang giải quyết: xyz.local
* Không có kết quả: xyz.local
cõi: Không tìm thấy cõi như vậy

Vì vậy, tôi đã thực hiện các mục sau đây trong sudo vi /etc/hosts như đã đề cập trong cái này liên kết. Hai IP trên là của Máy chủ AD của tôi

Tôi cũng đã thực hiện các thay đổi đối với /etc/resolv.conf như sau :

Sau đó, tôi đã sử dụng vương quốc sudo khám phá XYZ.local lệnh để kiểm tra nếu vương quốc có thể khám phá miền:

Tôi có thể xem chi tiết. Sau này, khi tôi cố gắng tham gia lại miền, nó báo lỗi sau:

vương quốc: Không thể tham gia vương quốc: Các gói cần thiết chưa được cài đặt: Oddjob, Oddjob-mkhomedir, sssd, adcli

Vì vậy, tôi cũng đã cài đặt các gói trên. Tôi đã thử lại một lần nữa và lần này lỗi đã đổi thành:

Lỗi :
! Không thể nhận vé kerberos cho: [email protected]: Không thể tìm thấy KDC cho vương quốc "XYZ.local"
adcli: không thể kết nối với miền XYZ.local: Không thể nhận vé kerberos cho: [email protected]: Không thể tìm thấy KDC cho vương quốc "XYZ.local"
 ! Không thể tham gia miền
lĩnh vực: Không thể tham gia lĩnh vực: Không thể tham gia miền

Tôi đã tìm ra giải pháp cho vấn đề trên cái này link và thực hiện lệnh một lần nữa. Lần này là thành công. Đây là đầu ra:

đầu ra cho danh sách cõi:

tôi đã thử Tôi lệnh xác minh uid và gid của người dùng id người dùng-shivkumar, nhưng điều này không thành công với tin nhắn không có người dùng như vậy.

Tôi vẫn tiếp tục với tài liệu AWS để hoàn thành tất cả các bước và sau đó kiểm tra chéo.
sudo vi /etc/ssh/sshd_config
Xác thực mật khẩu có
Sudo systemctl khởi động lại sshd.service
khởi động lại dịch vụ sudo sshd
sudo visudo
## Thêm nhóm "Quản trị viên được ủy quyền của AWS" từ miền example.com. %AWS\ Delegated\ [email protected] ALL=(ALL:ALL) ALL

Dưới đây là các chi tiết của tôi /etc/sssd/sssd.conf

Tôi vẫn không thể truy cập Phiên bản EC2 bằng thông tin đăng nhập AD. Nó nói rằng Truy cập bị từ chối.

Tôi không thể hiểu những cấu hình nào khác cần được thực hiện?

Điều này luôn luôn đau đớn mỗi khi tôi thử nó! Tôi cuối cùng đào ra trang RedHat vì chúng thường là thông tin chính xác nhất.

Chỉ vì bạn đã chạy vương quốc lệnh, không có nghĩa là PAM được thiết lập chính xác để sử dụng AD làm nguồn nhận dạng để xác định người dùng. Vẫn còn nhiều việc phải làm tôi tin sau khi chạy vương quốc tham gia chỉ huy.

Tôi nghĩ bạn muốn xem xét việc thiết lập sssd sử dụng thông tin trên những trang này?

Đôi khi tôi cũng gặp may mắn hơn (dễ dàng hơn) khi sử dụng quảng cáo.

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:

• https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_linux_instance.html
• https://www.linuxtechi.com/integrate-rhel7-centos7-windows-active-directory/
• https://aws.nz/best-practice/ad-join/
• https://techdirectarchive.com/2020/03/21/cannot-find-kdc-for-realm-while-getting-initial-credentials-kinit-configuration-file-does-not-specify-default-realm/
• https://access.redhat.com/articles/3023951
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/windows_integration_guide/index#sssd-ad-proc
• http://www.techpository.com/linux-kinit-cannot-contact-any-kdc-for-realm-while-getting-initial-credentials/#:~:text=February%209-,Linux%3A%20kinit%3A%20Cannot%20contact%20any%20KDC%20for,realm%20while%20getting%20initial%20credentials&text=There%20is%20probably%20one%20of,not%20resolving%20the%20domain%20controller.
• https://unix.stackexchange.com/questions/464648/sssd-and-active-directory-user-does-not-exist-in-centos