Add automount rules to Active Directory and access them with SSSD

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 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


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:

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


instance type(s): sss
map: auto.home

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.

Add automount rules to Active Directory and access them with SSSD

6 thoughts on “Add automount rules to Active Directory and access them with SSSD

  1. Dave says:

    Excellent writeup, many thanks! I have a question: Rather than defining keys for particular users in our auto.home map, as this would be prohibitive with thousands of users, can’t we simply use a username or UID variable?



    1. Thanks. Refer to the automounter man page – you can use automounter wild cards for this – i.e. key=* value=filer:/homes/&. Specific keys takes precedence to wild cards


  2. Khan Miller says:

    when I automount -m the maps are displayed but no mounting is done other than the , mount point created on my linux machine. Any ideas ?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s