Eu quase tenho checado o saslauthd contra o Kerberos, mas vendo alguns últimos problemas no CentOS 7. Quando o postfix fala com o saslauthd, ele envia um domínio em minúsculas e não é corrigido. Eu tentei consertar as coisas no /etc/krb5.conf usando [domain_realms] mas não funcionou. O testsaslauthd funciona bem, assim como o kinit.
saslfinger - postfix Cyrus sasl configuration Mon Oct 13 02:09:37 EDT 2014
version: 1.0.2
mode: server-side SMTP AUTH
-- basics --
Postfix: 2.10.1
System: CentOS Linux release 7.0.1406 (Core)
-- smtpd is linked to --
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007fb849a49000)
-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = EXAMPLE.COM
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix-certs/smtp.crt
smtpd_tls_key_file = /etc/postfix-certs/smtp.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
-- listing of /usr/lib64/sasl2 --
total 692
drwxr-xr-x. 2 root root 4096 Oct 12 20:39 .
dr-xr-xr-x. 62 root root 32768 Oct 12 15:59 ..
-rwxr-xr-x. 1 root root 19952 Jun 10 00:15 libanonymous.so
-rwxr-xr-x. 1 root root 19952 Jun 10 00:15 libanonymous.so.3
-rwxr-xr-x. 1 root root 19952 Jun 10 00:15 libanonymous.so.3.0.0
-rwxr-xr-x. 1 root root 24160 Jun 10 00:15 libcrammd5.so
-rwxr-xr-x. 1 root root 24160 Jun 10 00:15 libcrammd5.so.3
-rwxr-xr-x. 1 root root 24160 Jun 10 00:15 libcrammd5.so.3.0.0
-rwxr-xr-x. 1 root root 57888 Jun 10 00:15 libdigestmd5.so
-rwxr-xr-x. 1 root root 57888 Jun 10 00:15 libdigestmd5.so.3
-rwxr-xr-x. 1 root root 57888 Jun 10 00:15 libdigestmd5.so.3.0.0
-rwxr-xr-x. 1 root root 36904 Jun 10 00:15 libgssapiv2.so
-rwxr-xr-x. 1 root root 36904 Jun 10 00:15 libgssapiv2.so.3
-rwxr-xr-x. 1 root root 36904 Jun 10 00:15 libgssapiv2.so.3.0.0
-rwxr-xr-x. 1 root root 19984 Jun 10 00:15 liblogin.so
-rwxr-xr-x. 1 root root 19984 Jun 10 00:15 liblogin.so.3
-rwxr-xr-x. 1 root root 19984 Jun 10 00:15 liblogin.so.3.0.0
-rwxr-xr-x. 1 root root 19984 Jun 10 00:15 libplain.so
-rwxr-xr-x. 1 root root 19984 Jun 10 00:15 libplain.so.3
-rwxr-xr-x. 1 root root 19984 Jun 10 00:15 libplain.so.3.0.0
-rwxr-xr-x. 1 root root 28200 Jun 10 00:15 libsasldb.so
-rwxr-xr-x. 1 root root 28200 Jun 10 00:15 libsasldb.so.3
-rwxr-xr-x. 1 root root 28200 Jun 10 00:15 libsasldb.so.3.0.0
-- listing of /etc/sasl2 --
total 16
drwxr-xr-x. 2 root root 23 Oct 13 01:58 .
drwxr-xr-x. 98 root root 8192 Oct 13 00:42 ..
-rw-r--r--. 1 root root 101 Oct 13 01:58 smtpd.conf
-- content of /etc/sasl2/smtpd.conf --
pwcheck_method: saslauthd
mech_list: GSSAPI PLAIN LOGIN
keytab: /etc/postfix/smtp.keytab
loglevel: 6
-- active services in /etc/postfix/master.cf --
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
smtp inet n - n - - smtpd
submission inet n - n - - smtpd
pickup unix n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
-- mechanisms on localhost --
-- end of saslfinger output --
testsaslauthd:
[root@mail ~]# testsaslauthd -u [email protected] -p password -s smtp
0: OK "Success."
Parece muito um problema no Postfix não enviar os parâmetros corretos para o saslauthd, pois o testsaslauthd funciona.
UPDATE
Por sugestão, usei "ltrace -S" em instâncias de thread único de saslauthd e krb5kdc. Quando o testsaslauthd é usado, tanto o saslauthd quanto o KDC têm uma enxurrada de atividades e o resultado é uma autenticação bem-sucedida, mas quando o Postfix tenta processar o mesmo nome de usuário e senha, apenas o saslauthd tem alguma atividade e o KDC não possui nenhum. Além disso, não há registros de auditoria do selinux.
saída ltrace -S do saslauthd quando chamada do Postfix:
**SNIP**
close@SYS(10) = 0
gettimeofday@SYS(0x7ffffc0fa5b0, nil) = 0
<... krb5_init_context resumed> ) = 0
__snprintf_chk(0x7ffffc0fafb0, 2048, 1, 2048) = 33
krb5_parse_name(0x7f15647cc070, 0x7ffffc0fafb0, 0x7ffffc0fa6a8, 0x7fffffde) = 0x96c73a86
krb5_free_context(0x7f15647cc070, 0, 0x7f1560ee5770, 0) = 1361
__syslog_chk(3, 1, 0x7f1562b364cb, 0x7f15647cc060 <unfinished ...>
sendto@SYS(3, 0x7f15647cee20, 64, 0x4000) = 64
<... __syslog_chk resumed> ) = 0
malloc(28) = 0x7f15647ce510
strlen("NO saslauthd internal error") Oct 19 14:21:57 mail saslauthd[32005]: auth_krb5: krb5_parse_name
**SNIP**
Quando chamado via testsaslauthd: Observe a diferença após a chamada para krb5_parse_name ..
read(9, "smtp", 4) = 4
__errno_location() = 0x7fd8e86de7a0
read(9, "", 2) = 2
krb5_init_context(0x7fffe69f1888, 0x7fffe69f4de0, 0x7fffe69f4ef0, 0x7fffe69f5000) = 0
__snprintf_chk(0x7fffe69f21a0, 2048, 1, 2048) = 19
krb5_parse_name(0x7fd8e8bfd070, 0x7fffe69f21a0, 0x7fffe69f1898, 0x7fffffec) = 0
strcpy(0x7fffe69f19a0, "MEMORY:0") = 0x7fffe69f19a0
krb5_cc_resolve(0x7fd8e8bfd070, 0x7fffe69f19a0, 0x7fffe69f1890, 0x7fd8e870d0e2) = 0
krb5_cc_initialize(0x7fd8e8bfd070, 0x7fd8e8c22090, 0x7fd8e8c21f70, 0) = 0
krb5_get_init_creds_opt_init(0x7fffe69f18d0, 0, 0, 0) = 0
krb5_get_init_creds_opt_set_tkt_life(0x7fffe69f18d0, 900, 0, 0) = 0
krb5_get_init_creds_password(0x7fd8e8bfd070, 0x7fffe69f1920, 0x7fd8e8c21f70, 0x7fffe69f4de0
Parece que há um problema em como a biblioteca cliente kerberos está sendo configurada. Dado que o KDC não está sendo chamado no primeiro caso, é como se a biblioteca do cliente KRB5 estivesse rejeitando a chamada como lixo e jogando tudo fora. O que eu não tenho certeza é como descobrir por que não compilar tudo e anexar um depurador a ele.
** ATUALIZAÇÃO 2 **
Muito perto. A coisa que finalmente me levou foi executar o saslauthd na linha de comando sem o ltrace, mas com KRB5_TRACE="/dev/stderr" exportado no ambiente. Percebi o seguinte enquanto brincava com o programa testsaslauthd (que funcionou consistentemente durante todo o tempo):
saslauthd[785] :do_auth : auth success: [[email protected]] [service=smtp] [realm=] [mech=kerberos5]
Isso me fez pensar, "hmm, isso funcionou sem um reino", então eu removi os reinos de todos os lugares, incluindo a linha de comando e o Postfix main.cf. Tudo começou a funcionar.
ENTÃO eu percebi que tinha configurado o cliente de e-mail com o nome de usuário [email protected] em vez de [email protected]. Quando mudei de volta para um endereço de e-mail minúsculo, tudo parou de funcionar.
Depois disso, percebi que estava usando testsaslauthd com [email protected].
Isso está fazendo sentido? Parece que há um problema com o krb5.conf, mas tudo parece bem?
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
EXAMPLE.COM = {
kdc = mail.example.com:88
master_kdc = mail.example.com:88
admin_server = mail.example.com:749
default_domain = example.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM