Re: Additional filter for special_result_attribute query
On 2020-08-19 18:00, Viktor Dukhovni wrote:
On Wed, Aug 19, 2020 at 01:16:25PM +0300, Sergey Urushkin wrote:
So, this would be great if we had a way to specify additional filter
for
special_result_attribute query. Something like this in our case:
special_query_filter=(!(useraccountcontrol:1.2.840.113556.1.4.803:=2))
and the resulting query would be:
(&(dn={dn from special_result_attribute}){special_query_filter})
I guess it's not so hard to implement.
Sounds potentially reasonable, are you in a position to contribute a
patch along those lines?
Unfortunately no.
Should the special_result_query_filter support
any expansions (%1, %2, %d, ...)?
Basically, should the optional query component be static or not?
Static will be sufficient for us, but someone may find expansions
useful. E.g. mapping single group (static localpart/mail) to different
users for different domains:
query_filter = (&(mail=group1@any)(objectClass=group))
special_query_filter = (&(mail=*@%d)(objectClass=user))
cn=group1:
objectClass: group
mail: group@any
member: cn=user1
member: cn=user2
member: cn=user3
cn=user1:
objectClass: user
mail: user1@domain1
cn=user2:
objectClass: user
mail: user2@domain1
cn=user3:
objectClass: user
mail: user3@domain2
gro...@domain1.com will go to us...@domain1.com, us...@domain1.com
gro...@domain2.com will go to us...@domain2.com
---
Best regards,
Sergey Urushkin
Re: TLS client certificates and auth external
Steffen Nurpmeso: > I have no idea of the inner sensitivities of postfix, but i do not > understand where the problem lies. Why does postfix "wave > through" the SASL offering of EXTERNAL when it does not support > it? (I have no idea of SASL library interfaces.) Short summary: Postfix does not implement a single iota of SASL AUTH support. Postfix simply propagates the names of mechanisms that the backend (Cyrus or Dovecot) claims to support, and Postfix proxies requests and responses between the remote SMTP client and the SASL backend. Postfix has no idea what SASL mechanisms are, including EXTERNAL. It just proxies stuff. If Dovecot claims to support SASL EXTERNAL but does not handle it, that that is a bit of a WTF. > Ie postfix is configured to check client certificates, why does > it not "simply" allow the same configuration setting that dovecot > supports, something like auth_ssl_username_from_cert=yes, then > requires that for case(EXTERNAL) nothing but an empty immediate > response is passed, then passed the user given in the certificate > to the dovecot process? Or do also allow a username, but ensure > the given one is identical to that specified in the certificate? Are you suggesting that we create new SASL protocol support in Postfix to handle the EXTERNAL protocol inside Postfix? There currently is no code in Postfix for any SASL mechanism at all. Wietse
Re: TLS client certificates and auth external
Hello. I am new to this list, and only come here to continue on this old thread. I have restored it from X-MARC-Message: https://marc.info/?l=postfix-users&m=155674111415072 so message-id etc. may not truly be correct, i apologise for that. And also, first, thank you for postfix, i use it for quite some years for my small private use cases, and it is working just fine! I have problems to deal with EXTERNAL authentification in conjunction with postfix, too. And whereas i personally like EXTERNAL very much, because i think that "client certificates everywhere" would be a good thing also for the IoT, so to say, my personal interest for now lies solely in proper (testing) support of the small MUA i maintain, for the EXTERNAL authentification. I have no idea of the inner sensitivities of postfix, but i do not understand where the problem lies. Why does postfix "wave through" the SASL offering of EXTERNAL when it does not support it? (I have no idea of SASL library interfaces.) If postfix is configured to check client certificates, why does it not "simply" allow the same configuration setting that dovecot supports, something like auth_ssl_username_from_cert=yes, then requires that for case(EXTERNAL) nothing but an empty immediate response is passed, then passed the user given in the certificate to the dovecot process? Or do also allow a username, but ensure the given one is identical to that specified in the certificate? My explanation last year (when in implemented EXTERNAL authentification for my MUA) was that due to the many-process approach of postfix the relevant information is not available? But today, "running against this problem" again, i can hardly believe that the I/O is decoupled so extensively. Having said all that, i simply assume that SASL takes only a user name and a password, hm. Aug 19 18:36:11 arch-2020 postfix/smtpd[4684]: connect from _gateway[10.0.0.1] Aug 19 18:36:11 arch-2020 dovecot[3229]: auth: Debug: client in: AUTH 2EXTERNALservice=smtpnologinlip=10.0.1.11 rip=10.0.0.1securedresp= Aug 19 18:36:11 arch-2020 dovecot[3229]: auth: external(?,10.0.0.1): username not known Aug 19 18:36:11 arch-2020 dovecot[3229]: auth: Debug: auth(?,10.0.0.1): Auth request finished Aug 19 18:36:13 arch-2020 postfix/smtpd[4684]: warning: _gateway[10.0.0.1]: SASL EXTERNAL authentication failed: Aug 19 18:36:13 arch-2020 dovecot[3229]: auth: Debug: client passdb out: FAIL 2 Aug 19 18:36:13 arch-2020 postfix/smtpd[4684]: 0E5B240511: client=_gateway[10.0.0.1] When i use EXTERNAL for IMAP and POP3, directly via dovecot that is, then i see a cert_username= as well as valid-client-cert passing by in the log. Like i said, i have never looked behind these scenes of SASL, dovecot auth and postfix source code. Another thing i do not understand is that _when_ i do have permit_tls_clientcerts, and the client certificate matches, that AUTHs are still announced and required. (However, if i turn off smtpd_sasl_auth_enable=yes then not, ... of course.) Whereas it does not help me and my EXTERNAL support, i think it would be sensible to offer such a configuration possibility? Thanks in advance, and Ciao and good night from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: SMTP TLS delivery fallback
On Thu, Aug 20, 2020 at 01:33:16AM +1000, Nikolai Lusan wrote: > Personally I have: > > smtp_tls_security_level = may > smtpd_tls_security_level = may > smtp_tls_note_starttls_offer = yes The last one one is redundant, unless you also have a policy table with security level set to "none" for some destinatons. > smtpd_tls_protocols = !SSLv2, !SSLv3 !TLSv1 !TLSv1.1 TLSv1.2 TLSv1.3 > smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 TLSv1.2 TLSv1.3 It is best to NOT list the inclusions, instead, list only the exclusions. With Postfix 3.6, the preferred syntax will be: smtp_tls_protocols = >=TLSv1.2 smtp_tls_mandatory_protocols = >=TLSv1.2 Which is a lower-bound, you can alternatively/also set an upper bound, for example: smtp_tls_protocols = >=TLSv1, <=TLSv1.2 smtp_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3 > smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, KDH, SEED, aNULL, RC4, > PSD, SRP, 3DES, RC2, aDSS, IDEA, kECDH, eNULL > smtpd_tls_exclude_ciphers = MD5, DES, ADH, KDH, SEED, aNULL, RC4,PSD, SRP, > 3DES, RC2, aDSS, IDEA, kECDH, eNULL This looks somewhat cargo-culted, in particular: - There was IIRC never any set of "PSD" ciphers, perhaps you meant "PSK"? - There was never any set of "KDH" ciphers, you likely meant "kDH", to go along with "kECDH", both are indeed deprecated, and by default no longer enabled in OpenSSL 1.1.1. - Why are you disabling aNULL? Generally, when Postfix does opportunistic TLS (security level "may" or "encrypt"), the aNULL (i.e. ADH + AECDH) ciphers are left enabled. - Why are you disabling ADH? It is a strict subset of aNULL. - There is no need to exclue "eNULL" (twice!), that exclusion is built-in. > tls_high_cipherlist = > EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:!CAMELLIA128:!AES128:!SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:!CAMELLIA128-SHA:!AES128-SHA This is not a good idea. Go with the defaults. -- Viktor.
Re: SMTP TLS delivery fallback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-08-18 at 06:42 -0600, @lbutlr wrote: > > smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, > RC5 > smtp_tls_loglevel = 1 FWIW it is worth periodically reviewing the documentation for openssl and the ciphers it offers to maintain excluded cipher lists, and also set protocol lists. Personally I have: smtp_tls_security_level = may smtpd_tls_security_level = may smtp_tls_mandatory_ciphers = high smtpd_tls_mandatory_ciphers = high smtp_tls_note_starttls_offer = yes smtp_tls_block_early_mail_reply = yes smtpd_tls_protocols = !SSLv2, !SSLv3 !TLSv1 !TLSv1.1 TLSv1.2 TLSv1.3 smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 TLSv1.2 TLSv1.3 smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, KDH, SEED, aNULL, RC4, PSD, SRP, 3DES, RC2, aDSS, IDEA, kECDH, eNULL smtpd_tls_exclude_ciphers = MD5, DES, ADH, KDH, SEED, aNULL, RC4,PSD, SRP, 3DES, RC2, aDSS, IDEA, kECDH, eNULL smtp_tls_connection_reuse = yes smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache smtpd_tls_session_cache_timeout = 3600s smtpd_tls_always_issue_session_ids = yes smtpd_tls_eecdh_grade = auto tls_preempt_cipherlist = yes tls_daemon_random_bytes = 64 tls_random_source = dev:/dev/urandom tls_random_bytes = 64 tls_random_reseed_period = 3600s tls_random_exchange_name = /var/lib/postfix/prng_exch tls_random_prng_update_period = 3600s tls_append_default_CA = no tls_high_cipherlist = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:!CAMELLIA128:!AES128:!SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:!CAMELLIA128-SHA:!AES128-SHA (Some of which may also be deprecated/legacy) It's probably time I reviewed the cipherlist, but I have other things on my plate right now. - -- Nikolai Lusan Email: niko...@lusan.id.au Phone: 0425 661 620 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAl89RjwACgkQ4ZaDRV2V L6SeJg/9HuehYiuG2Ebg8N46og3sJkgtzcsghr1pq3BpiABIiI3m9VKNfL+NAazl LvFbIB/9CTbKgCZKI2frnmKtBuDNoSEJ/Mdi6N8fmeRffeMzPu71UN7Kf9y7wWJE 905sEmYKLUaVy+uAj5cXRXExv7+Btv3tXEyNCK6YdHlTEslUzgRgPUYO9q/I5T88 nmGHAQY+yTPNYeP6NUo3mcL4lVNTKIbSnOhnx1aiSUApyy9i8fWgBNXl0JWYjOSO CNI7/DWD226ddT9AXh1c2LSOEc3IP5bww0eB2fCfPb48EZuA1juZFEDhx0FjCCqj zaRgEIPUEQsRCux5hQOrqUZDOuiBc7xyhlhyHoh718mmjeUh9UIJv+wnuVzYZ6s0 crFWOlR0gtMsny2oWk4JifFgu0w3so49mtRvyru0LllMZpJP4dVNucWknj9DTcQ7 iUBwsX5rj1cjYJ62GiR0OjR0d1dVn3ldjStiYo9WjDXXj6KqEcMTO04yMvxPl2G6 tcGmXJ1L1jwqo+RC+S6ixqyfDBs5rn5dv/MTwGQ7fDm8Av/I7nn7gK+LI7lMqPE2 segkXisPnnUM/0IJ2KPeDiUG9D7iMy6wiqjCiB6hjM0u8+8RxsiGrvQUx/FaQknf +kCM/LWXC6ULPn54juAqRTfOz1H8NfgV9jT9frf4KhGeq42Trzg= =pNPW -END PGP SIGNATURE-
Re: Additional filter for special_result_attribute query
On Wed, Aug 19, 2020 at 01:16:25PM +0300, Sergey Urushkin wrote:
> So, this would be great if we had a way to specify additional filter for
> special_result_attribute query. Something like this in our case:
>
> special_query_filter=(!(useraccountcontrol:1.2.840.113556.1.4.803:=2))
>
> and the resulting query would be:
> (&(dn={dn from special_result_attribute}){special_query_filter})
>
> I guess it's not so hard to implement.
Sounds potentially reasonable, are you in a position to contribute a
patch along those lines? Should the special_result_query_filter support
any expansions (%1, %2, %d, ...)?
Basically, should the optional query component be static or not?
--
Viktor.
Additional filter for special_result_attribute query
We are using Postfix+ActiveDirectory and group aliases:
query_filter = (&(mail=%s)(objectClass=group))
result_attribute = mail
leaf_result_attribute = mail
special_result_attribute = member
And the problem is that special sub query does return disabled users
(useraccountcontrol:1.2.840.113556.1.4.803:=2) which we'd like to skip.
This problem was discussed earlier
https://marc.info/?l=postfix-users&m=131827035520537&w=2
Suggestion was:
either use ldap_uri valued groups (dynamic groups) or use a target
attribute (say "maildrop") that is absent in disabled objects.
Well, (1) AD doesn't support dynamic groups as I know, and (2) this can
not be called simple and reliable solution, since instead of the single
well-know in AD-world action (disable user) we'll need the second
(add/remove some attribute via ADUC or other LDAP tool).
So, this would be great if we had a way to specify additional filter for
special_result_attribute query. Something like this in our case:
special_query_filter=(!(useraccountcontrol:1.2.840.113556.1.4.803:=2))
and the resulting query would be:
(&(dn={dn from special_result_attribute}){special_query_filter})
I guess it's not so hard to implement.
Thanks for attention!
--
Best regards,
Sergey Urushkin
