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

Re: GSSAPI SMTPD Authentication and MS Active Directory

Expand Messages
  • Quanah Gibson-Mount
    --On Wednesday, April 24, 2013 5:35 PM -0700 Matthew Larsen ... If you replaced Exchange 2003 with Zimbra, and set up external auth to your AD server, then it
    Message 1 of 8 , Apr 24 5:57 PM
    View Source
    • 0 Attachment
      --On Wednesday, April 24, 2013 5:35 PM -0700 Matthew Larsen
      <utegrad@...> wrote:

      >
      >
      > I'm working on a project to replace an Exchange 2003 server that is only
      > still around these days because we have lots of SMTP clients around the
      > country that use it as an SMTP relay.  It only relays messages for
      > clients authenticated by our Active Directory domain.  Members of a
      > group in the parent domain and a group in the child domain are given
      > relay permissions for this server.  

      If you replaced Exchange 2003 with Zimbra, and set up external auth to your
      AD server, then it would use the custom zimbra authentication method for
      cyrus-sasl to auth your clients against AD. I don't know what you intend
      on replacing Exchange with though, so that may be a bit more than you want.
      But it is a solution.

      If you want to use SASL/GSSAPI, the clients have to be able to get a TGT
      from the KDC.

      Alternatively, you could just do straight ldap authentication against AD,
      instead of Kerberos-AD, something like:

      <http://www.howtoforge.com/postfix-dovecot-authentication-against-active-directory-on-centos-5.x>

      --Quanah


      --

      Quanah Gibson-Mount
      Sr. Member of Technical Staff
      Zimbra, Inc
      A Division of VMware, Inc.
      --------------------
      Zimbra :: the leader in open source messaging and collaboration
    • Matthew Larsen
      On Wed, Apr 24, 2013 at 5:57 PM, Quanah Gibson-Mount
      Message 2 of 8 , Apr 25 12:27 PM
      View Source
      • 0 Attachment
        On Wed, Apr 24, 2013 at 5:57 PM, Quanah Gibson-Mount <quanah@...> wrote:

        If you replaced Exchange 2003 with Zimbra, and set up external auth to your AD server, then it would use the custom zimbra authentication method for cyrus-sasl to auth your clients against AD.  I don't know what you intend on replacing Exchange with though, so that may be a bit more than you want. But it is a solution.

        Zimbra would be more than I want in this case.  All I need is a secure authenticated SMTP server, and it would be nice to have a GUI to monitor the message queues.  My thought has been that Postfix with webmin would be a good fit if I can get the authentication to work with Active Directory. 

         
        Ifyou want to use SASL/GSSAPI, the clients have to be able to get a TGT from the KDC.

        The reason I've been looking at configuring the SASL/GSSAPI mechanism is that's what I see the current Exchange server doing.  I'm hoping to build something I can drop in place without needing to touch client systems for reconfiguration. 

        I'm just puzzled as to how this works because the clients aren't members of our AD domain, and I strongly doubt they have data for, or access to, the DNS servers in the domain or a KDC.  All they are given is an SMTP server, username (DOMAIN\Username), and password. 

        It's also my understanding that the GSSAPI mechanism is more secure on the wire than a plain text authentication method without TLS.  Is that accurate? 

        I'm not sure that my understanding of the security of the GSSAPI method is accurate, or that the infrastructure is there in this case to support doing this with Postfix?

        Here's a screen shot of an SMTP authentication exchange taken from a wireshark trace on the Exchange server.
         

        Any pointers or further information on this works would be appreciated. 

         
        Alternatively,you could just do straight ldap authentication against AD, instead of Kerberos-AD, something like:

        <http://www.howtoforge.com/postfix-dovecot-authentication-against-active-directory-on-centos-5

         I'll check out the LDAP authentication setup.  Hopefully as I gain a better understanding of other possible pieces of this configuration the whole thing will start to gel together for me. 


        Thanks,
        ML


      • Quanah Gibson-Mount
        --On Thursday, April 25, 2013 12:27 PM -0700 Matthew Larsen ... But exchange knows about your domain, correct? And how to authenticate users to AD? ...
        Message 3 of 8 , Apr 25 12:41 PM
        View Source
        • 0 Attachment
          --On Thursday, April 25, 2013 12:27 PM -0700 Matthew Larsen
          <utegrad@...> wrote:

          >> If you want to use SASL/GSSAPI, the clients have to be able to get a TGT
          >> from the KDC.

          > The reason I've been looking at configuring the SASL/GSSAPI mechanism is
          > that's what I see the current Exchange server doing.  I'm hoping to
          > build something I can drop in place without needing to touch client
          > systems for reconfiguration. 

          But exchange knows about your domain, correct? And how to authenticate
          users to AD?

          > I'm just puzzled as to how this works because the clients aren't
          > members of our AD domain, and I strongly doubt they have data for, or
          > access to, the DNS servers in the domain or a KDC.  All they are given
          > is an SMTP server, username (DOMAIN\Username), and password. 

          Because Exchange is cheating and doing the kerberos auth for them to AD?
          I.e., it isn't the clients themselves doing SASL/GSSAPI, correct? It is
          exchange?

          > It's also my understanding that the GSSAPI mechanism is more secure on
          > the wire than a plain text authentication method without TLS.  Is that
          > accurate? 

          Any form of encryption is more secure than plain text... so yes, that is a
          correct statement.

          --Quanah

          --

          Quanah Gibson-Mount
          Sr. Member of Technical Staff
          Zimbra, Inc
          A Division of VMware, Inc.
          --------------------
          Zimbra :: the leader in open source messaging and collaboration
        • Matthew Larsen
          ... Yes. ... I guess that s what I m asking, and it would make sense. Exchange would be both the client and service in the Kerberos exchange if that s the
          Message 4 of 8 , Apr 25 12:48 PM
          View Source
          • 0 Attachment
            On 4/25/2013 12:41 PM, Quanah Gibson-Mount wrote:
            > --On Thursday, April 25, 2013 12:27 PM -0700 Matthew Larsen
            > <utegrad@...> wrote:
            >
            >>> If you want to use SASL/GSSAPI, the clients have to be able to get a TGT
            >>> from the KDC.
            >
            >> The reason I've been looking at configuring the SASL/GSSAPI mechanism is
            >> that's what I see the current Exchange server doing. I'm hoping to
            >> build something I can drop in place without needing to touch client
            >> systems for reconfiguration.
            >
            > But exchange knows about your domain, correct? And how to authenticate
            > users to AD?

            Yes.

            >
            >> I'm just puzzled as to how this works because the clients aren't
            >> members of our AD domain, and I strongly doubt they have data for, or
            >> access to, the DNS servers in the domain or a KDC. All they are given
            >> is an SMTP server, username (DOMAIN\Username), and password.
            >
            > Because Exchange is cheating and doing the kerberos auth for them to AD?
            > I.e., it isn't the clients themselves doing SASL/GSSAPI, correct? It is
            > exchange?
            >

            I guess that's what I'm asking, and it would make sense. Exchange would
            be both the client and service in the Kerberos exchange if that's the
            case. Can Postfix / SASL be made to do the same?
          • Viktor Dukhovni
            ... What evidence do you have that the server is doing GSSAPI? It seems likely you re mistaken. Simply listing GSSAPI as a supported SASL AUTH mechanism is
            Message 5 of 8 , Apr 25 1:02 PM
            View Source
            • 0 Attachment
              On Thu, Apr 25, 2013 at 12:27:59PM -0700, Matthew Larsen wrote:

              > >
              > > If you want to use SASL/GSSAPI, the clients have to be able to get
              > > a TGT from the KDC.
              > >
              >
              > The reason I've been looking at configuring the SASL/GSSAPI
              > mechanism is that's what I see the current Exchange server doing.

              What evidence do you have that the server is "doing" GSSAPI? It
              seems likely you're mistaken. Simply listing GSSAPI as a supported
              SASL AUTH mechanism is not "doing" GSSAPI, the client would actually
              have to use GSSAPI. It is quite possible your client's IP address
              was whitelisted on the Exchange servers, or access was unrestricted, ...

              > I'm just puzzled as to how this works because the clients aren't
              > members of our AD domain, and I strongly doubt they have data for,
              > or access to, the DNS servers in the domain or a KDC. All they are
              > given is an SMTP server, username (DOMAIN\Username), and password.

              The clients may be doing NTLM or PLAIN or nothing at all. You need
              to figure out what's actually used. If TLS is not in use a simple
              packet capture plus wireshark or similar will show you exactly what
              the client and server are doing.

              > I'm not sure that my understanding of the security of the GSSAPI
              > method is accurate, or that the infrastructure is there in this case
              > to support doing this with Postfix?

              The Postfix SMTP client if compiled with Cyrus SASL support, and
              provided the Cyrus SASL gssapi plugin is installed will do GSSAPI.
              There is no GSSAPI-specific code in Postfix, all the logic is in
              Cyrus SASL. However, you need to specify a KRB5CCNAME in the
              client's environment that is readable by the "postfix" user and
              contains valid tickets at all times. To do this, run a cron-job
              periodically that uses a keytab file to populate the credential
              cache with freshly valid tickets.

              If the above is just a bunch of greek to you, you want to look for
              alternatives to GSSAPI.

              > I'll check out the LDAP authentication setup. Hopefully as I gain
              > a better understanding of other possible pieces of this
              > configuration the whole thing will start to gel together for me.

              If you replace the Exchange servers with Postfix, you can support
              any of the following authorization methods:

              - Allow any client to send anywhere (internal open relay).
              - Whitelist the particular sending IPs.
              - Allow the clients to send via authorized TLS client certs.
              - Allow the clients to send via any mutually supported SASL
              mechanism, including PLAIN and/or GSSAPI.

              For server-side GSSAPI support the server will need a keytab file
              containing shared keys with the appropriate realm's KDCs.

              --
              Viktor.
            • Matthew Larsen
              ... My apologies. I am mistaken about how this is happening. Sometimes it s a challenge to get accurate information from a different division that takes care
              Message 6 of 8 , Apr 25 2:39 PM
              View Source
              • 0 Attachment
                On 4/25/2013 1:02 PM, Viktor Dukhovni wrote:
                > What evidence do you have that the server is "doing" GSSAPI? It
                > seems likely you're mistaken. Simply listing GSSAPI as a supported
                > SASL AUTH mechanism is not "doing" GSSAPI, the client would actually
                > have to use GSSAPI. It is quite possible your client's IP address
                > was whitelisted on the Exchange servers, or access was unrestricted, ...

                My apologies. I am mistaken about how this is happening. Sometimes it's
                a challenge to get accurate information from a different division that
                takes care of this client system.

                The computers running the SMTP client software are members of a child
                domain in our AD forest, there's a VPN between those computers and a
                different segment of our network housing the child domain AD
                infrastructure, but for some reason (probably bandwidth and latency) the
                SMTP client is connecting over the public Internet connection at the
                client sites rather than the VPN. I think that mostly explains how the
                infrastructure is there to use Kerberos for authentication.

                Here's what I see it doing with wireshark on the server.

                A screen shot of some of what I see:
                http://img94.imageshack.us/img94/2579/gssapismtpauth.png

                The gist of it is

                S: 220 mail.exch01.com ...
                C: EHLO NETBIOSName
                S: 250-mail.exch01.com Hello [ip.addr.of.client] | 250- ... several
                items including AUTH GSSAPI NTLM LOGIN among others ....
                C: AUTH gssapi ...long string...
                S: 334 ...long string...
                C: ...long string...
                S: 235 2.7.0 Authentication successful.
                C: MAIL FROM:<sending@...>
                S: 250 2.1.0 sending@... ... Sender OK
                C: RCPT TO:<somebody@...>
                S: 250 2.1.5 somebody@...
                C: DATA
                S: 354 Start mail input; end with <CRLF>.<CRLF>
                ... blah blah blah ...

                > The clients may be doing NTLM or PLAIN or nothing at all. You need
                > to figure out what's actually used. If TLS is not in use a simple
                > packet capture plus wireshark or similar will show you exactly what
                > the client and server are doing.

                In addition to what I see in Wireshark, the event log shows it's using
                GSSAPI when I turn on the MSTransport authentication logging level to debug.

                Event Type: Information
                Event Source: MSExchangeTransport
                Event Category: Authentication
                Event ID: 1708
                Date: 4/25/2013
                Time: 11:17:49 AM
                User: N/A
                Computer: EXCH01
                Description:
                SMTP Authentication was performed successfully with client "A510E". The
                authentication method was "GSSAPI" and the username was "MYDOMAIN\AAA".


                >> I'm not sure that my understanding of the security of the GSSAPI
                >> method is accurate, or that the infrastructure is there in this case
                >> to support doing this with Postfix?
                > The Postfix SMTP client if compiled with Cyrus SASL support, and
                > provided the Cyrus SASL gssapi plugin is installed will do GSSAPI.
                > There is no GSSAPI-specific code in Postfix, all the logic is in
                > Cyrus SASL. However, you need to specify a KRB5CCNAME in the
                > client's environment that is readable by the "postfix" user and
                > contains valid tickets at all times. To do this, run a cron-job
                > periodically that uses a keytab file to populate the credential
                > cache with freshly valid tickets.
                >
                > If the above is just a bunch of greek to you, you want to look for
                > alternatives to GSSAPI.

                It's not entirely greek, but I'm trying to learn more greek. However, I
                don't believe that I need the Postifix client to do any authentication
                other than anonymous. It would be relaying messages from authenticated
                clients to Internet recipients via MX records. I'm only trying to
                configure the stmpd portion of Postfix for secure authentication.

                > If you replace the Exchange servers with Postfix, you can support
                > any of the following authorization methods:
                >
                > - Allow any client to send anywhere (internal open relay).
                > - Whitelist the particular sending IPs.
                > - Allow the clients to send via authorized TLS client certs.
                > - Allow the clients to send via any mutually supported SASL
                > mechanism, including PLAIN and/or GSSAPI.
                >
                > For server-side GSSAPI support the server will need a keytab file
                > containing shared keys with the appropriate realm's KDCs.

                The fourth option listed is what I'm trying to accomplish with GSSAPI,
                but have been finding challenging to get working. I'll go back over my
                configuration a time or two and try and find something specific that
                will point to where it's not working.
              • Viktor Dukhovni
                ... So GSSAPI it is and the clients already have GSS credentials. ... You ll need to use the Microsoft command-line tools for to create SPN s (service
                Message 7 of 8 , Apr 25 6:43 PM
                View Source
                • 0 Attachment
                  On Thu, Apr 25, 2013 at 02:39:28PM -0700, Matthew Larsen wrote:

                  > The gist of it is
                  >
                  > S: 220 mail.exch01.com ...
                  > C: EHLO NETBIOSName
                  > S: 250-mail.exch01.com Hello [ip.addr.of.client] | 250- ... several
                  > items including AUTH GSSAPI NTLM LOGIN among others ....
                  > C: AUTH gssapi ...long string...
                  > S: 334 ...long string...
                  > C: ...long string...
                  > S: 235 2.7.0 Authentication successful.

                  So GSSAPI it is and the clients already have GSS credentials.

                  > >If the above is just a bunch of greek to you, you want to look for
                  > >alternatives to GSSAPI.
                  >
                  > It's not entirely greek, but I'm trying to learn more greek.
                  > However, I don't believe that I need the Postifix client to do any
                  > authentication other than anonymous. It would be relaying messages
                  > from authenticated clients to Internet recipients via MX records.
                  > I'm only trying to configure the stmpd portion of Postfix for secure
                  > authentication.
                  >
                  > >If you replace the Exchange servers with Postfix, you can support
                  > >any of the following authorization methods:
                  > >
                  > > - Allow any client to send anywhere (internal open relay).
                  > > - Whitelist the particular sending IPs.
                  > > - Allow the clients to send via authorized TLS client certs.
                  > > - Allow the clients to send via any mutually supported SASL
                  > > mechanism, including PLAIN and/or GSSAPI.
                  > >
                  > >For server-side GSSAPI support the server will need a keytab file
                  > >containing shared keys with the appropriate realm's KDCs.
                  >
                  > The fourth option listed is what I'm trying to accomplish with
                  > GSSAPI, but have been finding challenging to get working. I'll go
                  > back over my configuration a time or two and try and find something
                  > specific that will point to where it's not working.

                  You'll need to use the Microsoft command-line tools for to create
                  "SPN"s (service principals) for smtp/<hostname> for each new host
                  on which you plan to install Postfix. Then another tool to extract
                  a keytab file for each SPN. The keytab file will need to installed
                  mode 0600 owned by "postfix".

                  The Postfix SMTP server will need:

                  import_environment = ... KRB5_KTNAME=FILE:/path/of/keytab/file

                  where "..." includes all the default values of import_environment. It
                  is also possible to delegate all the work of doing GSSAPI auth to dovecot,
                  in which case the dovecot keytab will need to contain keys for both
                  imap and smtp (or perhaps just smtp if dovecot is not used for imap),
                  or choose gssapi as the mechanism in smtpd.conf for Cyrus SASL.

                  The clients will need to be reconfigured to connect to a new set of
                  server hosts.

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