LDAP patch for the Linux automounter

This patch will allow ldap-map names in (almost) the form of LDAP URLs as defined in rfc2255:

[[scheme:]//server[:port]][/basedn][?attr[?scope[?filter[?ext]]]]]

The main reason for using this patch is its greater flexibility: e.g., you can use your own LDAP schema, you can apply arbitrary filters, and you can connect with TLS. Also, clients can authenticate to the server, either via LDAP simple authentication, or via SASL (though only the "external" SASL mechanism is tested and likely to work at this time).

Download

The most current patch against the current stable release, autofs-4.1.4:

autofs-4.1.4-ldap-20050930.patch

Digital signature:

autofs-4.1.4-ldap-20050930.patch.asc

This patch includes support for SASL authentication, as well as LDAP simple authentication. The SASL part is still pretty experimental.

Older and deprecated patches are in the attic.

To use LDAP, you must configure autofs --with-openldap, and you will also need the OpenLDAP client libraries installed.

If you want to use SASL authentication, you must additionally configure --with-sasl, and you must have the Cyrus-SASL client libraries installed.

LDAP URL Semantics

Every component of the map name can contain characters escaped by the % method described in rfc1738. In particular, every % must be escaped as %25. Syntactical elements separating the components of the URL must not be escaped in this way.

scheme will default to ldap. Use ldaps to get TLS (which can provide server authentication and strong encryption of the connection).

default port depends on scheme: usually 389 for ldap and 636 for ldaps.

server takes its default from ldap.conf.

basedn takes its default from ldap.conf.

attr, if not empty, should contain the names of key (ie: mountpoint) and automountinformation attributes in the ldap schema to be used, separated by comma. This can be used to support your own LDAP schema. By default cn,automountInformation and cn,nisMapEntry are both tried, to support the popular schemas autofs.schema and nis.schema.

scope, if empty or missing, defaults to sub.

filter, if empty or missing, defaults to (|(objectclass=automount)(objectclass=nisObject)) which again supports both autofs.schema and nis.schema.

ext can be used to specify optional extensions. If not empty, it must contain a comma-separated list of [!]name=value pairs, with the ! indicating critical extensions. Currently supported extensions are listed below. Unsupported extensions will be ignored unless they are marked as critical (see rfc2255).

URL Extensions

timeout=n
Set the LDAP timeout to n seconds. Default is no timeout.

binddn=dn
Use the distinguished name dn in simple binds to the LDAP directory. Most likely, you must also specify a bindpwfile extension.
Simple binds will be anonymous unless you specify this extension.
For SASL (ie, non-simple) binds, binddn does not apply, as the client's identity is determined in the SASL layer.
Caveat: dn will most likely contain commas, which must be escaped as %2c.

bindpwfile=file
Read the password for simple authentication from file. This only makes sense together with a binddn extension.
Caveat: all content of this file is the password, so make sure the file does not end with a newline! (unless your password happens to end with a newline, of course)

sasl_mech=mechanism
Bind to the server using the specified SASL mechanism, instead of doing a simple bind. So far, the only tested mechanism is external, i.e., client authentication in the TLS layer. You may need to also specify tls_cert and tls_key extensions.
This extension is only available if automount is configured --with-sasl.
Caveat: if you try to use sasl_mech=external and don't specify valid tls_cert and tls_key extensions, binding will fail with an "unknown authentication method" error, which can be misleading.
Caveat 2: "SASL external" means "TLS client authentication", so obviously, it requires TLS. Thus, you must specify scheme ldaps in the URL.

tls_cert=file
Read the client X509 certificate from file (for TLS client authentication, aka "SASL external" authentication).

tls_key=file
Read the private key corresponding to the client certificate from file (for TLS client authentication, aka "SASL external" authentication).

Examples

The previous form of map names, as in autofs-4.1.3,

[//host/]basedn

is still allowed and should work as before. If you want to be more explicit, you could use:


  protocol="ldap"
  server="ldap.acme.bla"
  port="389"
  base="ou=automounts,o=acme,c=bla"
  attr="cn,automountInformation"
  scope="one"
  filter="(objectclass=automount)"
  ext="timeout=8"
  automount /some/where ldap \
    "$protocol://$server:$port/$base?$attr?$scope?$filter?$ext" --no-slashify-colons

to use the autofs.schema with plain (unencrypted) ldap protocol and an 8-second timeout.

If you want to use the nis.schema with protocol ldaps (ie, with TLS), you could use the settings


  protocol="ldaps"
  server="ldap.acme.bla"
  port="636"
  base="ou=automounts,o=acme,c=bla"
  attr="cn,nisMapEntry"
  scope="one"
  filter="(objectclass=nisobject)"
  ext="timeout=8"
  automount /some/where ldap \
    "$protocol://$server:$port/$base?$attr?$scope?$filter?$ext" --no-slashify-colons

But you can do more creative things: I am currently using approximately this:


  protocol="ldaps"
  server="ldap.physik.uni-potsdam.de"
  base="ou=people,ou=physik,o=uni-potsdam,c=de"
  attr="uid,automountInformation"
  scope="one"
  filter="(!(|(!(objectclass=physikAccount))(!(accountdomain=quantum))))"
  ext="timeout=8"
  automount /nfshomes ldap \
    "$protocol://$server/$base?$attr?$scope?$filter?$ext" --no-slashify-colons

Here, the automountKey (for users home directories) is the uid attribute in the user database entry (rather than from a separate subtree, which is an administrative mess). The automountInformation attribute specifies the physical location of the home directory. Only accounts with the attribute accountdomain=quantum are eligible for automounting on this host. Account entries look approximately like this:


  dn: cn=Hans-Heinz Müller-Lüdenscheidt,ou=people,ou=physik,o=uni-potsdam,c=de
  objectClass: physikPerson
  objectClass: physikAccount
  objectClass: shadowAccount
  objectClass: physikAutomount
  cn: Hans-Heinz Müller-Lüdenscheidt
  title: Herr
  givenName: Hans-Heinz
  sn: Müller-Lüdenscheidt
  memberOf: institute
  memberOf: quantum
  roomNumber: 107
  telephoneNumber: +49 331 977 1793
  facsimileTelephoneNumber: +49 331 977 1767
  mail: Hans-Heinz.Mueller-Luedenscheidt@physik.uni-potsdam.de
  physikMaildrop: hhmuell@loriot.qipc.org
  uid: hhmuell
  uidNumber: 123
  gidNumber: 456
  loginShell: /bin/bash
  userPassword:: R3VtbWllbnRlCg==
  homeDirectory: /nfshomes/hhmuell
  accountDomain: quantum
  PhysikExportInformation: quantum
  automountInformation: -nosuid,nodev loriot.qipc.org:/Users/hhmuell

Authentication

By default, autofs will bind anonymously to the LDAP server (even when using TLS: by default, TLS only authenticates the server, not the client!). If your LDAP server won't give access to unauthenticated clients, you have the choice to use either LDAP simple authentication, or SASL:

In "LDAP simple authentication", the client authenticates as some entity in the directory. This entity must have a userPassword attribute which the client must send to prove his identity.
To use simple authentication with autofs, you must specify extensions like
binddn=cn=Joe Average%2cou=people%2co=acme%2cc=bla,bindpwfile=/etc/joes.password
in the URL (commas in the DN must be escaped!)
Unless you are also using TLS to encrypt the session (by specifying the scheme ldaps), "LDAP simple authentication" may transmit the password in clear text from client to server, and the session may also be vulnerable to other kinds of attacks (like hijacking); you have been warned!
SASL is "PAM for network services" (kind of). It can implement an arbitrary set of different authentication methods, called mechanisms, and you have to name the one you want to use in the sasl_mech extension.
So far, only the "external" mechanism is tested, and others are not very likely to work.
In "SASL external" authentication, the client proves his identity by
- presenting an X509 certificate (which contains the public part of an RSA key pair), and
- proving that he possesses the corresponding private RSA key (without revealing it, of course).
Thus, you must specify extensions like
sasl_mech=external,tls_key=/etc/ssh_host_rsa_key,tls_cert=/etc/cert.myself.pem
where /etc/cert.myself.pem is a X509 certificate which must be acceptable to the LDAP server and contain the public part of the host key pair. (of course, you can use any RSA key pair for this purpose. ssh host keys may be a convenient choice because they are already installed on most client hosts anyway).
"SASL external" authentication happens already in the TLS layer (which is why it is called "external"), so you must also use TLS (ie, you must specify the scheme ldaps in the URL).

Author

Author of the patch:

Timo Felbinger
Quantum Optics Group
Institut für Physik
University of Potsdam

This is free software and comes with NO WARRANTY.