Issues while adding CentOS EC2 to Windows AD

I am trying to add my CentOS EC2 machine to Windows AD. My Windows Active Directory is configured on EC2 Instance in another account. There are two AD Instances (Multi-AZ) that are configured and replication etc is configured by the AD Administrator on the Servers. He has created a User for me and shared the credentials with me. I have performed the following steps according to this AWS Documentation to add the CentOS EC2 machine to Windows AD.

Still, I am listing down the steps which I have executed on my Server.

• sudo yum -y update
• cat /etc/hostname Output : ip-1-7-2-6.xyz.local
• sudo yum -y install sssd realmd krb5-workstation samba-common-tools
• sudo realm join -U [email protected] XYZ.local --verbose
  The above command gave me error:
  * Resolving: _ldap._tcp.xyz.local
* Resolving: xyz.local
* No results: xyz.local
realm: No such realm found

So I made the following entries in sudo vi /etc/hosts as mentioned in this link. The above two IP's are of my AD Servers

I also made changes to /etc/resolv.conf as follows :

Then I used the sudo realm discover XYZ.local command to check if realm is able to discover the domain:

I am able to see the details. After this when I again tried to join the domain it gave me following error:

realm: Couldn't join realm: Necessary packages are not installed: oddjob, oddjob-mkhomedir, sssd, adcli

So I Installed the above packages as well. I tried once again and this time error changed to :

Error :
! Couldn't get kerberos ticket for: [email protected]: Cannot find KDC for realm "XYZ.local"
adcli: couldn't connect to XYZ.local domain: Couldn't get kerberos ticket for: [email protected]: Cannot find KDC for realm "XYZ.local"
 ! Failed to join the domain
realm: Couldn't join realm: Failed to join the domain

I found a solution to the above problem over this link and executed the command once again. This time it is successful. Here is the output:

Output for realm list:

I tried id command to verify the user’s uid and gid id user-shivkumar, but this failed with message no such user.

Still I proceeded ahead with the AWS doc to complete all of the steps and then cross check.
sudo vi /etc/ssh/sshd_config
PasswordAuthentication yes
sudo systemctl restart sshd.service
sudo service sshd restart
sudo visudo
## Add the "AWS Delegated Administrators" group from the example.com domain. %AWS\ Delegated\ [email protected] ALL=(ALL:ALL) ALL

Here are the details of my /etc/sssd/sssd.conf

Still I am not able to access the EC2 Instance using AD credentials. It says Access Denied.

I am not able to understand what other configurations needs to be made?

This has always been painful every time I tried it! I end up digging out the RedHat pages as they're often the most accurate info.

Just because you've run the realm command, doesn't mean that PAM is set up correctly to use AD as an identity source to identify users. There's still more to do I believe after running the realm join command.

I think you want to look into setting up sssd using the info on these pages?

I've also sometimes had better (easier) luck using adcli.

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