Adding a Linux Host to an Active Directory Domain

Blog >Adding a Linux Host to an Active Directory Domain

The Linux operating system has come a long way since 1991 when it was first introduced by Linux Torvalds as a free operating system.  Today, some form of Linux is used in devices ranging from high-end servers to IoT devices. More often than not, common database platforms such as Oracle, PostgreSQL, MySQL, and MongoDB, are deployed on servers running Linux.  One notable exception was the Microsoft SQL Server.  That changed recently after Microsoft announced support for Linux starting with SQL Server 2017.  Unlike the Windows hosts, Microsoft does not provide a straightforward way to integrate Linux hosts into Active Directory, making it harder to manage them.

In this blog, I will walk you through the steps of integrating a Linux host running on CentOS 8 into a Windows Active Directory (AD) domain configured on Windows 2012 R2 Server Standard Edition.  The reason I specify the versions and types of the Linux distribution and the Windows AD Domain Controller is because there are subtle differences between versions of Linux and Windows that you must be aware of.  For example, in CentOS/RHEL 8, Network Time Protocol (NTP) client and server activities were managed using the ntp daemon.  In CentOS/RHEL 8, it has been replaced with chrony daemon.

Step 1) Ensure that the hostname along with the fully qualified domain name (FQDN) is specified in the /etc/hosts file. The hostname cannot be localhost as it is mapped to the loop-back adapter  If you need to change the existing hostname, use the following command to change it to the desired name.  There is no need to specify the FQDN as part of the hostname.

[root@oldhostname ~]# hostnamectl set-hostname <new_host_name>
[root@newhostname~]# echo sblinmssql2019 >> /etc/hosts

Step 2) Specify the AD domain controller in the /etc/hosts file using the following command.

 [root@newhostname~]# echo 192.168.xx.x sbad >> /etc/hosts
[root@newhostname~]# ping

Step 3) Ping the AD domain controller that was specified in Step 2 and ensure that you get a ping response.

Step 4) The DNS server needs to be pointed to the AD domain controller, at least in my case, as my domain controller is also the DNS server for my domain,

Step 5) If the primary domain controller that you are planning to use as the NTP server does not have the NTP server configured, follow the steps in the screenshot to configure and enable the NTP sever on the primary domain controller prior to proceeding to Step 6.

Step 6) The Linux host needs to synchronize time with one of the domain controllers that is part of the AD domain.  In my case, there is only one domain controller and the Linux host will be synchronizing the time with the only domain controller in my AD domain. Install chrony if it is not already installed and configure it to use the domain controller to synchronize the time. It may already be installed, resulting in a message reporting a preexisting installation.

 [root@newhostname~]# vi /etc/resolv.conf
[root@newhostname~]# systemctl restart NetworkManager
  [root@sblinmssql2019~]# vi /etc/chrony.conf
  [root@sblinmssql2019~]# systemctl enable chronyd
  [root@sblinmssql2019~]# systemctl restart chronyd
  [root@sblinmssql2019~]# systemctl enable chronyd

If it is already installed, we need to edit the chrony.conf file and set the time server to the AD domain controller and restart the chronyd service. If it was not preinstalled, enable the service to startup on reboot and ensure that firewall is configured to allow NTP traffic after ensuring the successful installation.

Once chronyd is configured and enabled, the timedatectl command will show if the NTP service is active.  After confirming that NTP service is active, run the chronyc sources command to ensure that it is using the domain controllers as the time server as shown below.

Step 7) Next the samba suite including winbind needs to be installed on the Linux host. The winbind service enables the Linux host to interact with AD domain like a Windows host.  After the installation is complete ensure the packages shown in the screenshot below are installed.

Step 8) Next modify the /etc/samba/smb.conf file to reflect the realm value to the fully qualified domain name and also the workgroup value to the name of the domain as shown in the screenshot below.

[root@sblinmssql2019~]# yum -y install samba samba-client
[root@sblinmssql2019~]# yum -y install samba-winbind samba-winbind-clients

Step 9) Enable winbind daemon on system reboot using the systemctl command as shown in the screenshot below.  Please note that there is no reason to reboot the Linux host, unlike Windows hosts.

NOTE –  The realm parameter is the name of your domain, in my case it is and the workgroup parameter is set to sbits.  It can also be set to Windows default WORKGROUP if you prefer.  The security = ADS designates that this host is part of the AD domain.  The winbind separator =+ specifies that the + will be used to separate the domain name and username.  The traditional Windows separator \ is not compatible with Linux and an escape character has to be used every time a username is specified with the domain prefix. 

Step 10) Install the Kerberos package using yum as in the below command:

[root@sblinmssql2019~]# yum -y install krb5-workstation

Step 11) Now, add the Linux host to the AD domain using the command below.  It is highly likely that you will get the DNS update failed: NT_STATUS_INVALID_PARAMETER error.  In my case even though I got the error, the Linux host was added to the AD domain.  I reissued the command with the –no-dns-updates flag and the error did not pop-up.

Step 12) If you do not want to encounter the error and would like to have the DNS update the information about the new Linux hosts, change the security setting using DNS Manager as shown in the screenshot below.

Step 13) On the primary domain controller, verify that the Linux computer object was added using the Active Directory Users and Computers tool.

Step 14) Ensure that the winbind service is running on the Linux host.

Step 15) Let us validate that the Linux host is actually part of the AD domain and is able to communicate with the domain controller by running a couple of validation commands as follows.  We will use the wbinfo package to run encrypted RPC calls to the domain controller.

[root@sblinmssql2019~]# wbinfo -t    # verifies if encrypted RPC are supported
[root@sblinmssql2019~]# wbinfo – u  # enumerates AD the list of users
[root@sblinmssql2019~]# wbinfo – g  # enumerates AD the list of groups

Step 16) Next, we need to ensure that winbind is selected as the authorization provider by using the authselect select winbind –force command as shown in the screenshot below.  The –force flag will overwrite the entries in the /etc/nsswitch. conf  file.

Step 17) To ensure that Linux will winbind for user authentication prior to local Linux authentication make sure the passwd and group entries are listed to use winbind in the /etc/nsswitch.conf  file.

Step 18) Finally, let us try to get Kerberos Ticket Granting Ticket (TGT) using kinit.

[root@sblinmssql2019~]# wbinfo -t    # kinit
[root@sblinmssql2019~]# wbinfo – u  # klist

Chances are you will encounter the kinit error shown in the screenshot above.  If you do encounter it, edit the /etc/krb5.conf  file and change the setting as shown in the screenshot below.

Once the file is modified, there is no reason to start any services on the Linux host and the ticket request should work fine.

You can verify it on the AD domain controller as well as shown in the screenshot below.

That was the final step in adding a Linux host to a Windows AD domain.  Stay tuned for my next blog, where I will be installing SQL Server 2019 for Linux on the same host and setup SQL Server Mixed Authentication mode.

Active Directory literally holds the keys to the kingdom, while it makes perfect sense to add Linux hosts to an AD domain, one need to mindful of the security aspect of doing so.  StealthAUDIT is an AD auditing and reporting tool that can help address any vulnerabilities, misconfiguration and excessive permissions related to AD joined computer objects.  To learn more about how StealthAUDIT can help in effectively managing and securing Active Directory at all levels to mitigate the risks of advanced attacks, compliance failure, and operational outage please visit our website at:

Leave a Reply

Your email address will not be published. Required fields are marked *





© 2020 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.