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:
- 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
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
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/and append ‘sss’ to the ‘automount:’ database configuration:
automount: files sss
If the automount database was not present in
Finally, open the /etc/sssd/ file and edit the [sssd] section to include the autofs service:
services = nss, pam, autofs
Then just restart sssd and the setup is done! For testing, run:
You should be able to see something like this in the output:
autofs dump map information
global options: none configured
Mount point: /home
instance type(s): sss
victim | -fstype=nfs4 -sec=krb5p polaris1:/vol/vol1/users/victim
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.