I’m jumping onto a topic that keeps popping up for me in Samba/AD environments. I don’t think this is UCS-specific at all — it’s more about Debian as a domain member in general.
Quick background:
I’m currently writing a Python tool that analyzes an AD environment and evaluates whether a domain join is likely to succeed before actually attempting it. One practical example: if realm discover returns nothing even though the DNS records (_ldap._tcp, _kerberos._tcp) are perfectly fine, my tool should still be able to infer the REALM from DNS and offer it to the user. From a UX point of view, that’s just nicer.
What really bugs me though is a different issue altogether: the availability (and usability) of the UID of the currently logged-in domain user inside the desktop/system environment.
At first glance this sounds trivial — you have id, sssctl user-show, klist, and so on. But in practice, the integration breaks down in several places.
Use case
On workstations, you can use pam_mount to dynamically resolve the UID and mount CIFS shares at login — works fine.
On laptops that must also work outside the domain, things get messy. You can’t use static mounts, because multiple users should be able to log in on the same device. The goal is simple:
A logged-in domain user should be able to see SMB shares in the file manager (Dolphin) and mount them with a click — assuming they have the required permissions.
Since SSSD already retrieves a Kerberos ticket at login and resolves the domain UID, this should be straightforward. In reality, it isn’t.
Case 1 — /etc/fstab
You can define a share like this and prevent it from being mounted automatically:
//srv01.lan.beispiel.de/Korrespondenz /mnt/Korrespondenz cifs sec=krb5i,uid=2016,gid=5001,cruid=2016,iocharset=utf8,_netdev,noperm,nofail,soft,fsc,actimeo=30,retrans=1,x-systemd.device-timeout=1,user 0 0
The problem: Kerberos requires the correct UID for the mount. In /etc/fstab, that UID is static. As soon as another domain user logs in, they can’t use the mount anymore. The multiuser mount option doesn’t give the expected results here either.
Case 2 — Network access via Dolphin
As an admin, I’d really like to just type smb://, see the shares, and access them with a click.
Dolphin does list the shares — but it doesn’t reuse the current session’s user or Kerberos credentials. The user is always prompted again for username and password.
kio_smb feels outdated or borderline obsolete. You can hack around this with gvfs scripts or workarounds, but that doesn’t feel like a clean or robust solution.
Conclusion / Overall impression
Linux Desktop ↔ Linux/Samba AD integration really should be easier than this.
- On workstations using PAM + SSSD, things are mostly fine.
- On mixed-use laptops (offline-capable, multiple domain users), the experience is still pretty frustrating.
The core pain points are:
- UID handling for CIFS + Kerberos
- Seamless reuse of session credentials by file managers (Dolphin / kio / gvfs)
This isn’t meant as a complaint about UCS specifically — it’s just an experience report based on what I’m seeing in a Univention-backed environment.