Centralizing automount rules in a centralized identity store such as FreeIPA is usually a good choice for your environment as opposed to copying the automount map files around – the administrator has one place to edit the automount rules and the rule set is always up to date. Replication mitigates most of the single-point-of-failure woes and by using modern clients like the SSSD, the rules can also be cached on the client side, making the client resilient against network outages.
What if your identity store is Active Directory though? In this post, I'll show you how to load automount maps to an AD server and how to configure SSSD to retrieve and cache the rules. A prerequisite is a running AD instance and a Linux client enrolled to the AD instance using tools like realmd or adcli. In this post, I'll use dc=DOMAINNAME,dc=LOCAL as the Windows domain name.
SSSD (as well as automounter LDAP backend) by default expects RFC2307bis schema on the LDAP server. Unfortunately AD (as of Windows 2008) is not fully compatible RFC2307bis schema so we have two options:
1.4 Volume Binding. Unix implements a namespace of hierarchically mounted filesystems. Two forms of binding between names and files are provided. A hard link completes the binding when the name is added to the filesystem. A soft link delays the binding until the name is accessed. AutoMounter is a sleek and powerful menu item for automatically mounting your network shares, ensuring that your shares are always mounted when you need them. Automatically mounts SMB / AFP / NFS / WebDAV / (FTP is read-only) Supports multiple NAS appliances, with server discovery. Advanced rule matching against WiFi SSIDs and more. Amd has also become known as the Berkeley Automounter. Linux has an independent implementation of an autofs-based automounter; version 5 of that automounter generally operates compatibly with the Solaris automounter. FreeBSD used to provide Amd; starting with 10.1 it has a new automounter very similar to the Solaris one.
- Use (older) RFC2307 recommendation to store maps – more SSSD configuration is needed
- extend AD schema to fully meet RFC2307bis and use SSSD with default configuration
As extending AD schema is irreversible operation that can be potentially dangerous – and not every Linux admin has right (Forest schema admins are needed) to do so, in this article we will describe the first option.
As the first step we need to create an LDAP container that would store the automount maps. It's not a good idea to mix automounter rules into the same OU that already stores other objects, like users – a separate OU makes management easier and allows to set more fine-grained permissions. You can create the automount OU in 'ADSI Edit' quite easily by right-clicking the top-level container (dc=DOMAINNAME,dc=LOCAL), selecting 'New->Object'. In the dialog that opens, select 'organizationalUnit', click 'Next' and finally name the new OU 'automount'. Note that ldap_autofs_search_base defaults to the RootDSE so we have to tell SSSD about the autofs maps location by in sssd.conf.
We also need to re-map automounter maps to the NIS friendly format – this is also done in sssd.conf. The final configuration snippet will look like this:
autofs_provider = ldap
ldap_autofs_entry_key = cn
ldap_autofs_entry_object_class = nisObject
ldap_autofs_entry_value = nisMapEntry
ldap_autofs_map_name = nisMapName
ldap_autofs_map_object_class = nisMap
ldap_autofs_search_base = ou=automount,DC=DOMAINNAME,dc=local
Note:
As of sssd version 13.3, ad provider can be directly used to feed automounter – you can directly use 'autofs_provider = ad' and omit the mapping part. Ad provider does it automatically for you
You could notice that we specified an ldap (not ad) provider for the autofs backend in AD. This a bit confusing, but it has to be done this way due to the current limitation in SSSD. Fortunately, no other ldap settings (authentication, credentials, etc) is necessary, SSSD actually takes the missing bits from the AD provider which has already been configured using adcli or realmd tools.
Now, let's add the the maps themselves. First we need to define auto.master map to contain all other indirect (we expect indirect maps here, but direct autofs maps can be configured similarly).
In my test, I used 'ADSI Edit' again. Just right-click the AUTOMOUNT container, select 'New->Object' and then you should see nisMap in the list of objectClasses. You will be asked for name (CN) and nisMapName attribute values, so enter 'auto.master' for both. Similarly, create an additional nisMap called for example auto.home – this one, in our example, will hold maps for user directories.
Now we need to put a reference for the auto.home map we just created in the main auto.master. Right click on the 'auto.master' map we just created and select 'New-Object', pick 'nisObject'. You will be asked for name (CN) – enter '/home', nisMapName – enter 'auto.master' and nisMapEntry – enter 'auto.home'.
As a last step, let's define keys for particular users in our auto.home map. Right click on the 'auto.home' map and select 'New-Object', pick 'nisObject'. You will be asked for name (CN) – enter 'johndoe', nisMapName – enter 'auto.home' and nisMapEntry – enter for example '-fstype=nfs4 -sec=krb5p Netapp:/vol/vol1/users/johndoe' to reflect a valid path to the NFS server.
The client configuration involves minor modifications to two configuration files. First, edit /etc/nsswitch.conf and append ‘sss' to the ‘automount:' database configuration:
automount: files sss
If the automount database was not present in nsswitch.conf at all, just add the line as above. This modification would allow automounter to communicate with the sssd with the libsss_autofs library.
Finally, open the /etc/sssd/sssd.conf file and edit the [sssd] section to include the autofs service:
Automounter 1 4 15
services = nss, pam, autofs
Then just restart sssd and the setup is done! For testing, run:
automount -m
You should be able to see something like this in the output:
autofs dump map information
global options: none configured
Mount point: /home
source(s):
instance type(s): sss
map: auto.home
victim | -fstype=nfs4 -sec=krb5p polaris1:/vol/vol1/users/victim
Automounter 1 4 1 1 Free Download
That's it! Now you can use your AD server as an centralized automount maps storage and the maps are cached and available offline with the SSSD.
Hi,
systemd can mount cifs filesystems at boot or on demand like autofs.
First cifs mount at boot time. Determine the share and the mount point.
For example:
Export: 192.168.56.1:/mp
Local mountpoint: /mnt/mp
Create the mount point
root@debdev:~# mkdir /mnt/mp
Create the systemd definition file. The Folder for custom systemd unit files is /etc/systemd/system.
Create a new file mnt-mp.mount in the diretory /etc/systemd/system. The filename must contain the mountpointname where the slashes are replaced with 'minus'. Filename for /mnt/mp => mnt-mp.mount
If this does not match you will get an error like:
root@debdev:~# journalctl |grep storage
mnt-mp.mount's Where= setting doesn't match unit name. Refusing.
This is a working unit
Enable the previous defined config and check if error occurs.
systemctl enable mnt-mp.mount
systemctl status mnt-mp.mount
To mount and unmount your share start or stop the unit.
root@debdev:~# systemctl start mnt-mp.mount
root@debdev:~# mount|grep 192
192.168.56.1:/mp on /mnt/mp type nfs (rw,relatime,...
root@debdev:~# systemctl stop mnt-mp.mount
If you make changes to your unit file while its still active, call
systemctl daemon-reload
to reload it.
It's also possible to mount your share just on demand. Like an automounter.
Define your mount unit mnt-mp.mount like above but do not enable it via systemctl.
Create an automount unit /etc/systemd/system/mnt-mp.automount. The automount unit starts the mount unit (mnt-mp.mount) on demand.
Enable the automount unit
systemctl enable mnt-mp.automount
This will create an autofs entry in the mount tab
root@debdev:~# mount|grep systemd
systemd-1 on /mnt/mp type autofs (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
root@debdev:~# systemctl status mnt-mp.automount
● mnt-mp.automount - nfs mount script
Loaded: loaded (/etc/systemd/system/mnt-mp.automount; enabled)
Active: active (running) since Fr 2016-03-18 12:21:37 CET; 9min ago
Where: /mnt/mp
and browse to the mountpoint and see what happens:
root@debdev:~ # ls -l /mnt/mp/Andreas/Adoring_Human_Flesh/
-rwxr-xr-x 1 root root 9361449 Mai 2 2015 ZOOM0041.MP3
-rwxr-xr-x 1 root root 6881906 Mai 2 2015 ZOOM0045.MP3
-rwxr-xr-x 1 root root 5959680 Mai 2 2015 ZOOM0046.MP3
-rwxr-xr-x 1 root root 5880058 Mai 2 2015 ZOOM0051.MP3
Michael
