Kent West
23 Feb 2021

Configure a Debian Box to:

1) Authenticate logins via Active Directory

2) Provide Samba file-shares

Configure Domain Authentication

You can use one of several methods (as I understand it currently) to add a Linux box to an Active Directory domain, so that AD users can log into the box:
1. sssd – this is the most recent, modern route. You will see recommendations to use this method, as it’s the new and coming way to do authentication. Problem is, file-sharing requires some winbind pieces, with which sssd is currently (Feb 2021) incompatible.
2. Winbind – previous route. If you’re going to have Samba file-sharing, for now at least, you probably want to stick with the older Winbind method.
3. You could also go an even earlier route, where you set things up all manually (not recommended), or you could go the commercial solution route (probably sweeter, but at a cost, being neither free nor Free).
Choose one method or the other a little further down in this document.

Initial Common Setup

Install a basic Debian setup.

For tinkering purposes, I used a VirtualBox setup, building a VM (named “tinkertoy”) with 4 GB of RAM and 20 GB of drive space, in one partition, booting from the most recent Debian netinstaller .iso
1. At the package-selection window, I unselected everything. (Note that I’m only keeping things simple to keep things simple; this is not necessary for the purposes of this document.)
2. I prefer aptitude to apt:
  
  apt install aptitude
3. The authentication mechanisms are finicky about the time matching between the server and the client, so we’ll need ntp, which was not installed automatically; install it:
  
  aptitude install ntp
You can manually configure either method mentioned above (sssd, Winbind), but I’ve been unable to find a good explanation for what’s needed where. Using the Redhad-created realmd utility is much easier, so let’s install it.
And to pull in all the utilities you need, the packagekit utility is good to have:
At this point, you have no /etc/samba directory, no /etc/sssd directory, no /etc/krb5.conf, no mods to /etc/nsswitch.conf, no winbind pieces installed, no Samba or samba-common or samba-common-bin pieces installed, but, you can begin to see the process coming together with this command:
which should give you about a dozen lines of information about the domain, including the fact that configured is set to no.
on the other hand, should return nothing, showing that you’re not joined to any domain.
If you ever need to leave a domain for any reason:
At this point, you can join the Debian box to the domain. There are probably several ways of doing this; what matters is not so much what the Debian box does, but simply telling the domain server about the Debian box. You could probably do this manually from the server side, but the easy way is to do it from the client, using the realm tool, which we’ll do below.

If this computer’s name is already in Active Directory (perhaps from previous attempts, or when this computer was a Windows box with the same name, etc), you’ll want to use your Windows Active Directory tools to first remove this computer name from the domain. Note also that when you add the computer to the domain, it’s likely to fall into the Default landing zone for your AD setup; you may want to later move it using the Active Directory tools to a different Organizational Unit, etc.

You may have noticed from the realm discover [domain] command above that several other packages are required for realm to work properly. We could manually aptitude install those, but the packagekit we installed earlier will watch for what’s needed by realm and install them on the fly as needed. (I have noticed that if you don’t install packagekit, when you try to use realm to join to the domain, it will fail and tell you not all the required packages it lists as required are installed, despite that fact that you may have them installed; it seems to be missing packagekit, without telling you. A bug.. uh, feature.)

Join the Linux box to the domain.

If you want, you can log into your AD server using the Active Directory and Users tool on a Windows box (most Windows admins will know this tool) and check to see that the Debian box is not in the domain, and then you can check again after joining to see that it is in the domain.

For the purposes of this document, we’ll join our Debian box to the domain using the realm utility, and we can join using the sssd method (recommended, most up-to-date, unless you need Samba file-sharing, which we do), or the Winbind method (slightly older method, which we’ll use because we need Samba file-sharing).

Choose → Join via sssd (recommended, unless you need Samba file-sharing)

If you’re going to connect using sssd (the recommended, most up-to-date, method):
In my case, this would be
Because packagekit is installed, the required packages for connecting with sssd will also be installed and configured.
Now if you do either of these commands again:
you’ll see that configured is no longer no, but rather kerberos-member, and that we now have a login-format of %U@domain.
Do some basic tests:
1. id [user@domain] should give you a list of things like groups and UID and GID, etc, related to that user.
2. getent passwd [user@domain] should give you the domain equivalent to the local systems /etc/passwd line for that user. (getent passwd [user] will give you that info for a local user instead of a domain user, and is equivalent to cat /etc/passwd | grep [user].)
3. Login as a domain user. At the login prompt, enter the username in the format of
  For example, smithj@widgets.com.
If this is successful, and it should be, you’ll notice that the user does not have a home directory, and that the user is using the root (“/”) directory for its home. This is not good. Let’s fix that.
Fix the home directory. The way this is done is to add the pam_mkhomedir.so module to the /etc/pam.d/common-session file. This could be done manually, but Debian makes it easier:
and then select the Create home directory on login option.
Optional: Change format of home directory. If you don’t like the format of having the domain name, you can change the fallback_homedir line in /etc/sssd/sssd.conf, just taking off the “@%d” part. (I’d comment out the line, with a hash mark (‘#’), and modify a copy of the line instead of the original; but that’s just me.)

If you want to get rid of the previously-created directory, just rm -rf the directory; there’s no local database information for the user, only the directory. So you don’t need to delete the user with deluser, etc; just delete the unwanted home directory. You’ll need to restart sssd for the change to take effect:
or
It might be better to leave the domain attached to the directory (and to the user, as mentioned in the next step) if you have local users, so there’s a clear distinction between AD-authenticated users and local users. But if you have users mapping drives to this Debian box from Windows or Mac, you might prefer for them to not have to map the drive with a username that needs the domain portion attached.
Optional: Login with just the username and not the username@domain format. But be careful; if you already have a local user with the same name as a domain user, this can confuse your system. This is especially true if you’ve changed the directory name as in the previous step, because the two users are not the same, and nor are the file ownerships/permissions/etc. Again, this change is made in /etc/sssd/sssd.conf: just change the use_fully_qualified_names line from True to False. As in the previous step, you’ll need to restart sssd.
In addition to logging in at the console, if you have ssh installed/configured (just aptitude install ssh, if you’d like) you should be able to ssh in as a domain user.
If login does not work, a couple of places to check is /var/log/sssd/sssd.log and /var/log/auth.log.
1. Another place to check is /etc/sssd/sssd.conf, maybe adding a “ad_site = [domain]” line and/or an “ad_gpo_ignore_unreadable = True” line.

Or Choose → Join via Winbind (recommended if you’ll have Samba file-shares)

If you’re going to connect using Winbind (a slightly older method):
Because packagekit is installed, some of the required packages for connecting with Winbind will also be installed and configured. The Winbind utilities are not installed by default using the SSSD method as described earlier.

However, packagekit/”realmd join” doesn’t (as of today) produce a working domain login (or a working getent utility) if you’re using the Winbind method; we’ll have to tweak it a little later.
If you’d like, you can verify the machine has been added to your domain, by using the “Active Directory Users and Computers” utility on a Windows computer (not installed on Windows by default, but any Windows domain administrator should know how to get the tool), and searching for your Debian box’s name.
This command should now return some info, including the fact that the system is now configured as a kerberos-member:
A tool you can use to look up AD info on a user is “wbinfo” using the “winbind” tool:
A similar test is:
which should return information about users in the domain (the more users in your domain, the longer it’ll take to run this command, at least the first time; if you get tired of waiting, you can Ctrl-C out of it). You can also pipe the results to grep to filter out a single user, etc:
You can get the AD groups with:
which should return information about groups in the domain. The man page for wbinfo offers several other tools that might be useful, such as:
and:
(which won’t work yet, until the aforementioned tweaks are made) which should prompt for the user’s password and test authentication using plaintext, and then prompt again for the user’s password and test authentication using challenge/response.
Some of the documentation out there states that you need to tinker with /etc/krb5.conf, but we don’t need to do that; the file probably doesn’t even exist on your box, if it’s a new, clean, minimal system.
As per Redhat’s documentation, the realm join –membership… command should have:
1. 1.Created a /etc/samba/smb.conf file for a membership in the domain.
2. Add the winbind module for user and group lookups to the /etc/nsswitch.conf file. On my Debian box, however, “winbind” was not added to the “passwd:” and “group:” lines, but “systemd” is there on both, which I presume is because the Debian tools believe that is sufficient; it is not, as we’ll see below.
3. Update the PAM config files in the /etc/pam.d directory. But a key component, creating a home directory for domain users, was not added; we’ll do that in a bit.
4. Configure and start the winbind service. You should now see a winbind script in /etc/init.d/. You can see that winbind processes are running with this command:
Many online documents say that “winbind” needs to be added to the “passwd:” and “group:” lines in the /etc/nsswitch.conf file (installed as part of Samba), which tells your system how to look up information on users and groups, but the Debian implementation of the realm join… command leaves this file configured to use systemd. For example, if you want to login as “bubba”, this line:
tells the system to first look in the system files (like /etc/passwd), and failing that, to then ask for the information from systemd.
So currently, the command wbinfo -i [domain_user] works, but the command getent passwd [domain_user] does not. So winbind is talking to the domain, but Debian’s systemd is not. This indicates a problem in the /etc/samba/smb.conf file or the /etc/nsswitch.conf file, or something in the pipeline… in my case, it took three tweaks to get getent to work:
1. Install a missing libnss-winbind package:
  This utility allows the system, via the /etc/nsswitch.conf file, to talk to the Winbind system, which in turn talks to the domain.
2. Tweak /etc/nsswitch.conf as mentioned above:
3. Tweak /etc/samba/smb.conf, to tell Samba that it’s okay for Winbind to list the users and groups:
  I believe the reason these are defaulted to no is because it could be a performance hit on very large domains. Winbind then needs to be restarted. Any of the below methods should work:
  1. reboot, or
  2. /etc/init.d/winbind restart, or
  3. /etc/init.d/winbind stop, followed by /etc/init.d/winbind start, or
  4. systemctl restart winbind, or
  5. systemctl stop winbind, followed by systemctl start winbind
Now that all the above has been done, not only is getent working now, (ex, getent passwd [user@domain]) so is the login. At the login prompt, log in as a domain user with:
However, you’ll see that the new user does not have a HOME directory. So exit out of the domain user account, and let’s fix this. Log back in as root (or a sudo user, etc), and either run:
(you can find the available profiles to enable/disable in /usr/share/pam-configs, which you could have found by looking at man pam-auth-update),

or
which will open a text-based GUI (a TUI), where you can select “Create home directory on login”.

That will create a new “pam_mkhomedir.so” line near the end of /etc/pam.d/common-session that will take care of this task for us. Now if you login as a domain user, a new directory will be created for that user. By default, the directory created is /home/user@domain. You can change this by changing, in /etc/samba/smb.conf (which doesn’t exist yet, until we install Samba later), this line:
but I’m concerned that might risk breaking future forward-compatibility. At any rate, you probably don’t want to set it to an existing directory structure, because then you’ll have to struggle to get file ownership/permissions/etc set up properly (although, this being Linux, you could certainly get it sorted out if you wanted to do this badly enough).
In addition to logging in at the console, if you have ssh installed/configured (just aptitude install ssh, if you’d like) you should be able to ssh in as a domain user. You’d remote in with one of these two commands:
or
You can also now use the id [user@domain] or getent passwd [user@domain] commands.
If you (needlessly) install the krb5-user package (aptitude install krb5-user), (you’ll then have the /etc/krb5.conf file mentioned earlier, and) you can try this test:

kinit [domain_user]@[DOMAIN}

This won’t return any information (unless something’s wrong; if you use a lower-case “DOMAIN”, you’ll get an error about not matching expectations). So you then use this command:

klist

to see that you got a Kerberos ticket. It seems (to my limited knowledge) that Kerberos is working.

Configure Samba File Sharing

1.Although a part of the Samba suite was installed earlier, not all of it has been. (If you used the sssd method above to join your machine to the domain, you may notice that /etc/samba and its smb.conf file do not exist.) If you try to map a drive from a Windows computer to the \\linux_box\homes or \\linux_box\domain_user shares, you won’t be able to connect to the Linux box at all. We need to install the Samba server:
If asked if you want to modify smb.conf to use WINS settings from DHCP, choose Yes (unless you have reason not to).

In order to connect to a user’s home share, that home directory must exist, which means that user must log into the machine (at the console, or via ssh) at least once in order to create the home directory.
Now try connecting to the linux_box (\\linux_box[name or IP]) in a Windows File Manager address bar on a same-domain-connected Windows box, and you should see your login user’s home directory share, although if the directory doesn’t exist, you won’t be able to access it.

Also, if you left the login name at the default, as %U%D in /etc/samba/smb.conf, meaning you log into your Debian box as user@domain, but you’re logging into Windows as just user, without the @domain part, then File Explorer will try to map a share to User rather than to User@domain, which is a directory that does not exist on your Debian box. So you’ll either have to change things on the Debian box to adjust for this, or change your behavior in Windows to map specifically to the user@domain share. For example, assume you’ve ssh’d into your Debian box, named peanuts.mydomain.com, using a user account named snoopy in the dogs.org Active Directory domain, with this command:
The directory created on the peanuts.mydomain.com Debian box will be /home/snoopy@dogs.org.

If you log into a Windows computer attached to the dogs.org domain, as the user snoopy, and then open File Explorer and in the address bar put \\peanuts.mydomain.com (assuming peanuts.mydomain.com is resolvable, either being in the domain’s DNS, or perhaps by placing it in the Windows PC’s lmhosts file), or \\[peanuts.mydomain.com’s IP address], then what will appear is the share snoopy, which will be inaccessible since there is no directory named snoopy. Instead, you’d need to use \\peanuts.mydomain.com\snoopy@dogs.org. With this, you should be able to connect to the share successfully.

However, this may not be suitable for your users. To remove the requirement to use the domain part of the username, edit /etc/samba/smb.conf, and change this line from no to yes:
Now, when you log in at the console, or via ssh, or map a shared drive, you can simply enter your username rather than your username@domain. The system will automatically assume the domain, as it has been specified in this same file at the workgroup = line.

Don’t forget you’ll need to restart the Samba daemon (which was added to /etc/init.d/ when you installed Samba above):
or
3.If you’d like the parent “home” directory share visible in the Windows’ File Explorer, in addition to your own user’s home directory, scroll down to the [homes] section and make:
You’ll need to restart Samba, as above in the previous point.
If you want your home directory to be read-write (probably), change this line in the [homes] section from no to yes:
and restart Samba.
5.Any additional Samba configuration should adhere to the normal Samba documentation, but this should get you started.