[Samba] Linux desktop setup with authentication against Samba AD DC

Peter Milesson miles at atmos.eu
Thu Nov 28 16:41:47 UTC 2024


Hi folks,

This is post no. 2, with technical information of how I set up the Linux 
PCs, and additional information about setting up the server shares. It 
will give the basic outlines to those trying to setup something similar, 
using another Linux distribution. I will not go into any detail about 
setting up the OS, and similar tasks, as it is assumed that the 
interested reader has got the required knowledge.


*Hardware*
CPU Gigabyte Brix GB-BRR5-4500 with AMD Ryzen 5 4500U, integrated GPU
RAM Crucial 8GB DDR4-3200 SoDIMM, 1.2V, CL22
SSD Patriot P320 PCIe M.2 256GB

The chosen hardware is more than sufficient for the task at hand, and 
provides lots of performance to a very modest cost. Added to that, small 
footprint, quiet operations, and low power consumption.


*Operating system*
Debian Bookworm with backports (status end of November 2024)

I chose Debian for this project, as it is a golden middle path, very 
stable, not too bleeding edge, neither too conservative, and with very 
few "surprises".


*Setting up*
I have exclusively used tools in Windows for setting up users in AD 
(ADUC) and configuring shares (Computer management).

/Setup users in AD/
Set up a few users in AD. The naming is irrelevant, use only names with 
ASCII A-Z, a-z, and 0-9 in user names (hint: have a look at MS's support 
pages about accented characters in user names)


/Setting up a server share (Windows or Samba) for the home directories/
*NOTE!* The setup has only been tested with Windows ACLs for maximum 
compatibility between Windows and Linux. The behavior with POSIX ACLs is 
unknown.

In the following text I will use the following abbreviations:

    This folder, subfolders, and files - TSF
    Subfolders and files only - SF
    This folder only - FO

- Create the root directory for the home directories
- Disable inheritance on the root folder
- Set ownership on the root folder and assign permissions
   - Set ownership to a group or user with administrative access in the 
domain (Domain Admins, Administrator)
   - Everyone (Read & Execute, FO), SERVER\Administrators (Full, TSF), 
SYSTEM (Full, TSF), CREATOR OWNER (Full, SF), Administrator (Full, TSF)
- Create the share in Computer Management, give full share permissions 
to Everyone

I named the share linuxhomes$, which implies that it will be hidden when 
browsing the server. What you don't see, won't tempt you...


/Create user home directories on the server/
- Create a directory with a name corresponding to each user name in the 
share directory
- Disable inheritance for each user directory
- Add the to be user to the permission list
- Set permissions on the user directory according to the following:
   - The user (Full, TSF), SERVER\Administrators (Full, TSF), CREATOR 
OWNER (Full, SF), SYSTEM (Full, TSF), Administrator (Full, TSF)
- Set ownership of the user's directory to that of the user


/Setting up Debian and installing components/
*Note!* The setup is untested with Samba versions below 4.21.1, YMMV.
- Make a minimal installation of Debian on the PC, only system utilities 
and sshd at this point
- Configure hostname and network, check that time synchronization 
(networkd-timesyncd) works. Caveat: When using DHCP, check that the DHCP 
server DNS point to AD DCs, oteherwise you need to use a static IP 
address on the PC, and set one or more AD DCs as name servers
- Add debian-backports to sources-list, update and upgrade
- Install other required packages from debian-backports: sudo, 
cifs-utils, attr, xattr, acl, cups
- Make sure there is at least one local sudo user
- Make sure nscd is not installed, disabling avahi-daemon.service and 
avahi-daemon.socket may also be a good idea
- Install the following packages from debian-backports, but exclude 
samba-ad-dc and samba-ad-provision:
   - krb5-user krb5-config  libldb2 libnss-winbind libpam-winbind 
libwbclient0 python3-ldb python3-cryptography python3-samba samba 
samba-common samba-common-bin samba-dsdb-modules samba-libs 
samba-vfs-modules winbind libpam-krb5 libpam-mount hxtools tdb-tools


/Setup Samba/
- Stop winbind, smbd, and nmbd
- Mask the nmbd service
- Configure Kerberos
- Configure /etc/samba/smb.conf
- Check that nsswitch.conf is OK and contains winbind for passwd and group


/smb.conf example/
# Global parameters
[global]
         dedicated keytab file = /etc/krb5.keytab
         disable netbios = Yes
         disable spoolss = Yes
         kerberos method = secrets and keytab
         printcap name = /dev/null
         realm = SAMDOM.EXAMPLE.NET
         restrict anonymous = 2
         security = ADS
         server role = member server
         smb ports = 445
         template homedir = /home/%U
         template shell = /bin/bash
         username map = /etc/samba/user.map
         min domain uid = 0
         winbind refresh tickets = Yes
         winbind use default domain = Yes
         workgroup = SAMDOM
         idmap config * : backend = tdb
         idmap config * : range = 3000-9999
         idmap config samdom : backend = rid
         idmap config samdom : range = 10000-99999
         map acl inherit = Yes
         vfs objects = acl_xattr


//etc/samba/user.map example/
!root = SAMDOM\Administrator


/Join the domain (as root, not sudo) and test/
samba-tool domain join samdom.example.net MEMBER -U administrator

samba-tool may output a bunch of error messages, but the important 
message is the last one, that the join was successful.

Start smbd and winbind

Run wbinfo --ping-dc, and check that the connection is successful


/Modify /etc/pam.d/common-session/
To avoid multiple mounts of the home directory, in case the user's home 
directory is not unmounted after logout, it is necessary to add the 
following line immediately before "session optional pam_mount.so"

session [success=1 default=ignore] pam_succeed_if.so service = systemd-user


/Setup automatic mounting with pam_mount after successful login/
Edit the file /etc/security/pam_mount.conf.xml and add the following 
contents after  <!-- Volume definitions -->:

<volume user="*"
         fstype="cifs"
         server="<FQDN of server>"
         path="linuxhomes$/%(DOMAIN_USER)"
         mountpoint="/home/%(DOMAIN_USER)"
         uid="10000-999999"
options="nosuid,nodev,sec=krb5i,cruid=%(USERUID),mfsymlinks,nobrl,vers=3.0" 
/>

The parameter uid should contain the same value as "idmap config samdom 
: range = 10000-99999" in /etc/samba/smb.conf". It means effectively, 
that no mounting should be tried for a user outside the uid span.

The following parameter must also be set properly, otherwise the user's 
home directory is not unmounted after logout

<logout wait="200000" hup="no" term="yes" kill="yes" />

If the PC and/or network is slow, it may be necessary to increase the 
wait value. With a value of 100000 (0.1s), I experienced that the user 
home directory did not get unmounted after logging off.


/Testing before installing a graphical desktop/
At this point you can try to login to the console either using a classic 
windows login name (WORKGROUP\user), or UPN:

SAMDOM\user
user at samdom.example.net

- Check that your user directory is under /home
- Try to create a file, an empty one is OK, check on the server that the 
file is in the user directory.
- Log out and log in as a local user
- Check that there is no directory /home/user.
- If there is, you need to increase the parameter logout wait= in 
/etc/security/pam_mount.conf.xml. *Note!* The delay is given in 
microseconds!

Login with SSH should behave like console login.


/Setting up the display manager/
It is important to use a display manager that stores Kerberos tickets, 
if you intend to use other kerberized services. In this setup LightDM 
was used. I tried with LXDM, as it is even more lightweight than 
LightDM, but Kerberos tickets are not stored.

When using a gvfs-based display manager (like LightDM), it is important 
to modify the behavior of the gvfs-daemon. It is a daemon that runs in 
userland, and in the original setup, it does not pick up the Kerberos 
ticket.

It is necessary to override this behavior by creating the unit file 
/etc/systemd/user/gvfs-daemon

[Unit]
Description=Virtual filesystem service
PartOf=graphical-session.target

[Service]
Environment="KRB5CCNAME=FILE:/tmp/krb5cc_%U"
ExecStart=/usr/libexec/gvfsd
Type=dbus
BusName=org.gtk.vfs.Daemon
Slice=session.slice


/Setting up the graphical desktop/
The choice of graphical desktop is an individual one. The choice here 
was LXDE, as it is very light weight and fast. Windows users (at least 
up to Windows 10) should not have any problems to feel at home here. You 
could always argue that the looks are seriously outdated, but the 
intention is fulfilling a purpose: Getting the user to do some work. If 
you miss the 3D-looks and the themes of a modern Disney cartoon, I 
recommend switching to Windows 11.

You want to start with a basic LXDE desktop, as the complete LXDE meta 
package contains uncountable applications. Additional LXDE elements, and 
required applications can be installed later on. LXDE is installed with 
the following packages:

   - lxde-core lxinput

The lxinput package enables the user to alter the mouse settings. Very 
handy for left handed persons.

Confirm that it is possible to login with the display manager as a 
domain user with a home directory defined. Use either the classic 
Windows login style (WORKGRUP\user) or with UPN.


/Installing required applications/
One of the final tasks is installation of required applications like web 
browsers, e-mail clients, remote desktop clients, etc. In this case, I 
installed Firefox, Thunderbird, Xpdf, LibreOffice, and FreeRDP. Also 
install specific language packs, if that is required (see below about 
localization).


/Localization/
If there are users which require a different user locale, the basic 
locale definitions should be configured now. Define the wanted locales. 
Edit /etc/locale.gen and uncomment the required locales, then run sudo 
locale-gen. Individual locale setting is described below.


/Configure CUPS and define printers for a limited set of users/
This is the right moment for defining printers, if there is intention of 
rolling out the image to several PCs with identical setups.


/Finalizing and saving a master image/
When the basic setup is working, the disk image can be saved as a master 
for rapid deployment of new devices.

If you intend to replicate the setup to new PCs, the current machine 
must first be removed from the domain, otherwise the new PC will "steal" 
the AD registration from a previous PC with the same setup. Remove the 
PC from the domain with:

sudo net ads leave -U Administrator

Power off the PC and boot up a Linux environment containing tools for 
copying an image of the whole disk.

I usually boot up an Archlinux installation image on a USB drive, as it 
contains all necessary tools, and transfer the disk image with dd over ssh.


/Individual localization/
LXDE can be set up for individual locales. This step is a once and for 
all activity, as the settings will be stored in the user's home 
directory, not on the PC. The setup is preferably made from another 
Linux PC, by subsequently mounting the home directories share as the 
Linux PC users, and adding the file described below.

It is assumed that the necessary locale definitions are configured on 
all the user PCs.

Repeat the following for every user that requires an individual locale.

- Mount the Linux user home share on the server as a specific user
- Create the file .xsessionrc (*Note* lower case) in the user's home 
directory. The contents are (for example Czech):

LC_ALL=
LANG=cs_CZ.UTF-8
LANGUAGE=cs_CZ:de:en

Applications based on gettext uses the LANGUAGE parameter, and in this 
example messages are preferably displayed in Czech, then German, and 
finally English.

Other LC_ variables can be added according to  your requirements. 
*Note!* It is considered a bad practice setting the LC_ALL parameter, as 
it overrides everything else.

Unmount the share and repeat for other users.


/Setting up a new PC from the master image/
*NOTE!* This may not work if the BIOS is set to UEFI secure boot. How to 
migrate from standard UEFI boot to secure UEFI boot is beyond the scope 
of this description
- Boot the new PC with an installation image on a USB drive, that 
contains a sufficient set of tools.
- Make sure that the disk in the new PC is sufficiently large for the 
image, at least the same size as the image
- Write the image to the PC's disk with the help of dd over SSH
- Reboot the PC
- Login as root from the console
- Change the host name in the hostname and hosts files
- Check/adjust the file /etc/network/interfaces and make sure the 
correct network interface names are used
- Reboot the PC
- Login as root from the console
- Stop smbd and winbind
- Join the PC to the domain (se above)
- Start smbd and winbind and check the domain connection with wbinfo 
--ping-dc
- Logout from root
- Make a test login as a user with home directory on the server
- Check that the user profile works
- Logout the user
- Login as a local user
- Check that the home directory for the previously logged in user does 
not exist

If the previously logged in user with a server home directory has left a 
mounted home directory, it is necessary to increase the logout wait time 
in the file /etc/security/pam_mount.conf.xml.
- Reboot the PC
- Login as root or local user with sudo privileges
- Remove the user directory for the user with a server home directory
- Increase the value until the user home directory is automatically 
removed after logout


*Conclusion*
After going through the steps above, there is a working PC with a 
graphical desktop, with authentication based on Kerberos and user 
profiles stored on a server. The users and PCs are all managed through 
AD, and with addition of administrative templates for Linux in AD, GPOs 
can be used for even more detailed administration.

If there are many Linux PCs to handle, it is probably a good idea to 
setup routines for regular updates and maintenance using scripting.

In case that the users store information with any importance at all, 
regular backups of the server share should be scheduled.

I hope you find the concept inspiring, and useful.

Peter


More information about the samba mailing list