This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.
Differences between revisions 7 and 17 (spanning 10 versions)
Revision 7 as of 2007-06-13 00:35:40
Size: 1535
Editor: TimoSirainen
Comment:
Revision 17 as of 2017-02-10 15:19:20
Size: 1573
Editor: adsl-75-24-144-168
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
User is looked up using `getpwnam()` call, which usually looks into `/etc/passwd` file, but depending on [[http://en.wikipedia.org/wiki/Name_Service_Switch|NSS]] configuration it may also look up the user from eg. LDAP database.
Line 3: Line 4:
User is looked up using `getpwent()` call, which usually looks into `/etc/passwd` file, but depending on [http://en.wikipedia.org/wiki/Name_Service_Switch NSS] configuration it may also look up the user from eg. LDAP database. Most commonly used as a user database.
Line 5: Line 6:
Most commonly used as a user database. Many systems use shadow passwords nowadays so it doesn't usually work as a password database. BSDs are an exception to this, they still set the password field even with shadow passwords.

The lookup is by default done in the primary dovecot-auth process, so if NSS is configured to do the lookups from an external server, it slows down all the other authentications while waiting for the reply. To avoid that, you can use {{{blocking=yes}}} argument to do the lookups in auth worker processes:
The lookup is by default done in the auth worker processes. If you have only a small local passwd file, you can avoid having extra auth worker processes by disabling it:
Line 10: Line 9:
# NOTE: v1.0.rc23 and later only
userdb passwd {
  args = blocking=yes
userdb {
  driver =
passwd
  args = blocking=no
Line 16: Line 15:
The "blocking" name can be a bit confusing. It doesn't mean that the lookup blocks the whole dovecot-auth, exactly the opposite.

== nss_ldap ==

nss_ldap can in some cases return wrong user's information and cause users to log in as each others. With 1.0.rc23 and later you can fix this by using the {{{blocking=yes}}} setting as described above.

There's a nss_ldap bug about this in [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154314 RedHat's Bugzilla].

A typical PAM + nss_ldap configuration looks like:
== Field overriding and extra fields (obsolete in v2.1+) ==
It's possible to override fields from passwd and add [[UserDatabase/ExtraFields|extra fields]] with templates, but in v2.1+ it's done in a better way by using override_fields. For example:
Line 27: Line 19:
# NOTE: v1.0.rc23 and later only
  userdb passwd {
    args = blocking=yes
  }
  passdb pam {
    args = dovecot
  }
userdb {
  driver = passwd
  # Pre-v2.1:
  #args = home=/var/mail/%u mail=maildir:/var/mail/%u/Maildir
  # v2.1+:
  override_fields = home=/var/mail/%u mail=maildir:/var/mail/%u/Maildir
}
Line 35: Line 27:
This uses the UID and GID fields from passwd, but home directory is overridden. Also the default [[MailLocation|mail_location]] setting is overridden.

== Passwd as a password database ==
Many systems use shadow passwords nowadays so passwd doesn't usually work as a password database. BSDs are an exception to this, they still set the password field even with shadow passwords.

With FreeBSD, passwd doesn't work as a password database because the password field is replaced by a `*`. But you can use [[AuthDatabase/PasswdFile#Passwd as a password database on FreeBSD|Passwd-file]].

Passwd

User is looked up using getpwnam() call, which usually looks into /etc/passwd file, but depending on NSS configuration it may also look up the user from eg. LDAP database.

Most commonly used as a user database.

The lookup is by default done in the auth worker processes. If you have only a small local passwd file, you can avoid having extra auth worker processes by disabling it:

userdb {
  driver = passwd
  args = blocking=no
}

Field overriding and extra fields (obsolete in v2.1+)

It's possible to override fields from passwd and add extra fields with templates, but in v2.1+ it's done in a better way by using override_fields. For example:

userdb {
  driver = passwd
  # Pre-v2.1:
  #args = home=/var/mail/%u mail=maildir:/var/mail/%u/Maildir
  # v2.1+:
  override_fields = home=/var/mail/%u mail=maildir:/var/mail/%u/Maildir
}

This uses the UID and GID fields from passwd, but home directory is overridden. Also the default mail_location setting is overridden.

Passwd as a password database

Many systems use shadow passwords nowadays so passwd doesn't usually work as a password database. BSDs are an exception to this, they still set the password field even with shadow passwords.

With FreeBSD, passwd doesn't work as a password database because the password field is replaced by a *. But you can use Passwd-file.

None: AuthDatabase/Passwd (last edited 2019-09-11 14:08:34 by MichaelSlusarz)