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

GSSAPI with SMTP client

Expand Messages
  • Erinn Looney-Triggs
    I have been trying to get GSSAPI to work with postfix s smtp client. Essentially, what I already have is a postfix server that works with GSSAPI already
    Message 1 of 10 , Jul 1, 2013
    • 0 Attachment
      I have been trying to get GSSAPI to work with postfix's smtp client.
      Essentially, what I already have is a postfix server that works with
      GSSAPI already (tested via thunderbird), and I want postfix to use this
      server as a relay.

      I have found a couple of references:
      http://permalink.gmane.org/gmane.mail.postfix.user/214560
      https://groups.google.com/forum/#!msg/mailing.postfix.users/IiOwDMqklVE/aJ8nNUgpgP4J

      Which essentially say, grab a keytab, setup cron to pull a ticket via
      said keytab, set the import_environment to include KRB5CCNAME pointing
      to the cache and voilĂ  it should work. Except, of course, for me it doesn't.

      I am unsure whether this is operator error or some oddity with my setup,
      probably the former but the latter is a small possibility.

      So here is what I have:
      Two RHEL 6.4 hosts running identical versions of postfix 2.6.6.

      Server:
      Server is tested and working with GSSAPI auth from any external source.
      The only oddity perhaps, is that TLS is required for auth, which I
      believe the smtp client should support.

      Client:
      relayhost = smtp.myserver.com
      smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
      smtp_tls_session_cache_database =
      btree:${data_directory}/smtp_tls_session_cache
      smtp_tls_security_level = may
      import_environment =
      MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ LANG=C
      KRB5CCNAME=${data_directory}/kerberos/cache

      A cronjob that is working and confirmed on the client:
      @reboot kinit -c /var/lib/postfix/cache -k -t /etc/keytabs/smtp.keytab
      SMTP/$(uname -n)
      * 0-23/4 * * * kinit -c /var/lib/postfix/cache -k -t
      /etc/keytabs/smtp.keytab SMTP/$(uname -n)

      I have tried relocating the cache to /var/spool/postfix/kerberos without
      it making a difference.
      SELinux is in fact on, however there are no denial alerts and setting it
      to permissive doesn't solve the problem.

      All messages relayed from client to server are rejected since no auth is
      performed.

      There has to be something I am missing here. Suggestions?

      -Erinn
    • Viktor Dukhovni
      ... This sets the ticket cache to /var/lib/postfix/kerberos/cache Keep in mind that credential caches have a type, which should not generally be left out,
      Message 2 of 10 , Jul 1, 2013
      • 0 Attachment
        On Mon, Jul 01, 2013 at 03:18:03PM -0400, Erinn Looney-Triggs wrote:

        > relayhost = smtp.myserver.com
        > smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
        > smtp_tls_session_cache_database =
        > btree:${data_directory}/smtp_tls_session_cache
        > smtp_tls_security_level = may
        > import_environment =
        > MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ LANG=C
        > KRB5CCNAME=${data_directory}/kerberos/cache

        This sets the ticket cache to "/var/lib/postfix/kerberos/cache"

        Keep in mind that credential caches have a type, which should not
        generally be left out, use:

        KRB5CCNAME=FILE:${data_directory}/krb5_ccache

        > A cronjob that is working and confirmed on the client:
        > @reboot kinit -c /var/lib/postfix/cache -k -t /etc/keytabs/smtp.keytab
        > SMTP/$(uname -n)
        > * 0-23/4 * * * kinit -c /var/lib/postfix/cache -k -t
        > /etc/keytabs/smtp.keytab SMTP/$(uname -n)

        This places tickets in "/var/lib/postfix/cache", which is different
        from your environment, use:

        * 0-23/4 * * * kinit -c FILE:/var/lib/postfix/krb5_ccache -k -t /etc/keytabs/smtp.keytab smtp/$(uname -n)

        The GSSAPI service name for SMTP is "smtp" (just like in /etc/services)
        not "SMTP". The principal in the keytab must also be lower case.

        > I have tried relocating the cache to /var/spool/postfix/kerberos without
        > it making a difference.

        Postfix reads the credential cache as "postfix". Do the cron jobs run
        as "postfix" or as "root"?

        > There has to be something I am missing here. Suggestions?

        Multiple problems.

        - Missing ccache type
        - Inconsistent ccache name
        - Possibly wrong ccache owner
        - Wrong service name in keytab

        --
        Viktor.
      • Erinn Looney-Triggs
        ... Viktor, Thanks a lot, that fixed up a few things. I added the ccache type in. Spotting those ccache name differences was big. Changed smtp to lowercase for
        Message 3 of 10 , Jul 2, 2013
        • 0 Attachment
          On 07/01/2013 04:13 PM, Viktor Dukhovni wrote:
          > On Mon, Jul 01, 2013 at 03:18:03PM -0400, Erinn Looney-Triggs wrote:
          >
          >> relayhost = smtp.myserver.com
          >> smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
          >> smtp_tls_session_cache_database =
          >> btree:${data_directory}/smtp_tls_session_cache
          >> smtp_tls_security_level = may
          >> import_environment =
          >> MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ LANG=C
          >> KRB5CCNAME=${data_directory}/kerberos/cache
          >
          > This sets the ticket cache to "/var/lib/postfix/kerberos/cache"
          >
          > Keep in mind that credential caches have a type, which should not
          > generally be left out, use:
          >
          > KRB5CCNAME=FILE:${data_directory}/krb5_ccache
          >
          >> A cronjob that is working and confirmed on the client:
          >> @reboot kinit -c /var/lib/postfix/cache -k -t /etc/keytabs/smtp.keytab
          >> SMTP/$(uname -n)
          >> * 0-23/4 * * * kinit -c /var/lib/postfix/cache -k -t
          >> /etc/keytabs/smtp.keytab SMTP/$(uname -n)
          >
          > This places tickets in "/var/lib/postfix/cache", which is different
          > from your environment, use:
          >
          > * 0-23/4 * * * kinit -c FILE:/var/lib/postfix/krb5_ccache -k -t /etc/keytabs/smtp.keytab smtp/$(uname -n)
          >
          > The GSSAPI service name for SMTP is "smtp" (just like in /etc/services)
          > not "SMTP". The principal in the keytab must also be lower case.
          >
          >> I have tried relocating the cache to /var/spool/postfix/kerberos without
          >> it making a difference.
          >
          > Postfix reads the credential cache as "postfix". Do the cron jobs run
          > as "postfix" or as "root"?
          >
          >> There has to be something I am missing here. Suggestions?
          >
          > Multiple problems.
          >
          > - Missing ccache type
          > - Inconsistent ccache name
          > - Possibly wrong ccache owner
          > - Wrong service name in keytab
          >

          Viktor,
          Thanks a lot, that fixed up a few things.

          I added the ccache type in.
          Spotting those ccache name differences was big.
          Changed smtp to lowercase for the keytab, which it already was on the
          server so, uh yeah.
          The cron job was already running as postfix so things were fine there.

          However, it still is not working.

          Running a debug_peer_list with the verbosity set to 2 against both a
          thunderbird client working with GSSAPI and the postfix client. It
          appears that GSSAPI is not even being tried by the postfix client. It
          negotiates the TLS session, is presented with GSSAPI as an auth option,
          and then it just attempts to send the message (MAIL FROM etc.). Whereas
          the thunderbird client does the GSSAPI negotiation (AUTH GSSAPI etc.).

          I keep looking for some setting that I may have flipped somewhere.
          smtp_sasl_auth_enable looked promising, however, it doesn't appear to be
          applicable in the case.

          Thanks again for the help, and let me know if you have other thoughts,

          -Erinn
        • Viktor Dukhovni
          ... The destination needs to appear the smtp_sasl_password_maps database, even when you re not using a password-based mechanism. This tells Postfix to use
          Message 4 of 10 , Jul 2, 2013
          • 0 Attachment
            On Tue, Jul 02, 2013 at 11:25:53AM -0400, Erinn Looney-Triggs wrote:

            > However, it still is not working.
            >
            > Running a debug_peer_list with the verbosity set to 2 against both a
            > thunderbird client working with GSSAPI and the postfix client. It
            > appears that GSSAPI is not even being tried by the postfix client. It
            > negotiates the TLS session, is presented with GSSAPI as an auth option,
            > and then it just attempts to send the message (MAIL FROM etc.). Whereas
            > the thunderbird client does the GSSAPI negotiation (AUTH GSSAPI etc.).

            The destination needs to appear the smtp_sasl_password_maps database,
            even when you're not using a password-based mechanism. This tells
            Postfix to use SASL for the destination.

            [smtp.example.com]:587 gssapi:nopassword

            You naturally need to make sure that you've installed the GSSAPI
            plugin for SASL and that smtp_sasl_mechanism_filter is set correctly.

            --
            Viktor.
          • Erinn Looney-Triggs
            ... Viktor, Thanks for the help, after a lot more messing about, and debugging (Wietse, you the man for putting in debug_peer_list, very helpful) I finally got
            Message 5 of 10 , Jul 5, 2013
            • 0 Attachment
              On 07/02/2013 12:03 PM, Viktor Dukhovni wrote:
              > On Tue, Jul 02, 2013 at 11:25:53AM -0400, Erinn Looney-Triggs wrote:
              >
              >> However, it still is not working.
              >>
              >> Running a debug_peer_list with the verbosity set to 2 against both a
              >> thunderbird client working with GSSAPI and the postfix client. It
              >> appears that GSSAPI is not even being tried by the postfix client. It
              >> negotiates the TLS session, is presented with GSSAPI as an auth option,
              >> and then it just attempts to send the message (MAIL FROM etc.). Whereas
              >> the thunderbird client does the GSSAPI negotiation (AUTH GSSAPI etc.).
              >
              > The destination needs to appear the smtp_sasl_password_maps database,
              > even when you're not using a password-based mechanism. This tells
              > Postfix to use SASL for the destination.
              >
              > [smtp.example.com]:587 gssapi:nopassword
              >
              > You naturally need to make sure that you've installed the GSSAPI
              > plugin for SASL and that smtp_sasl_mechanism_filter is set correctly.
              >

              Viktor,
              Thanks for the help, after a lot more messing about, and debugging
              (Wietse, you the man for putting in debug_peer_list, very helpful) I
              finally got this working.

              All the constituent parts where there but the syntax for the sasl
              password maps database was incorrect (my fault), which client side
              debugging revealed as it wasn't matching the mail server host.

              I am going to write up a little how to for this and post it on up.
              Hopefully it will make folks lives easier if they decide to do this in
              the future.

              Thanks again,
              -Erinn
            • Erinn Looney-Triggs
              ... Just for posterity, I put together a set of instructions on how to do this beginning to end here:
              Message 6 of 10 , Jul 10, 2013
              • 0 Attachment
                On 07/02/2013 12:03 PM, Viktor Dukhovni wrote:
                > On Tue, Jul 02, 2013 at 11:25:53AM -0400, Erinn Looney-Triggs wrote:
                >
                >> However, it still is not working.
                >>
                >> Running a debug_peer_list with the verbosity set to 2 against both a
                >> thunderbird client working with GSSAPI and the postfix client. It
                >> appears that GSSAPI is not even being tried by the postfix client. It
                >> negotiates the TLS session, is presented with GSSAPI as an auth option,
                >> and then it just attempts to send the message (MAIL FROM etc.). Whereas
                >> the thunderbird client does the GSSAPI negotiation (AUTH GSSAPI etc.).
                >
                > The destination needs to appear the smtp_sasl_password_maps database,
                > even when you're not using a password-based mechanism. This tells
                > Postfix to use SASL for the destination.
                >
                > [smtp.example.com]:587 gssapi:nopassword
                >
                > You naturally need to make sure that you've installed the GSSAPI
                > plugin for SASL and that smtp_sasl_mechanism_filter is set correctly.
                >

                Just for posterity, I put together a set of instructions on how to do
                this beginning to end here:
                https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/

                Though it uses FreeIPA you can easily just use straight kerberos tools
                like kadmin.

                Viktor, thanks again for the help.

                -Erinn
              • Viktor Dukhovni
                ... If active man-in-middle-attacks are a plausible risk, you should look into making TLS mandatory and authenticating the server. GSSAPI inside TLS currently
                Message 7 of 10 , Jul 11, 2013
                • 0 Attachment
                  On Wed, Jul 10, 2013 at 09:17:40PM -0400, Erinn Looney-Triggs wrote:

                  > Just for posterity, I put together a set of instructions on how to do
                  > this beginning to end here:
                  >
                  > https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/
                  >
                  > Though it uses FreeIPA you can easily just use straight kerberos tools
                  > like kadmin.

                  If active man-in-middle-attacks are a plausible risk, you should
                  look into making TLS mandatory and authenticating the server.

                  GSSAPI inside TLS currently does not perform channel binding, and
                  so your session can be hijacked, after the client authenticates
                  with GSSAPI. You can use "fingerprint" security if your server
                  certificate is not signed by a usable CA.

                  As for where to keep non-system keytabs, there is some precedent for
                  using /var/spool/keytabs/.

                  Finally, the main.cf fragment in the document does not indent the
                  continuation lines for import_environment correctly. I would also
                  avoid the double-spacing.

                  --
                  Viktor.
                • Erinn Looney-Triggs
                  ... Viktor, Thanks for giving it a read through and for the feedback. I ll make some adjustments. However, do you have a bit more info about what you mean by
                  Message 8 of 10 , Jul 11, 2013
                  • 0 Attachment
                    On 07/11/2013 10:01 AM, Viktor Dukhovni wrote:
                    > On Wed, Jul 10, 2013 at 09:17:40PM -0400, Erinn Looney-Triggs wrote:
                    >
                    >> Just for posterity, I put together a set of instructions on how to do
                    >> this beginning to end here:
                    >>
                    >> https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/
                    >>
                    >> Though it uses FreeIPA you can easily just use straight kerberos tools
                    >> like kadmin.
                    >
                    > If active man-in-middle-attacks are a plausible risk, you should
                    > look into making TLS mandatory and authenticating the server.
                    >
                    > GSSAPI inside TLS currently does not perform channel binding, and
                    > so your session can be hijacked, after the client authenticates
                    > with GSSAPI. You can use "fingerprint" security if your server
                    > certificate is not signed by a usable CA.
                    >
                    > As for where to keep non-system keytabs, there is some precedent for
                    > using /var/spool/keytabs/.
                    >
                    > Finally, the main.cf fragment in the document does not indent the
                    > continuation lines for import_environment correctly. I would also
                    > avoid the double-spacing.
                    >

                    Viktor,
                    Thanks for giving it a read through and for the feedback. I'll make some
                    adjustments. However, do you have a bit more info about what you mean by
                    channel binding? A link, something along those lines just so I can
                    understand the concepts here.

                    -Erinn
                  • Viktor Dukhovni
                    ... https://tools.ietf.org/html/rfc5056 -- Viktor.
                    Message 9 of 10 , Jul 11, 2013
                    • 0 Attachment
                      On Thu, Jul 11, 2013 at 11:23:50AM -0400, Erinn Looney-Triggs wrote:

                      > > GSSAPI inside TLS currently does not perform channel binding, and
                      > > so your session can be hijacked, after the client authenticates
                      > > with GSSAPI. You can use "fingerprint" security if your server
                      > > certificate is not signed by a usable CA.
                      >
                      > However, do you have a bit more info about what you mean by
                      > channel binding? A link, something along those lines just so I can
                      > understand the concepts here.

                      https://tools.ietf.org/html/rfc5056

                      --
                      Viktor.
                    • Erinn Looney-Triggs
                      ... Viktor, Thanks again for the feedback, I updated the article. If you want to take a look at it again and have any more feedback feel free to send it along.
                      Message 10 of 10 , Jul 18, 2013
                      • 0 Attachment
                        On 07/11/2013 07:45 AM, Viktor Dukhovni wrote:
                        > On Thu, Jul 11, 2013 at 11:23:50AM -0400, Erinn Looney-Triggs wrote:
                        >
                        >>> GSSAPI inside TLS currently does not perform channel binding, and
                        >>> so your session can be hijacked, after the client authenticates
                        >>> with GSSAPI. You can use "fingerprint" security if your server
                        >>> certificate is not signed by a usable CA.
                        >>
                        >> However, do you have a bit more info about what you mean by
                        >> channel binding? A link, something along those lines just so I can
                        >> understand the concepts here.
                        >
                        > https://tools.ietf.org/html/rfc5056
                        >

                        Viktor,
                        Thanks again for the feedback, I updated the article. If you want to
                        take a look at it again and have any more feedback feel free to send it
                        along.

                        https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/

                        -Erinn
                      Your message has been successfully submitted and would be delivered to recipients shortly.