Shake a Leg

Adding Clients

Before you add a client to AD, you need to verify that its DNS configuration points to the DC server. This example deploys Windows 10 Enterprise and Windows Server 2022. Windows 10 Enterprise version 21H2 does not have the Join a domain button that previous Windows versions had in system Settings. You need to work your way through the following menus in Windows: Start | Settings | System | About | Rename this PC (advanced) . In the System Properties dialog, press Change and enter the name of your domain in the Member of Domain box. Now Windows asks for a user with the domain join permission. Simply enter Administrator with the appropriate password and the system will become part of the domain. After restarting, you can log in to the Windows client as one of the previously created users.

If you want to use the GUI tools for AD administration on this Windows client, you can download them from Microsoft [1]. Windows Server 2022 provides the appropriate tools. The DS-Client setup works in a similarly simple way on Linux systems. Different Kerberos versions for the clients have no compatibility issues as long as they use AD for login verification and do not run a local Samba service. EL and Fedora systems can join the domain just like Debian systems. On a Fedora 36 workstation, the first step is to install the necessary packages:

dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools -y

If needed, adjust the DNS configuration in systemd-resolved as described previously. Make sure the configuration is correct and the Fedora client can contact the DC:

realm discover <Domain-Name>

If you do not get an error message here, add the Linux client to the domain:

realm join <Domain-Name> -v

The -v switch prints all the details of the operation on the CLI. At the end of the process, Successfully enrolled machine in realm confirms joining the domain. Now you can log in to the Linux GUI or CLI as with a domain user.

Adding a Second DC

Of course, one DC should not manage a network alone, so you need to add at least one more DC. It is also considered best practice for DCs not to provide file shares but devote themselves to their tasks as domain controllers. Regular domain member servers without DC functions then host the filesystem shares – but more on this later. Setting up additional AD servers follows the same pattern as for the AD: Set up the packages, delete smb.conf, check the DNS configuration, and adjust if necessary. On another DC server, run the Samba tool:

samba-tool domain join <domain-name> DC -U"Administrator@<domain-name>"

The tool will then prompt you for the admin password and perform the AD setup. Afterward, disable and comment out the regular Samba services as on the first DC, enable the samba-ad-dc service instead, and apply the Kerberos configuration.

Becoming a Domain Member

If you specify

samba-tool domain join <Domain Name> MEMBER

instead of DC, the system only joins the domain as a member and not as a domain controller. However, this does not always work flawlessly or with all distributions. The somewhat more complex way, which also works with other distributions such as Fedora or EL, uses a manual configuration.

The setup of a member server differs from the client setup described above. For a client, you just need the System Security Services Daemon (SSSD) with Kerberos. The member on the other side connects to the domain with Samba's Winbind service without needing SSSD. On the EL8 system (e.g., RHEL  8, Alma or Rocky Linux, CentOS Stream  8), which I use as a domain member, the necessary services need to be set up first:

dnf install samba samba-client samba-winbind samba-winbind-clients oddjob oddjob-mkhomedir

Adjust the smb.conf configuration for the member server (Listing 1). Doing so specifies that Winbind uses ADS to query the users.

[global]
  realm = <ADS Realm>
  security = ADS
  template shell = /bin/bash
  winbind enum groups = Yes
  winbind enum users = Yes
  winbind offline logon = Yes
  winbind use default domain = Yes
  workgroup = <AD Workgroup Name>
  idmap config * : rangesize = 1000000
  idmap config * : range = 100000-19999999
  idmap config * : backend = autorid
...

To ensure that the local system also uses Windbind to determine users and their IDs, you also need to modify the /etc/nsswitch.conf file. The entries for passwd and group should look something like:

passwd         compat winbind
group          compat winbind

The Linux system will then first search the local passwd and group files for users and groups, along with their IDs. If it doesn't find anything there, it fetches the information from the domain via Winbind. In an AD client setup, for example, sssd is displayed here instead of winbind. Now you can register the member server as a member of the domain with

net ads join -U Administrator

and start the winbind and smb services. You might get an error message stating that DNS registration did not work, but this response is not a big deal. Just enter the server manually in the ADS-integrated DNS. After that, you can share folders on the member server and make them available as shares in the ADS forest.