У меня почти есть проверка saslauthd на соответствие Kerberos, но я вижу некоторые последние проблемы в CentOS 7. Когда postfix обращается к saslauthd, он отправляет домен в нижнем регистре, и это не исправляется. Я пытался исправить что-то в /etc/krb5.conf, используя [domain_realms], но не сработало. testsaslauthd отлично работает, как и 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 brian@EXAMPLE.COM -p password -s smtp
0: OK "Success."
Очень похоже, что проблема в Postfix, когда он не отправляет правильные параметры в saslauthd, поскольку работает testsaslauthd.
ОБНОВИТЬ
По предложению, мы использовали «ltrace -S» для однопоточных экземпляров saslauthd и krb5kdc. Когда используется testsaslauthd, как saslauthd, так и KDC имеют шквал активности, и результатом является успешная аутентификация, но когда Postfix пытается обработать одно и то же имя пользователя и пароль, только saslauthd имеет активность, а KDC - нет. Кроме того, нет журналов аудита selinux.
ltrace -S вывод из saslauthd при вызове из 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**
При вызове через testsaslauthd: обратите внимание на разницу после вызова 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
Очень похоже, что есть проблема с настройкой клиентской библиотеки Kerberos. Учитывая, что в первом случае KDC даже не вызывается, создается впечатление, что клиентская библиотека KRB5 просто отклоняет вызов как мусор и выбрасывает все. Я не уверен в том, как понять, почему не нужно скомпилировать все и прикрепить к нему отладчик.
** ОБНОВЛЕНИЕ 2 **
Очень близко. В конце концов меня заставило запустить saslauthd в командной строке без ltrace, но с KRB5_TRACE="/dev/stderr" экспортируется в окружающую среду. Я заметил следующее, играя с программой testsaslauthd (которая работала постоянно):
saslauthd[785] :do_auth : auth success: [user=brian@EXAMPLE.COM] [service=smtp] [realm=] [mech=kerberos5]
Это заставило меня подумать: «Хм, это работало без области», поэтому я удалил области отовсюду, включая командную строку и Postfix main.cf. Все заработало.
ТОГДА я понял, что настроил почтовый клиент с именем пользователя brian@EXAMPLE.COM вместо brian@example.com. Когда я снова изменил его на адрес электронной почты в нижнем регистре, все перестало работать.
ТОГДА ПОСЛЕ этого я понял, что использовал testsaslauthd с brian@EXAMPLE.COM.
В этом есть смысл? Кажется, проблема с krb5.conf, но все в порядке?
[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