Inspect SASL Plugins Safely with saslpluginviewer

saslpluginviewer shows which Cyrus SASL plugins are installed and loadable, and what mechanisms and security properties they actually offer. The checks are read-only and normally take five to ten minutes. They do not authenticate to a server, change SASL configuration or restart a service.

1. Confirm the installed tool

This guide is written against Ubuntu's sasl2-bin 2.1.28+dfsg1-5ubuntu3.1, installed as /usr/sbin/saslpluginviewer. The manual page calls the program pluginviewer in its synopsis, but the installed executable is named saslpluginviewer. Confirm both the package and the path before comparing output with a different host:

$ command -v saslpluginviewer
/usr/sbin/saslpluginviewer
$ dpkg-query -W -f='${Package} ${Version}\n' sasl2-bin
sasl2-bin 2.1.28+dfsg1-5ubuntu3.1

Run this as an ordinary user. Use sudo only if your environment deliberately restricts access to the executable or plugin directories. Elevation does not make a missing or broken plugin valid.

Checkpoint: you have the binary path and package version recorded. Stop here if the command is not installed; do not copy a plugin directory from another machine as a quick fix.

2. Take a baseline inventory

With no selection flags, the viewer reports auxprop plugins followed by server-side and client-side SASL mechanisms. It prints the installed and properly configured mechanisms, the mechanisms matching the current criteria, and then plugin properties such as API version, security flags and features:

$ saslpluginviewer
Installed and properly configured auxprop mechanisms are:
sasldb
List of auxprop plugins follows
Plugin "sasldb" ,  API version: 8
        supports store: yes

Installed and properly configured SASL (server side) mechanisms are:
  SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 SCRAM-SHA-224 SCRAM-SHA-1 DIGEST-MD5 EXTERNAL CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
Available SASL (server side) mechanisms matching your criteria are:
  SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 SCRAM-SHA-224 SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS

Your list is host-specific. A mechanism can appear in the installed list but not in the available list because the current side, security criteria or external security context excludes it. That distinction is the useful part of this command: a plugin file being present is not the same as a mechanism being usable for your intended connection.

3. Inspect one side at a time

Use -c for client authentication plugins, -s for server authentication plugins and -a for auxprop plugins. These options make a service-side comparison easier to read:

$ saslpluginviewer -c
Installed and properly configured SASL (client side) mechanisms are:
  SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 SCRAM-SHA-224 SCRAM-SHA-1 DIGEST-MD5 EXTERNAL CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
Available SASL (client side) mechanisms matching your criteria are:
  SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 SCRAM-SHA-224 SCRAM-SHA-1 DIGEST-MD5 EXTERNAL CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
List of client plugins follows
Plugin "plain" [loaded],  API version: 4
        SASL mechanism: PLAIN, best SSF: 0

The sample is shortened; the real command prints every matching plugin. For a server problem, do not infer the server list from the client list. The two contexts can expose different mechanisms and properties.

4. Limit the report to a mechanism

Use -m with a space-separated mechanism list. It is a filter for the report, not a command to enable a mechanism:

$ saslpluginviewer -c -m SCRAM-SHA-256
Available SASL (client side) mechanisms matching your criteria are:
  SCRAM-SHA-256
List of client plugins follows
Plugin "scram" [loaded],  API version: 4
        SASL mechanism: SCRAM-SHA-256, best SSF: 0

Quote a list containing spaces so the shell passes it as one argument:

$ saslpluginviewer -c -m 'SCRAM-SHA-256 PLAIN'

For auxprop plugins, use -x instead. On this host, saslpluginviewer -a reports sasldb. A mechanism filter does not test credentials, TLS, a server configuration file or a live protocol exchange.

5. Apply security criteria before choosing a mechanism

The -f option accepts comma-separated security flags. For example, noplain excludes mechanisms that send a password in the clear during authentication:

$ saslpluginviewer -c -m SCRAM-SHA-256 -f noplain
Available SASL (client side) mechanisms matching your criteria are:
  SCRAM-SHA-256
List of client plugins follows
Plugin "scram" [loaded],  API version: 4
        security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|MUTUAL_AUTH

Other documented flags are noactive, nodict, forwardsec, passcred and maximum. maximum requires all security flags. These are selection criteria, not a replacement for the policy in the client or server that will actually negotiate SASL. Treat passcred as security-sensitive: it asks for mechanisms that can delegate client credentials, so do not add it merely to make a list longer.

For a security layer, use -b min=N,max=N. The values are strengths in bits; a minimum of 1 means integrity protection. This example asks for mechanisms supporting a security layer from 1 through 256 bits:

$ saslpluginviewer -c -b min=1,max=256
Available SASL (client side) mechanisms matching your criteria are:
  DIGEST-MD5

The exact result depends on installed plugins. Do not read best SSF: 0 as proof that a mechanism is useless in every deployment; it describes the plugin's reported best security layer under the viewer's current assumptions.

6. Model an external security layer

If the connection already has an external layer such as TLS, -e ssf=N,id=ID tells the viewer its strength and authentication identity. It models that context; it does not create TLS or verify the identity:

$ saslpluginviewer -c -e ssf=128,id=host.example
Installed and properly configured SASL (client side) mechanisms are:
  SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 SCRAM-SHA-224 SCRAM-SHA-1 DIGEST-MD5 EXTERNAL CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS

Replace host.example with the identity supplied by the real external security layer. Do not paste a password, private key or bearer token into this option. If you do not have an external layer, omit -e; inventing an SSF or identity can produce a reassuring but irrelevant report.

7. Check a custom plugin path without changing the host

Use -p to provide a colon-separated plugin search path for this invocation. Start with a directory you can inspect and do not point a production service at it until the files and ownership have been reviewed:

$ saslpluginviewer -p /tmp/empty-sasl-plugin-path
Installed and properly configured auxprop mechanisms are:
<none>
Installed and properly configured SASL (server side) mechanisms are:
  EXTERNAL
No server side SASL mechanisms matching your criteria found

The external mechanism can still be reported because it does not require a plugin file in the same way as the other mechanisms. An empty or wrong path does not prove that all SASL support is absent. Check the path, permissions and library dependencies, then rerun the baseline command without -p. This diagnostic changes no persistent setting, so there is nothing to undo.

Done means