Ubuntu 20.04 AD-Join (SSSD&Kerberos) with pam_mount (CIFS)


in relation to the contributions:

I have integrated Ubuntu 20.04 into Samba AD. Since not everything is running out-of-the-box, especially if you need dynamic CIFS.mount via pam_mount you have to intervene a little bit.

Since I spent several days with it here now (may also be due to my skills :wink: ) I describe the procedure here. Maybe another user needs something similar.

It would be good if somebody who has more knowledge about the technique in detail says something about it here.

In the first step I installed Ubuntu 20.04 (Desktop) as a minimum selection. The computer has to be connected to the UCS before it gets an IP.

Add packages and set time

sudo apt install ntpdate git keyutils libpam-mount cifs-utils
sudo ntpdate master.mydomain.local

** ADS join **

git clone https://github.com/ABotelho23/UCS_domain_join
cd UCS_domain_join
sudo bash setup.sh

What is the Kerberos realm? (dom.example.com)? mydomain.local
What is the domain controllers short hostname ? ('dc' part of dc.dom.example.com)? master
What is the domain admin username? Administrator
Creating computer account on master.mydomain.local UCS server. Password for domain admin will be prompted.
Add a domain user to local sudoers? Y/N: N
UCS Domain Join Complete! REBOOT NOW? [y/N] N

Note on sudors. Even if you select “y” here and specify a domain user to be added to sudors. Nothing happens! The specified user will not be added to the group. This has to be done manually later if you want to work with sudo. But since I always add a “real” root, it does not matter to me.

If you don’t need PAM_MOUNT with CIFS you can restart now and login with your domain users and everything is fine.
If you want pam_mount to work correctly with CIFS, change in /etc/sssd/sssd.conf

# deactivate entry
#default_domain_suffix = gehr.local

# change line
use_fully_qualified_names = True -> use_fully_qualified_names = False

Because my home everywhere is /home/[username] I have changed the following line:

fallback_homedir = /home/%u@%d -> fallback_homedir = /home/%u

I’m not sure if this is necessary or what the implications are.

change in /etc/request-key.d/cifs.spnego.conf

create  cifs.spnego    * * /usr/sbin/cifs.upcall %k
create  cifs.spnego    * * /usr/sbin/cifs.upcall -t %k

The script for the AD join comes from here:

many thanks to the developers!

Now restart the computer and log on as domain user.

Dynamic mounting of the user home from the server with PAM_MOUNT & CIFS does not work with the environment created by the script! I have spent days trying to figure it out or I found the reason. But not how I change it.

With the CIFS mount in PAM_MOUNT.CONF.XML I can use the variables


The variable %(USER) should actually contain the user name without …@DOMAIN… . But it does not. With the following line in /etc/security/pam_mount.conf.xml
<volume fstype="cifs" server="master.mydomain.local" path="%(USER)" mountpoint="/home/%(USER)/" sec="krb5i" cruid="%(USERUID)" />

the system tries to mount the servershare:
to local:


This share does not exist and must be without domain in the user.
I haven’t found a way to change that behavior.

Someone with more knowledge is needed here.

The remaining shares can then be mounted using the entries in /etc/security/pam_mount

<volume fstype="cifs" pgrp="domain users" server="master.mydomain.local" path="Buchhaltung" mountpoint="/data01/Buchhaltung/" sec="krb5i" cruid="%(USERUID)" />
volume fstype="cifs" pgrp="domain users" server="master.mydomain.local" path="Downloads" mountpoint="/data01/Downloads/" sec="krb5i" cruid="%(USERUID)" />

maybe someone facing the same problem will help. It would be nice if the dynamic mounting of the user homes would still work but I’m satisfied like this.

with best

I have not yet tested Ubuntu 20.04. I will not do that before April 20th. Too many bugs. But I’m sure that others are highly motivated here. :star_struck:

Thanks for the credit!

If you wanna work together I’d gladly take pull requests for the script!

I did in fact notice that the sudoers file modification is incomplete. It allows a user to perform sudo actions, but isn’t perfect because the user isn’t also added to the sudo group. I’ll be tweaking that soon.

If there is an extra rule for the user he hasn’t to be added to the sudo group. But if the user should have full admin rights I would prefer to add him to the sudo group. Or to create a rule for a domain group.

That’s right, I’ll probably simplify it and simply add the user to sudo group without adding to sudoers file.

As for a domain group, the idea here is to say give a single user who may “own” the device admin permissions to that device only. I can’t think of a simpler way for a device-by-device way of doing it. I’d gladly modify it if you have a clean way of doing it on the domain’s end.

Great! sudo is not relevant for me because I activate the “real” root. Other users might want / need it.