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

Re: Postfix ldap_table authenticate to LDAP using GSSAPI or EXTERNAL

Expand Messages
  • Jerry
    On Tue, 22 Jan 2013 10:04:30 -0500 (EST) ... I think that should be: -- Jerry ✌
    Message 1 of 8 , Jan 22, 2013
      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 2 of 8 , Jan 22, 2013
        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 3 of 8 , Jan 22, 2013
          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 4 of 8 , Jan 22, 2013
            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 5 of 8 , Jan 22, 2013
              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.