Home / server / Questions / 1166586
Accepted
user4540359
Asked: 2024-10-15 05:00:57 +0800 CST

Proprer way to support user and service emails with Postfix/Dovecot

  • 772

I'm trying to understand the correct approach to support email via Postfix/Dovecot for both network-authenticated users and various network services such as Gitlab.

My network-authentication server is Ubuntu 22.04, using OpenLDAP and Kerberos. My network-authenticated users all inherit from the posixAccount and PostfixBookMailAccount object classes while my service accounts only inherit from the latter. This is an attempt to only allow login on various machines from my users but not service accounts, but to support email for both.

I've tried configuring Dovecot to use the pam driver which has worked for user email but Gitlab didn't work. I modified the PAM configurations (which all utilized Kerberos but not LDAP) by adding LDAP ahead of Kerberos. This included configuring PAM LDAP to search based on mailEnabled instead of posixAccount for user lookup but something may be off as it still worked for users but not services.

I also tried configuring Dovecot to use the ldap driver and similarly search for mailEnabled but something is also off as it did not work for any account.

It seems I could potentially capitulate and just make user accounts for services like Gitlab but this tickles my security paranoia.

Before spinning my wheels too much farther or going in the wrong direction, I would first like to understand if it makes sense to distinguish these two email sources or if I'm just overthinking it. If I should distinguish, can someone point me to reference materials that outline this approach or provide some pointers if there are / what considerations to make when configuring Postfix/Dovecot. So far I have no combination that suits both account types. My web searching has not turned up anything on what approach to take and therefore any relevant material.

My 10-auth.conf contains:

auth_krb5_keytab = /etc/dovecot/dovecot.keytab
auth_mechanisms = plain login gssapi

where the keytab was populated with imap, nslcd, and smtp principals.

When configured for PAM, my auth-network.conf.ext looks like:

passdb {
  driver = pam
}
userdb {
  driver = passwd
  args = uid=vmail gid=vmail home=/srv/vmail/%u mail=maildir:/srv/vmail/%u/Maildir
}

and when configured for LDAP it's:

passdb {
  args = /etc/dovecot/dovecot-ldap.conf.ext
  driver = ldap
}
userdb {
  driver = prefetch
}
userdb {
  args = /etc/dovecot/dovecot-ldap.conf.ext
  driver = ldap
}
email

2 Answers

  1. It seems I could potentially capitulate and just make user accounts for services like Gitlab but this tickles my security paranoia.

    That's the standard way of doing it. The relevant concept is that the existence of an account, or the ability to authenticate as an account should not be tied to authorization for that account to access services – e.g. it's why PAM has separate auth (authentication) and account (authorization) stacks for everything.

    • authentication: determining who the client is
    • authorization: determining what the client is allowed to do

    So you can have Kerberos-based authentication (either GSSAPI which bypasses PAM, or password via PAM) and still have the service verify authorization by calling pam_ldap.so from its PAM account stack. The standard way there is to use the LDAP authorizedService attribute, which corresponds 1:1 to the LDAP service name (but you can extend it with custom values for non-PAM-based systems).

    This way, your "service" accounts can be authorized to only access specific services – such as SMTP – but still prevented from using SSH/Telnet/cron/sudo, despite being a posixAccount, as they would not have the authorizedService: sshd that allows SSH logins.

    Alternatively, you can use pam_succeed_if to require membership of a specific POSIX group (e.g. if your regular users are members of 'users' but service-accounts are not), to achieve the same goal of preventing service-accounts from logging in via SSH and such.

    Compare to AD, which practically does not have the distinction between "full" accounts and "LDAP-only" accounts, so any service that needs LDAP read access just gets a "full" user account (it's the only type that exists) and all forms of access are controlled through ACLs, not through existence of accounts.

    • 0
  2. Best Answer

    Not sure if my application of this approach is complete, but at least it's working for email. My network-authenticated users now all have an authorizedService attribute for the following services:

    • autofs
    • gdm-password
    • sshd
    • su
    • systemd-user

    whereas my service users like gitlab have none. The relevant parts of my /etc/sssd/sssd.conf on each client machine and the mail server itself contains:

    [domain/EXAMPLE.COM]
auth_provider = krb5
krb5_server = sso.example.com
krb5_realm = EXAMPLE.COM
access_provider = ldap
chpass_provider = krb5
id_provider = ldap
ldap_id_use_start_tls = true
ldap_uri = ldap://sso.example.com
ldap_schema = rfc2307
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = ...
ldap_default_authtok = ...
ldap_access_order = authorized_service
ldap_user_authorized_service = authorizedService
ldap_access_filter = authorizedService

    where example.com/EXAMPLE.COM is your domain ;)

    I think without adding an authorized service attribute for su I was not able to switch to another user like:

    su someone

    and without gdm-password I couldn't login from the lock screen.

    I didn't find so much information on using this attribute which surprises me a bit if this is the standard approach. This link https://freeradius-users.freeradius.narkive.com/IW953CLH/ldap-authorizedservice-attribute-matching#post2 offered hints at which services I should authorize and also suggests which other services are needed if you have any different display manager[s].

    • 0