Stopping login via "nologin" parameter
Hello,
I have a basic e-mail server with Postfix 3.1 and Dovecot 2.2.22.
I am using a passwd-file for both userdb and passdb:
/etc/dovecot/dovecot.conf
userdb {
driver = passwd-file
args = /etc/dovecot/passwd
}
passdb {
driver = passwd-file
args = /etc/dovecot/passwd
}
}
In the passwd file, I want to have user account names for SMTP SASL AUTH and IMAP that are NOT e-mail addresses.
For example, employee one of ABC corp would have a SMTP SASL AUTH/IMAP account name in the form: abc_company_employeeid (for example: abc_company_03284). The idea behind that is that I do not want someone outside of the company to be able to know the first half of the username and password pair just because they have an employee's e-mail address.
For the e-mail address I specify something like: bob@abc.com however I never want someone to be able to login via their e-mail address. Originally, I specified the password field as empty, with the understanding being that the default encryption of a password is {CRYPT}. Since crypt() cannot output a null string, this meant that there was never a valid password.
So passwd looked like this:
/etc/dovecot/passwd
# SMTP SASL AUTH and IMAP accounts
abc_company_03284:::::::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284
# IMAP
bob@abc.com:vmail:vmail::/home/vmail/bob::userdb_maill=maildir:/var/mail/vhosts/abc.com/abc_company_03284
I tested SMTP SASL AUTH and IMAP via the openssl s_client and can confirm that I can login and send e-mail as well as retrieve mail only via the: abc_company_03284 account, but because an empty password field isn’t mentioned on the Dovecot wiki, I was wondering if I should add “nologin” to explicitly make it impossible for: bob@abc.com. “nologin” was mentioned to me in a previous e-mail to this list.
So passwd would now look like this:
/etc/dovecot/passwd
# SMTP SASL AUTH and IMAP accounts
abc_company_03284:::::::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284
# IMAP
bob@abc.com:vmail:vmail::/home/vmail/bob::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 nologin
I restarted Dovecot and tested this with openssl s_client for SMTP SASL AUTH and IMAP, but just wanted to make sure that this STOPS ANY LOGINS via the e-mail address: bob@abc.com ?
Thanks,
- J
On Jul 19, 2018, at 6:49 PM, J Doe
mailto:general@nativemethods.com> wrote: Hello,
I have a basic e-mail server with Postfix 3.1 and Dovecot 2.2.22.
I am using a passwd-file for both userdb and passdb:
/etc/dovecot/dovecot.conf userdb { driver = passwd-file args = /etc/dovecot/passwd }
passdb { driver = passwd-file args = /etc/dovecot/passwd }
}
In the passwd file, I want to have user account names for SMTP SASL AUTH and IMAP that are NOT e-mail addresses.
For example, employee one of ABC corp would have a SMTP SASL AUTH/IMAP account name in the form: abc_company_employeeid (for example: abc_company_03284). The idea behind that is that I do not want someone outside of the company to be able to know the first half of the username and password pair just because they have an employee's e-mail address.
For the e-mail address I specify something like: bob@abc.com mailto:bob@abc.com however I never want someone to be able to login via their e-mail address. Originally, I specified the password field as empty, with the understanding being that the default encryption of a password is {CRYPT}. Since crypt() cannot output a null string, this meant that there was never a valid password.
So passwd looked like this:
/etc/dovecot/passwd # SMTP SASL AUTH and IMAP accounts abc_company_03284:::::::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 http://abc.com/abc_company_03284
# IMAP bob@abc.com <mailto:bob@abc.com>:vmail:vmail::/home/vmail/bob::userdb_maill=maildir:/var/mail/vhosts/abc.com/abc_company_03284 <http://abc.com/abc_company_03284>
I tested SMTP SASL AUTH and IMAP via the openssl s_client and can confirm that I can login and send e-mail as well as retrieve mail only via the: abc_company_03284 account, but because an empty password field isn’t mentioned on the Dovecot wiki, I was wondering if I should add “nologin” to explicitly make it impossible for: bob@abc.com mailto:bob@abc.com. “nologin” was mentioned to me in a previous e-mail to this list.
So passwd would now look like this:
/etc/dovecot/passwd # SMTP SASL AUTH and IMAP accounts abc_company_03284:::::::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 http://abc.com/abc_company_03284
# IMAP bob@abc.com <mailto:bob@abc.com>:vmail:vmail::/home/vmail/bob::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 <http://abc.com/abc_company_03284> nologin
I restarted Dovecot and tested this with openssl s_client for SMTP SASL AUTH and IMAP, but just wanted to make sure that this STOPS ANY LOGINS via the e-mail address: bob@abc.com mailto:bob@abc.com ?
Thanks,
- J
Hi list,
I believe I’ve found the solution I’m looking for.
I use one passwd-file for SMTP SASL AUTH, IMAP and LMTP from a Postfix 3.1 server to a Dovecot 2.2.22 server.
/etc/dovecot/dovecot.conf
userdb {
driver = passwd-file
args = /etc/dovecot/passwd
}
passdb {
driver = passwd-file
args = /etc/dovecot/passwd
}
}
The passwd file contains one test user. The test user’s SMTP SASL AUTH and IMAP account name is: “abc_company_03284" and has a password of “password”. The e-mail address of that user is "bob@abc.com mailto:bob@abc.com". I don’t have the SMTP SASL AUTH and IMAP account name set to “bob@abc.com mailto:bob@abc.com" because I don’t want someone to try to login by assuming the SMTP SASL AUTH/IMAP account name is the user’s e-mail address.
/etc/dovecot/passwd
# SMTP SASL AUTH and IMAP information
abc_company_03284:{PLAIN}password::::::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 <http://abc.com/abc_company_03284>
# LMTP
bob@abc.com <mailto:bob@abc.com>:{PLAIN}password:vmail:vmail:/home/vmail/bob::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 <http://abc.com/abc_company_03284>
If I test logging on via SMTP SASL AUTH and IMAP via the openssl s_client, I can log on using an account name of “bob@abc.com" and a password of “password”, as expected.
To stop someone from logging on via their e-mail address, I place “fail” [1] at the end INSTEAD OF “nologin”:
/etc/dovecot/passwd
# SMTP SASL AUTH and IMAP information
abc_company_03284:{PLAIN}password::::::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 <http://abc.com/abc_company_03284>
# LMTP
bob@abc.com <mailto:bob@abc.com>:{PLAIN}password:vmail:vmail:/home/vmail/bob::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 <http://abc.com/abc_company_03284> fail
If I then restart Postfix and Dovecot and attempt to login via SMTP SASL AUTH and IMAP via the openssl s_client with an account name of “bob@abc.com mailto:bob@abc.com” and use a password of “password”, it now fails password lookup in both instances. Because of the “fail” command, the password field I used for testing with the “bob@abc.com mailto:bob@abc.com" account is irrelevant and I can remove it. Therefore my final passwd file is:
/etc/dovecot/passwd
# SMTP SASL AUTH and IMAP information
abc_company_03284:{PLAIN}password::::::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 <http://abc.com/abc_company_03284>
# LMTP
bob@abc.com <mailto:bob@abc.com>::vmail:vmail:/home/vmail/bob::userdb_mail=maildir:/var/mail/vhosts/abc.com/abc_company_03284 <http://abc.com/abc_company_03284> fail
Sending a test e-mail to “bob@abc.com mailto:bob@abc.com” confirms that the user’s e-mail is received and stored in: "/var/mail/vhosts/abc.com/abc_company_03284 http://abc.com/abc_company_03284”, which means LMTP is working.
Can anyone confirm that I am correct about this ? I want to be sure that is now:
1) Impossible to login via SMTP SASL AUTH and IMAP using the e-mail address “bob@abc.com <mailto:bob@abc.com>”.
2) Only possible to login via SMTP SASL AUTH and IMAP using the account name “abc_company_03284” and a password of “password"
Thanks,
- J
Sources:
[1] https://wiki2.dovecot.org/PasswordDatabase/ExtraFields https://wiki2.dovecot.org/PasswordDatabase/ExtraFields and see “fail"
participants (1)
-
J Doe