This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.
Differences between revisions 20 and 30 (spanning 10 versions)
Revision 20 as of 2016-02-10 18:18:49
Size: 2855
Editor: c-73-34-144-29
Comment: Added fail field
Revision 30 as of 2019-09-11 14:02:20
Size: 102
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Password database extra fields =
The primary purpose of a password database lookup is to return the password for a given user. It may however also return other fields which are treated specially:

 * '''[[PasswordDatabase/ExtraFields/User|user]]''': Change the username (eg. lowercase it).
 * '''login_user''': Master passdb can use this to change the username. (v2.2.13+)
 * '''[[PasswordDatabase/ExtraFields/AllowNets|allow_nets]]''': Allow user to log in from only specified IPs.
 * '''[[PasswordDatabase/ExtraFields/Proxy|proxy and proxy_maybe]]''': Proxy the connection to another IMAP/POP3 server.
 * '''[[PasswordDatabase/ExtraFields/Host|host]]''': Send login referral to client (if proxy=y field isn't set).
 * '''[[PasswordDatabase/ExtraFields/NoLogin|nologin]]''': User isn't actually allowed to log in even if the password matches, with optionally a different reason given as the authentication failure message.
 * '''[[PasswordDatabase/ExtraFields/NoDelay|nodelay]]''': Don't delay reply to client in case of an authentication failure.
 * '''nopassword''': If you want to allow all passwords, use an empty password and this field.
 * '''fail''': If set, explicitly fails the passdb lookup. (v2.2.22+)

How to return these extra fields depends on the password database you use. See the [[PasswordDatabase|password database]] pages on how to do it. Some passdbs however don't support returning them at all, such as [[PasswordDatabase/PAM|PAM]].

The password database may also return fields prefixed with `userdb_`. These fields are only saved and used later as if they came from the [[UserDatabase|user database]]'s extra fields. Typically this is done only when using [[UserDatabase/Prefetch|prefetch userdb]].

Note that boolean fields are true always if the field exists. So `nodelay`, `nodelay=yes`, `nodelay=no` and `nodelay=0` all mean that the nodelay field is true. With SQL the field is considered to be non-existent if its value is NULL.

== Examples ==
=== SQL ===

password_query = SELECT userid as user, password, 'Y' as proxy, host \
  FROM users WHERE userid = '%u'
=== LDAP ===

pass_attrs = \
  =user=%{ldap:user}, \
  =proxy=%{ldap:proxyEnabled}, \

Note about the "proxy", "proxy_maybe" and any other boolean type fields: these represent an existence test. Currently this translates to "will proxy (or proxy_maybe) if this attribute exists". This allows the proxy behaviour to be selectable per user. To have it "always" on, use a template, e.g.:

pass_attrs = \
  =user=%{ldap:user}, \
  =proxy=y, \
=== passwd-file ===
user:{plain}pass::::::proxy=y host=
Moved to

None: PasswordDatabase/ExtraFields (last edited 2019-09-11 14:02:20 by MichaelSlusarz)