autofs: Missing support of SCRAM for SASL binds

Hi rdratlos, thanks for keeping an eye on autofs.

Is this something that can be enabled in the Ubuntu packaging for autofs, or is it more a feature that'd need implemented in autofs itself? If the latter, would this be better to report upstream? Or do you already have thoughts on a fix for it?

It doesn't look like SCRAM support is implemented in autofs, so this is likely a feature request and, as such, should probably be forwarded upstream.

Dear Bryce and Sergio,
sorry for my late reply. In general, supported SASL bind mechanisms are transparent for autofs. But there is one line of code that harms this principle. I'll add a first patch later. Firstly, I would like to provide a reproduction of the bug/feature request.
Kind regards
Thomas

To reproduce an LDAP server (server.example.com) is required with a test user setup. autofs maps in LDAP are not needed, as we only try to bind our workstation to the directory service.

Test user dn:
<email address hidden>,ou=Users,dc=example,dc=com

Settings in /etc/autofs_ldap_auth.conf:
<?xml version="1.0" ?>
<!--
This files contains a single entry with multiple attributes tied to it.
See autofs_ldap_auth.conf(5) for more information.
-->

<autofs_ldap_sasl_conf
        usetls="yes"
        tlsrequired="no"
        authrequired="yes"
        <email address hidden>"
        authtype="SCRAM-SHA-1"
        secret="my_secret"
/>

Failed SASL bind log:
$ automount -f -v -d
Starting automounter version 5.1.8, master map auto.master
using kernel protocol version 5.05
lookup_nss_read_master: reading master ldap auto.master
parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master".
parse_server_string: lookup(ldap): mapname auto.master
parse_ldap_config: lookup(ldap): ldap authentication configured with the following options:
parse_ldap_config: lookup(ldap): use_tls: 1, tls_required: 0, auth_required: 2, sasl_mech: SCRAM-SHA-1
parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: (null) credential cache: (null)
do_init: parse(sun): init gathered global options: (null)
find_server: trying server uri ldap://server.example.com
do_bind: lookup(ldap): auth_required: 2, sasl_mech SCRAM-SHA-1
do_bind: Attempting sasl bind with mechanism SCRAM-SHA-1
do_bind: lookup(ldap): ldap_sasl_interactive_bind failed with error 49
do_bind: ldap_sasl_interactive_bind: SASL(-13): user not found: no secret in database
lookup(ldap): couldn't connect to server ldap://server.example.com

Here's the working configuration using unsafe DIGEST-MD5 mechanism:

<?xml version="1.0" ?>
<!--
This files contains a single entry with multiple attributes tied to it.
See autofs_ldap_auth.conf(5) for more information.
-->

<autofs_ldap_sasl_conf
        usetls="yes"
        tlsrequired="no"
        authrequired="yes"
        <email address hidden>"
        authtype="DIGEST-MD5"
        secret="my_secret"
/>

$ automount -f -v -d
Starting automounter version 5.1.8, master map auto.master
using kernel protocol version 5.05
lookup_nss_read_master: reading master ldap auto.master
parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master".
parse_server_string: lookup(ldap): mapname auto.master
parse_ldap_config: lookup(ldap): ldap authentication configured with the following options:
parse_ldap_config: lookup(ldap): use_tls: 1, tls_required: 0, auth_required: 2, sasl_mech: DIGEST-MD5
parse_ldap_config: lookup(ldap): user: <email address hidden>, secret: specified, client principal: (null) credential cache: (null)
do_init: parse(sun): init gathered global options: (null)
find_server: trying server uri ldap://server.example.com
do_bind: lookup(ldap): auth_required: 2, sasl_mech DIGEST-MD5
do_bind: Attempting sasl bind with mechanism DIGEST-MD5
do_bind: SASL username: <email address hidden>
do_bind: SASL authcid: root
do_bind: sasl bind with mechanism DIGEST-MD5 succeeded

Attached patch contains a first idea how to solve this issue. It has not yet been proposed to upstream, as the patch checks for SASL mechanisms that are supported by Cyrus libsasl2 during build.

Current Ubuntu approach is to provide SASL bind mechanims as optional packages (libsasl2-modules, libsasl2-modules-gssapi-mit), which are not a build dependency of the Cyrus SASL source package.

Therefore, this attached patch requires to add libsasl2-modules-gssapi-mit to the build dependencies in debian/rules.

A Launchpad PPA is available to test above patch on Ubuntu Jammy clients:
https://launchpad.net/~rdratlos/+archive/ubuntu/lp-1987992-autofs-missing-sram-support

I need further advice how to proceed in fixing this issue.

Upstream has a strong focus on backward compatibility and support of different LDAP implementations. Checks during configure (build) time seem to preferred over runtime checks. This strategy conflicts with Ubuntu packaging strategy for Cyrus SASL packages.

Currently followed strategy for fixing this issue is to add libsasl2-modules-gssapi-mit to autofs build dependencies. This automatically adds libsasl2-modules and we have most of the SASL mechanims available at build time. A configure message informs users about the detected mechanims.

On the other hand SCRAM family authentication mechanisms should be provided as part of the shared secret SASL authentication package (libsasl2-modules). See bug #1988730. This is required to allow Heimdal GSSAPI and SCRAM on clients. In this case, provided patch would just need to add libsasl2-modules to autofs build dependencies.

But still Cyrus SASL packaging in Ubuntu makes it very difficult to check and print all (installable) SASL bind/authentication mechanims on a server/workstation during build time.

Any ideas how to solve this hen and egg issue?

For sake of completeness the log about with above patch:

$ automount -f -v -d
Starting automounter version 5.1.8, master map auto.master
using kernel protocol version 5.05
lookup_nss_read_master: reading master ldap auto.master
parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master".
parse_server_string: lookup(ldap): mapname auto.master
parse_ldap_config: lookup(ldap): ldap authentication configured with the following options:
parse_ldap_config: lookup(ldap): use_tls: 1, tls_required: 0, auth_required: 2, sasl_mech: SCRAM-SHA-1
parse_ldap_config: lookup(ldap): user: <email address hidden>, secret: specified, client principal: (null) credential cache: (null)
do_init: parse(sun): init gathered global options: (null)
find_server: trying server uri ldap://server.example.com
do_bind: lookup(ldap): auth_required: 2, sasl_mech SCRAM-SHA-1
do_bind: Attempting sasl bind with mechanism SCRAM-SHA-1
do_bind: SASL username: <email address hidden>
do_bind: SASL authcid: root
do_bind: sasl bind with mechanism SCRAM-SHA-1 succeeded

A further security improvement of this patch let's OpenLDAP libldap negotiate and choose the most safe available SASL authentication mechanism:

Settings in /etc/autofs_ldap_auth.conf:
<?xml version="1.0" ?>
<!--
This files contains a single entry with multiple attributes tied to it.
See autofs_ldap_auth.conf(5) for more information.
-->

<autofs_ldap_sasl_conf
        usetls="yes"
        tlsrequired="no"
        authrequired="autodetect"
        <email address hidden>"
        authtype="DIGEST-MD5"
        secret="my_secret"
/>

$ automount -f -v -d
Starting automounter version 5.1.8, master map auto.master
using kernel protocol version 5.05
lookup_nss_read_master: reading master ldap auto.master
parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master".
parse_server_string: lookup(ldap): mapname auto.master
parse_ldap_config: lookup(ldap): ldap authentication configured with the following options:
parse_ldap_config: lookup(ldap): use_tls: 1, tls_required: 0, auth_required: 4, sasl_mech: DIGEST-MD5
parse_ldap_config: lookup(ldap): user: <email address hidden>, secret: specified, client principal: (null) credential cache: (null)
do_init: parse(sun): init gathered global options: (null)
find_server: trying server uri ldap://server.example.com
do_bind: lookup(ldap): auth_required: 4, sasl_mech DIGEST-MD5
do_bind: Attempting sasl bind with mechanism DIGEST-MD5
do_bind: SASL username: <email address hidden>
do_bind: SASL authcid: root
do_bind: sasl bind with mechanism SCRAM-SHA-1 succeeded

The attachment "Enable SCRAM for SASL binding" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

A further security improvement of this patch let's OpenLDAP libldap negotiate and choose the most safe available SASL authentication mechanism:

Settings in /etc/autofs_ldap_auth.conf:
<?xml version="1.0" ?>
<!--
This files contains a single entry with multiple attributes tied to it.
See autofs_ldap_auth.conf(5) for more information.
-->

<autofs_ldap_sasl_conf
        usetls="yes"
        tlsrequired="no"
        authrequired="autodetect"
        <email address hidden>"
        authtype="DIGEST-MD5"
        secret="my_secret"
/>

$ automount -f -v -d
Starting automounter version 5.1.8, master map auto.master
using kernel protocol version 5.05
lookup_nss_read_master: reading master ldap auto.master
parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master".
parse_server_string: lookup(ldap): mapname auto.master
parse_ldap_config: lookup(ldap): ldap authentication configured with the following options:
parse_ldap_config: lookup(ldap): use_tls: 1, tls_required: 0, auth_required: 4, sasl_mech: DIGEST-MD5
parse_ldap_config: lookup(ldap): user: <email address hidden>, secret: specified, client principal: (null) credential cache: (null)
do_init: parse(sun): init gathered global options: (null)
find_server: trying server uri ldap://server.example.com
do_bind: lookup(ldap): auth_required: 4, sasl_mech DIGEST-MD5
do_bind: Attempting sasl bind with mechanism DIGEST-MD5
do_bind: SASL username: <email address hidden>
do_bind: SASL authcid: root
do_bind: sasl bind with mechanism SCRAM-SHA-1 succeeded

Thanks for the steps to reproduce the issue and the proposed patch rdratlos.

The bug #1988730 you mentioned is valid and should be fixed in Jammy, but I believe you should try to forward the patch your are proposing here to upstream and get any feedback there. Once it gets merged we can work to add it to Jammy via a SRU (Stable Release Update).

In case you forward it to upstream, please add a reference here to the merge request so we can track everything.

Upstream has been informed and two patches have been proposed:
https://marc.info/?l=autofs&m=166294402105815&w=2

This patch is an add-on to fixes provided by LP #1984073.

Launchpad PPA has been updated to test above upstream proposed patches on Ubuntu Jammy clients:
https://launchpad.net/~rdratlos/+archive/ubuntu/lp-1987992-autofs-missing-sram-support

I'm sorry but previously posted patch 0002 contained an error. Here's the correct one.
PPA has been updated, too.

Thanks for forwarding the patches upstream. I see you are still waiting for further comments, when everything is settled and merged (it does seem it will take too long for them to merge the changes) we can move forward, preparing the upload and so on.

I see that there was some movement upstream, but I can't find the patches listed here:

https://mirrors.edge.kernel.org/pub/linux/daemons/autofs/v5/patches-5.1.9/

So I'm assuming that the upstream maintainers are still working on them. Nothing to do for now.

Here's the answer of the maintainer:
Ian Kent <email address hidden>
I haven't committed them yet, I've had a number of things come up. Rest assured your patches are in my queue for the next time I commit. Ian

Ian Kent <email address hidden>
There's no problem, it's just me getting diverted to other tasks. Rest assured I will get to committing the changes eventually. Ian

Seems that we need to be patient ...

On Monday, November 21 2022, rdratlos wrote:

> Here's the answer of the maintainer:
> Ian Kent <email address hidden>
> I haven't committed them yet, I've had a number of things come
> up. Rest assured your patches are in my queue for the next time I
> commit. Ian
>
> Ian Kent <email address hidden>
> There's no problem, it's just me getting diverted to other tasks. Rest assured I will get to committing the changes eventually. Ian
>
> Seems that we need to be patient ...

Thanks, rdratlos. Indeed, let's wait until upstream has the time to do
the actual commit.

Cheers,

--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

Still no commit or publishing in the patches directory from upstream, latest status is https://marc.info/?l=autofs&m=166867517022295&w=2

Still no upstream formal ACK on this patch. We will consider it again for the next development cycle.

This patch (and others) has been published to https://mirrors.edge.kernel.org/pub/linux/daemons/autofs/v5/patches-5.1.9/, this bug can move forward.

I have a DEP8 test that fails with the release package when using SCRAM-SHA-*, and passes when the autofs patch is applied.

This bug was fixed in the package autofs - 5.1.8-1ubuntu6

---------------
autofs (5.1.8-1ubuntu6) mantic; urgency=medium

  * d/t/ldap-map-sasl-auth: wait for slapd to be ready (LP: #2023232)

 -- Andreas Hasenack <email address hidden> Thu, 08 Jun 2023 14:02:00 -0300

Hello rdratlos, or anyone else affected,

Accepted autofs into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/autofs/5.1.8-1ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello rdratlos, or anyone else affected,

Accepted autofs into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/autofs/5.1.8-1ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Jammy[1] and Lunar[2] autopkgtests are green, and I can see that SCRAM-* was used in those tests, including other SASL mechanisms:

In Jammy[3]:

(...)
987s ## Configuring autofs to use mechanism SCRAM-SHA-1
987s
987s ## Confirming target is not mounted
987s total 4
987s drwxr-xr-x 2 root root 0 Jul 26 21:00 .
987s drwxr-xr-x 20 root root 4096 Jul 26 21:00 ..
987s
987s ## Triggering a mount, and checking that the mountpoint has the test file
987s -rw-r--r-- 1 root root 29 Jul 26 21:00 /mnt/storage/test_file_3556
987s
987s ## Checking that the mountpoint is nfsv4
987s TARGET SOURCE FSTYPE OPTIONS
987s /mnt/storage server.example.fake:/storage nfs4 rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.1.10
987s
(...)
(and likewise for the other mechanisms)

In lunar[4] (I picked another SCRAM-* variant for the paste):

(...)
1131s ## Configuring autofs to use mechanism SCRAM-SHA-256
1131s
1131s ## Confirming target is not mounted
1131s total 4
1131s drwxr-xr-x 2 root root 0 Jul 26 21:03 .
1131s drwxr-xr-x 20 root root 4096 Jul 26 21:03 ..
1131s
1131s ## Triggering a mount, and checking that the mountpoint has the test file
1131s -rw-r--r-- 1 root root 29 Jul 26 21:03 /mnt/storage/test_file_3296
1131s
1131s ## Checking that the mountpoint is nfsv4
1131s TARGET SOURCE FSTYPE OPTIONS
1131s /mnt/storage server.example.fake:/storage nfs4 rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.1.10
(...)
(and likewise for the other mechanisms)

Jammy and Lunar verifications succeeded.

1. https://ubuntu-archive-team.ubuntu.com/proposed-migration/jammy/update_excuses.html#autofs
2. https://ubuntu-archive-team.ubuntu.com/proposed-migration/lunar/update_excuses.html#autofs
3. https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/a/autofs/20230726_210052_fa453@/log.gz
4. https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/amd64/a/autofs/20230726_210332_bb951@/log.gz

The verification of the Stable Release Update for autofs has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package autofs - 5.1.8-1ubuntu4.1

---------------
autofs (5.1.8-1ubuntu4.1) lunar; urgency=medium

  * Support SASL SCRAM authentication (LP: #1987992):
    - d/p/autofs-5.1.8-support-SCRAM-for-SASL-binding.patch: allow
      SCRAM-SHA-*
  * d/t/control, d/t/ldap-map-sasl-auth: DEP8 tests for SASL
    authentication mechanisms in LDAP maps, including shared secret
    mechanisms and GSSAPI ones
  * Fix NTLM and CRAM-MD5 SASL authentication (LP: #2023595):
    - d/p/ntlm-crammd5-require-credentials.patch: fix NTLM and CRAM-MD5
    - d/t/ldap-map-sasl-auth: add NTLM and CRAM-MD5 to the test

 -- Andreas Hasenack <email address hidden> Wed, 05 Jul 2023 14:14:04 -0300

This bug was fixed in the package autofs - 5.1.8-1ubuntu1.3

---------------
autofs (5.1.8-1ubuntu1.3) jammy; urgency=medium

  * Support SASL SCRAM authentication (LP: #1987992):
    - d/p/autofs-5.1.8-support-SCRAM-for-SASL-binding.patch: allow
      SCRAM-SHA-*
  * d/t/control, d/t/ldap-map-sasl-auth: DEP8 tests for SASL
    authentication mechanisms in LDAP maps, including shared secret
    mechanisms and GSSAPI ones
  * Fix NTLM and CRAM-MD5 SASL authentication (LP: #2023595):
    - d/p/ntlm-crammd5-require-credentials.patch: fix NTLM and CRAM-MD5
    - d/t/ldap-map-sasl-auth: add NTLM and CRAM-MD5 to the test

 -- Andreas Hasenack <email address hidden> Wed, 05 Jul 2023 14:21:32 -0300