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

290883Re: Postfix ldap_table authenticate to LDAP using GSSAPI or EXTERNAL

Expand Messages
  • Eric McCorkle
    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"

      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.
    • Show all 8 messages in this topic