Estou tentando entender a abordagem correta para oferecer suporte a e-mail via Postfix/Dovecot para usuários autenticados em rede e vários serviços de rede, como o Gitlab.
Meu servidor de autenticação de rede é o Ubuntu 22.04, usando OpenLDAP e Kerberos. Todos os meus usuários autenticados em rede herdam das classes posixAccount
de PostfixBookMailAccount
objeto e enquanto minhas contas de serviço herdam apenas da última. Esta é uma tentativa de permitir login em várias máquinas apenas dos meus usuários, mas não das contas de serviço, mas para dar suporte a e-mail para ambos.
Tentei configurar o Dovecot para usar o pam
driver que funcionou para o e-mail do usuário, mas o Gitlab não funcionou. Modifiquei as configurações do PAM (que utilizavam Kerberos, mas não LDAP) adicionando LDAP antes do Kerberos. Isso incluiu configurar o PAM LDAP para pesquisar com base em mailEnabled
em vez de posixAccount
para pesquisa do usuário, mas algo pode estar errado, pois ainda funcionou para usuários, mas não para serviços.
Também tentei configurar o Dovecot para usar o ldap
driver e fazer uma busca semelhante, mailEnabled
mas algo também está errado, pois não funcionou para nenhuma conta.
Parece que eu poderia capitular e simplesmente criar contas de usuário para serviços como o Gitlab, mas isso desperta minha paranoia de segurança.
Antes de girar minhas rodas muito mais longe ou ir na direção errada, eu gostaria primeiro de entender se faz sentido distinguir essas duas fontes de e-mail ou se estou apenas pensando demais. Se eu deveria distinguir, alguém pode me indicar materiais de referência que descrevam essa abordagem ou fornecer algumas dicas se houver / quais considerações fazer ao configurar Postfix/Dovecot. Até agora, não tenho nenhuma combinação que se adapte a ambos os tipos de conta. Minha pesquisa na web não revelou nada sobre qual abordagem adotar e, portanto, nenhum material relevante.
Meu 10-auth.conf
contém:
auth_krb5_keytab = /etc/dovecot/dovecot.keytab
auth_mechanisms = plain login gssapi
onde o keytab foi preenchido com imap
, nslcd
e smtp
principais.
Quando configurado para PAM, meu auth-network.conf.ext
se parece com:
passdb {
driver = pam
}
userdb {
driver = passwd
args = uid=vmail gid=vmail home=/srv/vmail/%u mail=maildir:/srv/vmail/%u/Maildir
}
e quando configurado para LDAP é:
passdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
userdb {
driver = prefetch
}
userdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
Essa é a maneira padrão de fazer isso. O conceito relevante é que a existência de uma conta, ou a capacidade de autenticação como uma conta, não deve ser vinculada à autorização para que essa conta acesse serviços – por exemplo, é por isso que o PAM tem pilhas separadas
auth
(autenticação) eaccount
(autorização) para tudo.Então você pode ter autenticação baseada em Kerberos (GSSAPI que ignora PAM, ou senha via PAM) e ainda ter o serviço verificando autorização chamando pam_ldap.so de sua
account
pilha PAM. A maneira padrão é usar oauthorizedService
atributo LDAP, que corresponde 1:1 ao nome do serviço LDAP (mas você pode estendê-lo com valores personalizados para sistemas não baseados em PAM).Dessa forma, suas contas de "serviço" podem ser autorizadas a acessar apenas serviços específicos – como SMTP – mas ainda impedidas de usar SSH/Telnet/cron/sudo, apesar de serem uma posixAccount, pois não teriam a
authorizedService: sshd
permissão para logins SSH.Como alternativa, você pode
pam_succeed_if
exigir a associação a um grupo POSIX específico (por exemplo, se seus usuários regulares forem membros de 'usuários', mas contas de serviço não), para atingir o mesmo objetivo de impedir que contas de serviço efetuem login via SSH e coisas do tipo.Em comparação com o AD, que praticamente não faz distinção entre contas "completas" e contas "somente LDAP", qualquer serviço que precise de acesso de leitura LDAP obtém apenas uma conta de usuário "completa" (é o único tipo que existe) e todas as formas de acesso são controladas por meio de ACLs, não pela existência de contas.
Não tenho certeza se minha aplicação dessa abordagem está completa, mas pelo menos está funcionando para e-mail. Meus usuários autenticados pela rede agora têm um
authorizedService
atributo para os seguintes serviços:enquanto meus usuários de serviço gostam de
gitlab
não ter nenhum. As partes relevantes do meu/etc/sssd/sssd.conf
em cada máquina cliente e o próprio servidor de e-mail contém:onde
example.com/EXAMPLE.COM
está seu domínio ;)Acho que sem adicionar um atributo de serviço autorizado
su
não consegui alternar para outro usuário como:e sem isso
gdm-password
não consegui fazer login pela tela de bloqueio.Não encontrei muitas informações sobre o uso desse atributo, o que me surpreende um pouco se essa for a abordagem padrão. Este link https://freeradius-users.freeradius.narkive.com/IW953CLH/ldap-authorizedservice-attribute-matching#post2 ofereceu dicas sobre quais serviços eu deveria autorizar e também sugere quais outros serviços são necessários se você tiver algum gerenciador de exibição diferente.