Zitat von Emmanuel Fusté <emmanuel.fu...@external.thalesgroup.com>:
Hello,
Great piece of work ! It solve a big part of my problem, but sadly I
need to go deeper.
Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and
Victor, which adds an option smtpd_sasl_tls_ccert_username.
As the patch is rather small, I also attached it to this message.
This smtpd_sasl_tls_ccert_username option can be used in the following way:
Using smtpd_sasl_tls_ccert_username = commonName
After providing a verified client certificate, postfix advertises
auth external and the user can authenticate with the username being
the commonName of the certificate. This is for users having control
over the CA issuing the certificates and resembles the way cyrus
imap handles the situation.
Using smtpd_sasl_tls_ccert_username = relay_clientcerts
When a client presents a certificate, where the fingerprint matches
in relay_clientcerts, the lookup value (previously unused) is used
to get the username for sasl. The client can then perform an auth
external with this username successfully. This is a solution for
users, which cannot control the CAs or do not want to trust them or
cope with crls, ... It fits in the way postfix currently handles
client certificates.
I have to deal with products that do not support SMTP AUTH (big
email security appliance provider .....) but are able to present a
TLS certificate.
On my platform, the use of the smtpd_sender_login_maps and
associated restrictions (reject_sender_login_mismatch) is mandatory
to achieve our goal.
At first, I was thinking about using the lookup value of
relay_clientcerts to map a sasl username.
It is nicely done with your patch with smtpd_sasl_tls_ccert_username
= relay_clientcerts, but I need to go one step further:
I need to completely bypass the sasl provider call and act as if the
mapped user successfully authenticate.
It would be something like "smtpd_sasl_tls_ccert_username =
relay_clientcerts_nosasl" or relay_clientcerts_saslbypass or other
(I'm not good at finding good option naming ...)
The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer
announce AUTH support, the auth and identity mapping is already done
by the relay_clientcerts map
I think it is not a big code complexity addition on top of your
work, but before going further I would like to request for comments
about this.
Viktor, Wietse, would you accept such addition ?
Emmanuel.
I tested this with a patched postfix for my usage scenario (relaying
based on validated CN) but i fail to get it work. Note that i don't
need a sasl username at all, but also tested with sasl username and
check_sasl_access.
The config basically looks like this:
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sasl_access hash://etc/postfix/check_sasl_access,
defer_unauth_destination
# tested both
#smtpd_sasl_tls_ccert_username = commonName
smtpd_sasl_tls_ccert_username = relay_clientcerts_auto
#relay_clientcerts = hash://etc/postfix/relay_clientcerts
smtpd_tls_loglevel = 2
smtpd_tls_ask_ccert = yes
smtpd_sasl_auth_enable = yes
smtpd_use_tls=yes
smtpd_tls_CApath = /etc/ssl/certs
But this leads to
Apr 18 11:46:05 linux-test postfix/smtpd[4257]:
kw-tools.hq.kwsoft.de[10.1.7.15]: subject_CN=xxx.kwsoft.de,
issuer=SwissSign Server Silver CA 2014 - G22,
fingerprint=B8:D9:ED:1F:33:FE:DB:36:11:A6:D9:3F:BA:B5:1D:44,
pkey_fingerprint=43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: Trusted TLS connection
established from kw-tools.hq.kwsoft.de[10.1.7.15]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: NOQUEUE: reject: RCPT
from kw-tools.hq.kwsoft.de[10.1.7.15]: 454 4.7.1 <xx...@kwsoft.eu>:
Relay access denied; from=<xx...@kwsoft.de> to=<xx...@kwsoft.eu>
proto=ESMTP helo=<kw-tools>
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: disconnect from
kw-tools.hq.kwsoft.de[10.1.7.15] ehlo=2 starttls=1 mail=1 rcpt=0/1
data=0/1 rset=1 quit=1 commands=6/8
What i actually need is relaying based on validated certificate CN
without forcing the client to use some form of authentication, so this
would basically mean relay_clientcerts with CN lookup key or a
relay_clientcerts_auto_cn to always skip AUTH and use the CN as
username i guess.
Any other idea?
Thanks
Andreas
Any othe idea
