Loading ...
Sorry, an error occurred while loading the content.

Postfix ldap_table authenticate to LDAP using GSSAPI or EXTERNAL

Expand Messages
  • Eric McCorkle
    Hello, I am trying to set up an LDAP-based alias table, and I want postfix to authenticate to LDAP using a Kerberos service principal, or at least using the
    Message 1 of 8 , Jan 21, 2013
    • 0 Attachment
      Hello,

      I am trying to set up an LDAP-based alias table, and I want postfix to
      authenticate to LDAP using a Kerberos service principal, or at least
      using the EXTERNAL method (SSL certificate authentication).

      The ldap-aliases.cf file looks like this (domains and realms changed):

      server_host = ldap://ldap.example.com/
      search_base = ou=people,dc=metricspace,dc=net
      version = 3
      bind = sasl
      sasl_mechs = EXTERNAL
      sasl_realm = EXAMPLE.COM
      scope = sub
      query_filter = mail=%s
      result_attribute = maildrop
      start_tls = yes
      tls_ca_cert_file = /etc/ssl/certs/ca-cert.pem
      tls_cert = /etc/ssl/certs/host-cert.pem
      tls_key = /etc/ssl/private/host-key.pem
      tls_require_cert = yes

      master.cf looks like this:

      smtp inet n - n - - smtpd
      smtps inet n - n - - smtpd -o
      smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o
      smtpd_client_restrictions=permit_sasl_authenticated,reject
      pickup fifo n - n 60 1 pickup
      cleanup unix n - n - 0 cleanup
      qmgr fifo 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


      Interestingly, postalias works fine with this setup, but when I start
      postfix, it complains as follows:

      postfix/local[82350]: warning: dict_ldap_set_tls_options: Unable to
      allocate new TLS context -1: Can't contact LDAP server
      postfix/postmap[44248]: fatal: table
      ldap:/usr/local/etc/postfix/ldap/ldap-aliases.cf: query error: Bad file
      descriptor

      Interestingly, postalias run from the command line seems to work just
      fine. More interestingly, using an ldap-based local_recipients_maps
      seems to work just fine, but alias_maps fails as described.


      The keys and the keytables are both accessible by the postfix user.
      This leads me to believe that it's either something subtle wrong with
      the file permissions, or there's a bug in postfix.

      There is a new feature in MIT Kerberos which allows a client key table
      to be set (via the KRB5_CLIENT_KTNAME environment variable), which will
      be used to automatically update and refresh the credentials cache. When
      I set this to point to a key table and update ldap-aliases.cf to use
      GSSAPI, postalias works, and the credentials cache gets updated, but the
      postfix daemon fails in the same way.


      My version is 2.4.9, installed as a FreeBSD port, and I am using openSSL
      (ie *not* GNUTLS).


      Thanks,
      Eric
    • Wietse Venema
      ... You run postalias as root. Postfix runs as a daemon, and minimizes usage of root privileges. If you have SElinux, root shell users and Postfix daemons may
      Message 2 of 8 , Jan 22, 2013
      • 0 Attachment
        Eric McCorkle:
        > Interestingly, postalias run from the command line seems to work just
        > fine. More interestingly, using an ldap-based local_recipients_maps
        > seems to work just fine, but alias_maps fails as described.

        You run postalias as root. Postfix runs as a daemon, and minimizes
        usage of root privileges.

        If you have SElinux, root shell users and Postfix daemons may be
        subject to different policies.

        > There is a new feature in MIT Kerberos which allows a client key table
        > to be set (via the KRB5_CLIENT_KTNAME environment variable), which will

        Another difference is that root shell user environment settings
        differ from those of Postfix daemons. Look at the output from
        "postconf import_environment export_evironment". More information
        about these is in http://www.postconf.5.html#export_evironment etc.

        Wietse
      • Viktor Dukhovni
        ... I would recommend GSSAPI (Kerberos) if that s an option, over EXTERNAL, key management is easier. To use GSSAPI, arrange for a cron job that runs once an
        Message 3 of 8 , Jan 22, 2013
        • 0 Attachment
          On Mon, Jan 21, 2013 at 09:05:33PM -0500, Eric McCorkle wrote:

          > I am trying to set up an LDAP-based alias table, and I want postfix to
          > authenticate to LDAP using a Kerberos service principal, or at least
          > using the EXTERNAL method (SSL certificate authentication).

          I would recommend GSSAPI (Kerberos) if that's an option, over
          EXTERNAL, key management is easier.

          To use GSSAPI, arrange for a cron job that runs once an hour or so,
          and executes

          $ kinit -k -t FILE:/some/keytab -c FILE:/some/cred-cache principal

          as Wietse points out: make sure the cred-cache is readable by the
          "postfix" user ($mail_owner). Then make sure that the KRB5CCNAME
          environment variable is set to point at the above credential cache
          in the Postfix delivery agent, by setting:

          import_environment =
          ... default value ...
          KRB5CCNAME=FILE:/some/cred-cache

          Unfortunately, Postfix does not yet support a "+= syntax" in main.cf.

          --
          Viktor.
        • Jerry
          On Tue, 22 Jan 2013 10:04:30 -0500 (EST) ... I think that should be: -- Jerry ✌
          Message 4 of 8 , Jan 22, 2013
          • 0 Attachment
            On Tue, 22 Jan 2013 10:04:30 -0500 (EST)
            Wietse Venema articulated:

            > Another difference is that root shell user environment settings
            > differ from those of Postfix daemons. Look at the output from
            > "postconf import_environment export_evironment". More information
            > about these is in http://www.postconf.5.html#export_evironment etc.

            I think that should be:
            <http://www.postfix.com/postconf.5.html#export_environment>

            --
            Jerry ✌
            postfix-user@...
            _____________________________________________________________________
            TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
            TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

            If you want to know how old a man is, ask his brother-in-law.
          • Eric McCorkle
            ... Ran postalias su ed to the postfix user, and it still worked. Also, I m using local_recipients_maps defined in LDAP (using EXTERNAL authentication,
            Message 5 of 8 , Jan 22, 2013
            • 0 Attachment
              On 01/22/13 10:04, Wietse Venema wrote:
              > Eric McCorkle:
              >> Interestingly, postalias run from the command line seems to work just
              >> fine. More interestingly, using an ldap-based local_recipients_maps
              >> seems to work just fine, but alias_maps fails as described.
              >
              > You run postalias as root. Postfix runs as a daemon, and minimizes
              > usage of root privileges.

              Ran postalias su'ed to the postfix user, and it still worked. Also, I'm
              using local_recipients_maps defined in LDAP (using EXTERNAL
              authentication, haven't tried GSSAPI yet) and it works just fine. Is
              there some reason why the process that checks aliases (local, I believe)
              wouldn't be able to get at the keys?

              > If you have SElinux, root shell users and Postfix daemons may be
              > subject to different policies.

              Nope, it's on a FreeBSD system.


              > Another difference is that root shell user environment settings
              > differ from those of Postfix daemons. Look at the output from
              > "postconf import_environment export_evironment". More information
              > about these is in http://www.postconf.5.html#export_evironment etc.

              I added KRB5_CLIENT_KTNAME to import_environment and export_environment
              in my main.cf, but it didn't seem to help, though this did yield a clue.

              If I have just a plain ldap connection with GSSAPI authentication
              (ldap://ldap.example.com), then I get the following:

              postfix/local[49728]: warning: dict_ldap_connect: Unable to bind to
              server ldap://ldap.example.com/ with dn empty or implicit: -2 (Local error)

              Which is due ultimately to there not being a kerberos principal
              available. However, if I add "start_tls = yes" (and set up the
              certificate files), then I get the same "unable to allocate TLS context"
              error.

              This seems to suggest that the process can't get at the certs (or the
              keytab), but both are readable by the postfix user, and postalias su'ed
              to postfix seems to work fine.


              Not sure if it's relevant, but I have the private key and the keytab
              with permissions set as follows:

              chown root:hostkey <path to key>
              chmod 640 <path to key>

              Where the "hostkey" group includes the postfix user.
            • Viktor Dukhovni
              ... This does not work, Postfix daemons don t run with the secondary groups of the postfix user. To use a client certificate for LDAP you must make it
              Message 6 of 8 , Jan 22, 2013
              • 0 Attachment
                On Wed, Jan 23, 2013 at 12:33:01AM -0500, Eric McCorkle wrote:

                > Which is due ultimately to there not being a kerberos principal
                > available. However, if I add "start_tls = yes" (and set up the
                > certificate files), then I get the same "unable to allocate TLS context"
                > error.
                >
                > This seems to suggest that the process can't get at the certs (or the
                > keytab), but both are readable by the postfix user, and postalias su'ed
                > to postfix seems to work fine.
                >
                > Not sure if it's relevant, but I have the private key and the keytab
                > with permissions set as follows:
                >
                > chown root:hostkey <path to key>
                > chmod 640 <path to key>
                >
                > Where the "hostkey" group includes the postfix user.

                This does not work, Postfix daemons don't run with the secondary
                groups of the "postfix" user. To use a client certificate for
                LDAP you must make it readable by the "postfix" user, via:

                chown postfix client-key.pem
                chmod 600 client-key.pem

                The "root" user can still read if required.

                --
                Viktor.
              • Eric McCorkle
                ... Well, then that would be the cause. I ll check it out, but in the mean time, thanks for the help!
                Message 7 of 8 , Jan 22, 2013
                • 0 Attachment
                  On 01/23/13 00:49, Viktor Dukhovni wrote:
                  > On Wed, Jan 23, 2013 at 12:33:01AM -0500, Eric McCorkle wrote:
                  >
                  >> Which is due ultimately to there not being a kerberos principal
                  >> available. However, if I add "start_tls = yes" (and set up the
                  >> certificate files), then I get the same "unable to allocate TLS context"
                  >> error.
                  >>
                  >> This seems to suggest that the process can't get at the certs (or the
                  >> keytab), but both are readable by the postfix user, and postalias su'ed
                  >> to postfix seems to work fine.
                  >>
                  >> Not sure if it's relevant, but I have the private key and the keytab
                  >> with permissions set as follows:
                  >>
                  >> chown root:hostkey <path to key>
                  >> chmod 640 <path to key>
                  >>
                  >> Where the "hostkey" group includes the postfix user.
                  >
                  > This does not work, Postfix daemons don't run with the secondary
                  > groups of the "postfix" user. To use a client certificate for
                  > LDAP you must make it readable by the "postfix" user, via:
                  >
                  > chown postfix client-key.pem
                  > chmod 600 client-key.pem
                  >
                  > The "root" user can still read if required.
                  >

                  Well, then that would be the cause. I'll check it out, but in the mean
                  time, thanks for the help!
                • Eric McCorkle
                  ... Yep, that did it. Thanks.
                  Message 8 of 8 , Jan 22, 2013
                  • 0 Attachment
                    On 01/23/13 00:51, Eric McCorkle wrote:
                    > On 01/23/13 00:49, Viktor Dukhovni wrote:
                    >> On Wed, Jan 23, 2013 at 12:33:01AM -0500, Eric McCorkle wrote:
                    >>
                    >>> Which is due ultimately to there not being a kerberos principal
                    >>> available. However, if I add "start_tls = yes" (and set up the
                    >>> certificate files), then I get the same "unable to allocate TLS context"
                    >>> error.
                    >>>
                    >>> This seems to suggest that the process can't get at the certs (or the
                    >>> keytab), but both are readable by the postfix user, and postalias su'ed
                    >>> to postfix seems to work fine.
                    >>>
                    >>> Not sure if it's relevant, but I have the private key and the keytab
                    >>> with permissions set as follows:
                    >>>
                    >>> chown root:hostkey <path to key>
                    >>> chmod 640 <path to key>
                    >>>
                    >>> Where the "hostkey" group includes the postfix user.
                    >>
                    >> This does not work, Postfix daemons don't run with the secondary
                    >> groups of the "postfix" user. To use a client certificate for
                    >> LDAP you must make it readable by the "postfix" user, via:
                    >>
                    >> chown postfix client-key.pem
                    >> chmod 600 client-key.pem
                    >>
                    >> The "root" user can still read if required.
                    >>
                    >
                    > Well, then that would be the cause. I'll check it out, but in the mean
                    > time, thanks for the help!
                    >

                    Yep, that did it. Thanks.
                  Your message has been successfully submitted and would be delivered to recipients shortly.