This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.
Differences between revisions 24 and 25
Revision 24 as of 2013-08-15 21:18:24
Size: 2961
Editor: TimoSirainen
Comment:
Revision 25 as of 2013-12-08 18:54:17
Size: 4559
Editor: TimoSirainen
Comment:
Deletions are marked like this. Additions are marked like this.
Line 39: Line 39:

  skip = never

  result_failure = continue
  result_internalfail = continue
  result_success = return-ok
Line 42: Line 48:
Here you have settings: First we have the settings that provide content for the userdb lookup:
Line 48: Line 54:

Then we have the setting which specify when the userdb is used (v2.2.10+):

 * skip: Do we sometimes want to skip over this userdb?
  * never
  * found: Skip if an earlier userdb already authenticated found the user
  * notfound: Skip if previous userdbs haven't yet found the user

And finally we can control what happens when we're finished with this userdb (v2.2.10+):

result_success: What to do if the user was found from the userdb (default: return-ok)
result_failure: What to do if the user wasn't found from the userdb (default: continue)
result_internalfail: What to do if the userdb lookup had an internal failure (default: continue). If any of the userdbs had an internal failure and the final userdb also returns "continue", the lookup will fail with "internal error".

The result values that can be used:

return-ok: Return success, don't continue to the next userdb.
return-fail: Return "user doesn't exist", don't continue to the next userdb.
return: Return earlier userdb's success or failure, don't continue to the next userdb. If this was the first userdb, return "user doesn't exist".
continue-ok: Set the current user existence state to "found", and continue to the next userdb.
continue-fail: Set the current user existence state to "not found", and continue to the next userdb.
continue: Continue to the next userdb without changing the user existence state. The initial state is "not found".

User Databases

After a user has been successfully authenticated, Dovecot looks up the user's userdb information. The userdb lookup is also done by LDA to find out how to deliver mails for the user.

The user database lookup returns these fields:

  • uid: User's UID (UNIX user ID), overrides the global mail_uid setting.

  • gid: User's GID (UNIX group ID), overrides the global mail_gid setting.

  • home: User's home directory, overrides the global mail_home setting. Although not required, it's highly recommended even for virtual users.

  • mail: Mail location, overrides the global mail_location setting.

  • Optional extra fields, which can be used for example:

    • Overwriting all mail-related settings (e.g. quota_rule to specify per-user quota limit)
    • The extra fields are also passed to post-login scripts

The user and password databases may be the same or they may be different depending on your needs. You can also have multiple databases.

Currently supported user databases are:

  • Passwd: System users (NSS, /etc/passwd, or similiar)

  • Passwd-file: /etc/passwd-like file in specified location

  • NSS: Name Service Switch

  • LDAP: Lightweight Directory Access Protocol

  • SQL: SQL database (PostgreSQL, MySQL, SQLite)

  • Dict: Dict key-value database (Redis, memcached, etc.)

  • Static: Userdb information generated from a given template

  • VPopMail: External software used to handle virtual domains

  • Prefetch: This assumes that the passdb already returned also all the required user database information

Userdb settings

An example userdb entry might look like this:

userdb {
  driver = passwd-file
  args = username_format=%n /etc/dovecot/users

  default_fields = uid=vmail gid=vmail
  override_fields = 

  skip = never

  result_failure = continue
  result_internalfail = continue
  result_success = return-ok
}

First we have the settings that provide content for the userdb lookup:

  • driver: The userdb backend name
  • args: Arguments for the userdb backend. The format of this value depends on the userdb driver. Each one uses different args.
  • default_fields: Userdb fields (and extra fields) that are used, unless overwritten by the userdb backend. They are in format key=value key2=value2 .... The values can contain %variables.

  • override_fields: Same as default_fields, but instead of providing the default values, these values override what the userdb backend returned. For example useful with userdb passwd for overriding e.g. home directory or the uid/gid.

Then we have the setting which specify when the userdb is used (v2.2.10+):

  • skip: Do we sometimes want to skip over this userdb?
    • never
    • found: Skip if an earlier userdb already authenticated found the user
    • notfound: Skip if previous userdbs haven't yet found the user

And finally we can control what happens when we're finished with this userdb (v2.2.10+):

result_success: What to do if the user was found from the userdb (default: return-ok) result_failure: What to do if the user wasn't found from the userdb (default: continue) result_internalfail: What to do if the userdb lookup had an internal failure (default: continue). If any of the userdbs had an internal failure and the final userdb also returns "continue", the lookup will fail with "internal error".

The result values that can be used:

return-ok: Return success, don't continue to the next userdb. return-fail: Return "user doesn't exist", don't continue to the next userdb. return: Return earlier userdb's success or failure, don't continue to the next userdb. If this was the first userdb, return "user doesn't exist". continue-ok: Set the current user existence state to "found", and continue to the next userdb. continue-fail: Set the current user existence state to "not found", and continue to the next userdb. continue: Continue to the next userdb without changing the user existence state. The initial state is "not found".

None: UserDatabase (last edited 2019-09-11 13:58:52 by MichaelSlusarz)