0

I have joined a PC running Ubuntu Studio 18.04 to an AD domain managed by Synology Directory Server. I can now log into the Ubuntu PC with the credentials of a domain user, but there are still two things that don't work the way I want them to:

  1. Logging in with domain user credentials created a home directory on the Ubuntu PC, even though I configured a home directory and a user profile directory on the NAS in Synology Directory Server. I would like domain users to have their home directories on the NAS, not on the client PC.
  2. There is a shared (but not public) directory (named "private") on the NAS to which domain users should have access. The needed permissions are configured on the NAS. It mounts, but attempts to access it from a domain account result in permission denied. A similarly mounted public folder (named "public") is accessible:
    [email protected]@nas:/mnt$ ls -l
    total 84
    drwxrwxrwx 1 root users 77824 Mai 19 15:39 data
    d--------- 1 root users    46 Apr 20 19:52 private
    drwxrwxrwx 1 root root    114 Mär 13 11:55 public
    drwxr-xr-x 2 root root   4096 Aug 19  2018 sde1
    drwxr-xr-x 2 root root   4096 Aug 19  2018 sde5
    [email protected]@nas:/mnt$ ls private
    ls: cannot open directory 'private': Permission denied
    

Here is the corresponding mount output:

192.168.0.5:/volume1/private on /mnt/private type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.5,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.0.5)
192.168.0.5:/volume1/public on /mnt/public type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.5,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.0.5)

I suspect that there is something I failed to set up properly to enable the proper use of kerberos authentication. The only thing in my krb5.conf which isn't standard OOTB is:

[libdefaults]
    default_realm = NAS.RSBRUX.CH

This thread suggests exporting a keytab, but I am too ignorant to know what is meant. Furthermore, since I don't really know what I am doing, it is entirely possible that I misconfigured something when joining the domain. Any tips on how to proceed would be most welcome!

An answer to point 2 is posted below, but point 1 remains unresolved.

My configuration agrees with the one described in the sssd service documentation. A local home directory of the form /home/%u@%d is created for each domain user as predicted in the documentation. However, the manpage for sssd.conf states:

fallback_homedir (string)
           Set a default template for a user's home directory if one is not specified explicitly
           by the domain's data provider.

Although I have configured a server-based home directory for each domain user in Synology Active Directory, domain users only get a home directory specified locally in in /etc/sssd/sssd.conf. With:

override_homedir = %o

the domain user gets $HOME = '', and is therefore unable to login from GUI. A login via su yields:

Creating directory ''.
Unable to create and initialize directory ''.

This leads me to conclude that sssd is not getting a home directory from the DC. I have tried to double-check this by using ldapsearch to request the complete record for a domain user but haven't succeeded. For example:

$ ldapsearch -b "dc=nas,dc=rsbrux,dc=ch" -h diskstation.nas.rsbrux.ch
SASL/GSS-SPNEGO authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
    additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)

I thought I could work around this by automounting the user's server-based home directory with the following map in auto.nas:

/nas/home   -fstype=cifs,multiuser,cruid=$USER,sec=krb5    ://diskstation.nas.rsbrux.ch/home

and then specifying it in sssd.conf:

override_homedir = /nas/home

However, this doesn't work because automount doesn't mount the home directory in time for the login to complete. Perhaps I could fix this by using AutofsLDAP, but I am not (yet) that capable.
Furthermore, automount has trouble with the way Synology's home service presents the user's home directory. The domain user's home directory is under /homes on the server, but the appropriate directory is presented simply as /home based on the user's authentication. The parent directory /homes is not visible to automount. With the map:

/nas/home   -fstype=cifs,multiuser,cruid=$USER,sec=krb5    ://diskstation.nas.rsbrux.ch/home

automount is not disposing the file handle as I would expect. If I log in as a domain user via "su", log out, and then log in as a different domain user, any attempt to access /nas/home produces:

cannot open directory: Stale file handle

In fact, even GUI session logins suffer from the same problem. If a second domain user logs in after the first one has logged out, without restarting Ubuntu, the directory mapped under /nas/home is inaccessible.
According to the linux manpage for autofs:

special variables will be substituted in the key and location fields of an automounter map ...

However, the Ubuntu manpage says:

special variables will be substituted in the location field of an automounter map entry ...

(emphasis mine) and, indeed:

/nas/home/$USER   -fstype=cifs,multiuser,cruid=$USER,sec=krb5    ://diskstation.nas.rsbrux.ch/home

doesn't work (with or without curly braces).
I also tried removing the user's home directory from the automount map and adding an fstab entry so that I could experiment with mounting and unmounting it as different users. Here is the fstab entry:

//diskstation.nas.rsbrux.ch/home    /nas/home   cifs    noauto,users,_netdev,sec=krb5   

If I mount this for a particular user after logging in:

mount -v /nas/home 

It works for the first user to login after system start, but the second user gets "permission denied", even if the first user unmounts it before the second user logs in. This appears to be due to the "stale file handle" problem reported above. Several sources suggested that the stale file handle could be avoided by forcing the use of SMB 1.0:

//diskstation.nas.rsbrux.ch/home    /nas/home   cifs    vers=1.0,noauto,users,_netdev,sec=krb5  

but this did not yield any improvement.

IAC, I would like to avoid workarounds.
How can I find out why I am not getting the server-based home directory from my DC?
In particular, how can I discriminate between the following possibilities?

  1. The DC isn't sending the home directory at all.
  2. What the DC is sending is not in a form that the client can use.
  3. The client is unable to use what is sent due to some missing link in the client system (e.g. missing SW component(s) or incorrect configuration).
0

1 Answer 1

0

Solution to point 2 above.
The most elegant solution I have found for point 2 is to use autofs with multiuser option as described in the accepted answer to this post. Specifically, I installed the needed software:

sudo apt install autofs keyutils cifs-utils

and then configured /etc/auto.master as follows:

/-  /etc/auto.nas

I used a direct map (see the community wiki) to avoid any possible problems with indirect mapping as mentioned in one of the comments to the above-mentioned post. Here are the contents of /etc/auto.nas:

/nas/private   -fstype=cifs,multiuser,cruid=$USER,sec=krb5   ://diskstation.nas.rsbrux.ch/private
/nas/public   -fstype=cifs,multiuser,cruid=$USER,sec=krb5    ://diskstation.nas.rsbrux.ch/public

A third line is required to automount the user's home directory on the domain's file server, but I have omitted it here as the content will depend on how the user's home directory will be mapped (please see commentary further below). At first the shares wouldn't mount, with the error message "Required key not available", so I added this line to /etc/sssd/sssd.conf:

krb5_ccname_template=FILE:%d/krb5cc_%U

as recommended in the answer to this post. In retrospect, this was probably unnecessary; the problem was likely due to my using an IP address instead of a Fully Qualified Domain Name (FQDN) for the server. Synology recommends the use of IP addresses, but mount needs the FQDN to retrieve the domain user permissions.

Point 1 above is still unresolved.
My last attempted workaround was not successful either (see additional details above). It appears that the only solution will be to forsake the Synology home service and create a new tree of home directories on the server to be mounted on the Ubuntu client at the /home level and having individual subdirectories for each user. This seems less elegant to me and I would be grateful for alternate suggestions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .