Postfix LDAP pipemap lookup tables and OctetStream

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Postfix LDAP pipemap lookup tables and OctetStream

Luca Fornasari
 Hello,

sadly I am stuck to a version of Postfix that not yet support
"pipemap" lookup table, so I am forced to ask here instead of simply
trying ...

I am using reject_sender_login_mismatch and I need to find out the
owner of an email address using smtpd_sender_login_maps.
The email address is present on a first AD server while user/owner is
on a second AD server ... what links the two is the SID (Exchange
linked mailbox).

The idea is to use a pipemap of LDAP queries; the first LDAP query
using the email address as a key to retrieve the
msExchMasterAccountSid on the first AD and pipe it as input key as
objectSid to a second LDAP query to retrieve the SamAccountName.

Since msExchMasterAccountSid is an OctetStream, I am wondering if this
will work ... does anyone already have experience on this?

Anyone did it with a custom script? What about performances?

Thanks
Luca
Reply | Threaded
Open this post in threaded view
|

Re: Postfix LDAP pipemap lookup tables and OctetStream

Fulvio Scapin
Hello Luca

> sadly I am stuck to a version of Postfix that not yet support
> "pipemap" lookup table, so I am forced to ask here instead of simply
> trying ...

Well you can always compile the latest version of postfix on your
machine and/or on the server in question, create the ldap files needed
and test the pipemap using postmap -q.

E.g.

$ /path/to/postfix_bin/postmap -q [hidden email] 'pipemap:{
ldap:/path/to/first_map, ldap:/path/to/second_map, }'

Of course you should be able to reach the LDAP servers from the machine
you run postmap from, although a few well-placed ssh-forwarded
connections would get you there anyway.

> I am using reject_sender_login_mismatch and I need to find out the
> owner of an email address using smtpd_sender_login_maps.
> The email address is present on a first AD server while user/owner is
> on a second AD server ... what links the two is the SID (Exchange
> linked mailbox).
>
> The idea is to use a pipemap of LDAP queries; the first LDAP query
> using the email address as a key to retrieve the
> msExchMasterAccountSid on the first AD and pipe it as input key as
> objectSid to a second LDAP query to retrieve the SamAccountName.
Be aware that creative combinations of unionmap, pipemap and pcre tables
(the latter to rewrite/combine outputs from other maps) can get you
pretty far, so if you have other keys or combinations of them which
might provide you a different join field through some degree of
rewriting it could be possible to use them.
> Since msExchMasterAccountSid is an OctetStream, I am wondering if this
> will work ... does anyone already have experience on this?
ldap_table(5) says the RFC 2254 quoting is used when expanding %s in the
search filter, but although I've made pipemap/unionmap combinations a
few levels deep I've never used binary values as keys, so I guess you
should just try.
>
> Anyone did it with a custom script? What about performances?

Performances are not usually an issue in my experience, but it depends
on the size of your infrastructure/mailflow and on how often the ldap
lookups are performed in your final flow.

Never tried a custom script.


Regards,

Fulvio


Reply | Threaded
Open this post in threaded view
|

Re: Postfix LDAP pipemap lookup tables and OctetStream

Viktor Dukhovni
In reply to this post by Luca Fornasari
On Thu, Feb 06, 2020 at 08:44:36AM +0100, Luca Fornasari wrote:

> I am using reject_sender_login_mismatch and I need to find out the
> owner of an email address using smtpd_sender_login_maps.
> The email address is present on a first AD server while user/owner is
> on a second AD server ... what links the two is the SID (Exchange
> linked mailbox).

You'll need a less exotic schema to make this go.  Provision a third
LDAP server on which the join is directly available in a single object
containing both the address and account name.

> The idea is to use a pipemap of LDAP queries; the first LDAP query
> using the email address as a key to retrieve the
> msExchMasterAccountSid on the first AD and pipe it as input key as
> objectSid to a second LDAP query to retrieve the SamAccountName.
>
> Since msExchMasterAccountSid is an OctetStream, I am wondering if this
> will work ... does anyone already have experience on this?

In Postfix, table lookup keys and result data are NUL-terminated
C strings.  So binary keys and values are not possible.

        const char *dict_lookup(dict_name, member)
        const char *dict_name;
        const char *member;

Internally, the Postfix LDAP table assumes that all attributes returned
in an LDAP query are NUL-terminated C-strings.  OpenLDAP appends a final
NUL even to binary data, but we don't check for absence of internal
NULs.

Also, the Postfix LDAP table folds keys to lower-case by default, and
IIRC you don't generally get to disable that when defining tables.

Bottom-line.  Sorry, no non-textual keys or values.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Postfix LDAP pipemap lookup tables and OctetStream

Luca Fornasari
On Thu, Feb 6, 2020 at 8:56 PM Viktor Dukhovni
<[hidden email]> wrote:

>
> On Thu, Feb 06, 2020 at 08:44:36AM +0100, Luca Fornasari wrote:
>
> > The idea is to use a pipemap of LDAP queries; the first LDAP query
> > [...]
> > Since msExchMasterAccountSid is an OctetStream, I am wondering if this
> > will work ... does anyone already have experience on this?
>
> In Postfix, table lookup keys and result data are NUL-terminated
> C strings.  So binary keys and values are not possible.
>
>         const char *dict_lookup(dict_name, member)
>         const char *dict_name;
>         const char *member;
>
> Internally, the Postfix LDAP table assumes that all attributes returned
> in an LDAP query are NUL-terminated C-strings.  OpenLDAP appends a final
> NUL even to binary data, but we don't check for absence of internal
> NULs.
>
> Also, the Postfix LDAP table folds keys to lower-case by default, and
> IIRC you don't generally get to disable that when defining tables.
>
> Bottom-line.  Sorry, no non-textual keys or values.
>
> --
>     Viktor.

Thanks Victor for your kind and detailed reply ... I should have read
the source code before asking.

Luca