Không thể làm cho SASL auxprop / sasldb hoạt động với postfix / Ubuntu 12.04


9

Tôi có hệ thống Ubuntu 8.04LTS chạy Postfix 2.5.1. Trên hệ thống đó, AUTH SMTP chạy tốt . Nội dung của /etc/postfix/sasl/smtpd.conf:

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: PLAIN

Các thuộc tính liên quan đến SASL là:

smtpd_sasl_type = cyrus
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_local_domain = $myhostname

Khi sudo sasldblistusers2tôi nhận được:

authusername@mail.mydomain.com: userPassword

Như tôi đã nói, tất cả đều hoạt động tốt trên hệ thống 8.04LTS.

Tuy nhiên, tôi đang cố gắng chuyển nó sang hệ thống Ubuntu 12.04LTS chạy Postfix 2.9.3 và tôi không thể làm cho nó hoạt động được. Tôi đang làm mọi thứ giống nhau, nhưng postfix luôn thất bại trong việc xác thực.

Đây không phải là /etc/sasldb2tập tin. Tôi đã thử chuyển tập tin từ hệ thống cũ và nó không hoạt động. Và tôi đã tạo một tệp mới bằng cách sử dụng:

saslpasswd2 -c -u mail.mydomain.com authusername

và nó không hoạt động, mặc dù nó sẽ hoạt động trên hệ thống cũ nếu tôi sao chép nó sang hệ thống cũ, đó là cách tôi biết không có gì sai với tệp.

Tương tự, tôi biết postfix đang xem smtpd.conftập tin. Nếu tôi thêm nhiều cơ chế hơn vào mech_listdòng của tệp, tôi sẽ thấy các cơ chế bổ sung đó được quảng cáo khi tôi kết nối với trình nền smtpd. Và khi tôi loại bỏ chúng, chúng lại biến mất. Vì vậy, /etc/postfix/sasl/smtpd.confrõ ràng là được sử dụng.

Tôi đang kiểm tra cả bằng cách sử dụng ứng dụng thư khách thực tế và bằng cách nói chuyện thủ công với máy chủ sau khi tạo mã thông báo bằng cách này:

perl -MMIME::Base64 -e 'print encode_base64("\000authusername\000thePassword");'

sau đó:

openssl s_client -quiet -starttls smtp -connect the.newsystem.com:587

Cuộc trò chuyện kết quả là:

250 DSN
EHLO example.com
250-the.newsystem.com
250-PIPELINING
250-SIZE 20971520
250-ETRN
250-AUTH PLAIN
250-AUTH=PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN theBase64EncodedToken
535 5.7.8 Error: authentication failed: authentication failure

Nhưng nếu tôi thay vào đó kết nối the.oldsystem.com:587và làm điều tương tự, tôi nhận được:

235 2.7.0 Authentication successful

Đầu ra của saslfinger trên máy mới là:

# sudoh saslfinger -s
saslfinger - postfix Cyrus sasl configuration Sat Jul 21 00:24:24 EDT 2012
version: 1.0.4
mode: server-side SMTP AUTH

-- basics --
Postfix: 2.9.3
System: Ubuntu 12.04 LTS \n \l

-- smtpd is linked to --
        libsasl2.so.2 => /usr/lib/i386-linux-gnu/libsasl2.so.2 (0xb76c5000)


-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = cyrus
smtpd_tls_CAfile = /etc/ssl/certs/MyCA.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/ssl/server.crt
smtpd_tls_key_file = /etc/postfix/ssl/server.key
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s


-- listing of /usr/lib/sasl2 --
total 16
drwxr-xr-x  2 root root 4096 Jul 20 23:00 .
drwxr-xr-x 67 root root 8192 Jul 20 21:25 ..
-rw-r--r--  1 root root    1 May  4 00:17 berkeley_db.txt

-- listing of /etc/postfix/sasl --
total 20
drwxr-xr-x 2 root root 4096 Jul 20 21:29 .
drwxr-xr-x 5 root root 4096 Jul 20 23:58 ..
-rw-r--r-- 1 root root   64 Jul 20 21:29 smtpd.conf



-- content of /etc/postfix/sasl/smtpd.conf --
pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: PLAIN

-- content of /etc/postfix/sasl/smtpd.conf --
pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: PLAIN


-- active services in /etc/postfix/master.cf --
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
smtp      inet  n       -       -       -       -       smtpd
submission inet n       -       -       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

[snipping the rest of the services]

-- mechanisms on localhost --

-- end of saslfinger output --

Tôi có thể thiếu / làm gì sai? Theo như tôi có thể nói, tất cả các cấu hình đều giống nhau, nhưng nó sẽ không hoạt động trên hệ thống mới.

Câu trả lời:


15

Giveaway ở đây:

-- active services in /etc/postfix/master.cf --
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
smtp      inet  n       -       -       -       -       smtpd
submission inet n       -       -       -       -       smtpd

Các smtpdquá trình trên submissioncổng đang chạy trong chế độ chroot (kể từ khi có một -trong cột đó có nghĩa là mặc định (đó là yes) áp dụng và do đó không thể nhìn thấy /etc/sasldb2.

Khi tôi sao chép /etc/sasldb2để /var/spool/postfix/etcxác thực bắt đầu hoạt động tốt.


3
Nhận xét này đặt dấu chấm hết cho sự điên rồ hậu tố tối nay. Ngoài ra, hãy nhớ rằng việc sử dụng cấu hình này sẽ yêu cầu người dùng xác thực phải là người dùng @ $ myhostname và không chỉ là "người dùng". Đó là khác nhau giữa cái này và cấu hình exim tương tự của tôi cho rơle xác thực.
David Dombrowsky

5

chroot chắc chắn là lý do, tuy nhiên đối với trường hợp của tôi, sao chép để /var/spool/postfix/etckhông hoạt động.

Vì vậy, tôi đã thoát khỏi chroot và điều đó làm việc cho tôi.

Để thực hiện điều đó, bạn sẽ cần chỉnh sửa /etc/postfix/master.cf định vị dòng sau:

smtp      inet  n       -       -       -       -       smtpd

và sửa đổi nó như sau:

smtp      inet  n       -       n       -       -       smtpd

4

Một cách khác để đồng bộ hóa tệp sasldb2 thành nhà tù chroot mặc định của postfix là thêm một liên kết cứng vào nó:

ln /etc/sasldb2 /var/spool/postfix/etc/

Lưu ý rằng một symlink sẽ không hoạt động vì không thể truy cập symlink từ bên trong nhà tù nhưng các liên kết cứng thì có thể. Điều này có lợi thế hơn là chỉ sao chép tệp vì người dùng mới và các thay đổi mật khẩu trong tương lai sẽ được tự động đồng bộ hóa mà không cần tải lại hậu tố.


Bạn thật tuyệt, tôi đã quản lý để chuyển tiếp máy chủ thử nghiệm Ubuntu 16, vì vậy tôi nghĩ rằng tôi sẽ thực hiện lại các thay đổi của mình trên máy chủ sản xuất Ubuntu 14 ... cả ngày để thử mọi thứ. Chroot là lý do, nhưng thay đổi để không bị chroot cho kết quả tồi tệ hơn, vì vậy việc giữ chroot và thực hiện ở trên đã giải quyết vấn đề của tôi.
mrjamesmyers
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.