SASL binds

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

SASL binds

Brendan Kearney
i am looking to get SASL binds working in Postfix for user, group and
alias lookups, and i am not sure what i might be doing wrong.

Postfix version - 3.0.3 running on Fedora 22.  MIT Kerberos and OpenLDAP
are being used.

my ldap-users.cf file, for example:
server_host = ldap://server1.bpk2.com ldap://server2.bpk2.com
search_base = dc=bpk2,dc=com
version = 3

bind = sasl
bind_dn = uid=mta,ou=processUsers,ou=Users,dc=bpk2,dc=com
sasl_mechs = gssapi
sasl_realm = BPK2.COM

query_filter = (mail=%s)

the above results in the below error logs:
Jan 01 14:33:50 mail postfix/trivial-rewrite[17185]: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (No
Kerberos credentials available)
Jan 01 14:33:50 mail postfix/trivial-rewrite[17185]: warning:
dict_ldap_connect: Unable to bind to server ldap://server1.bpk2.com
ldap://server2.bpk2.com with dn
uid=mta,ou=processUsers,ou=Users,dc=bpk2,dc=com: -2 (Local error)
Jan 01 14:33:50 mail postfix/trivial-rewrite[17185]: warning:
virtual_alias_domains: ldap:/etc/postfix/ldap-aliases.cf: table lookup
problem
Jan 01 14:33:50 mail postfix/submission/smtpd[17176]: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (No
Kerberos credentials available)
Jan 01 14:33:50 mail postfix/submission/smtpd[17176]: warning:
dict_ldap_connect: Unable to bind to server ldap://server1.bpk2.com
ldap://server2.bpk2.com with dn
uid=mta,ou=processUsers,ou=Users,dc=bpk2,dc=com: -2 (Local error)
Jan 01 14:33:50 mail postfix/submission/smtpd[17176]: warning:
ldap:/etc/postfix/ldap-aliases.cf lookup error for "[hidden email]"


i am assuming the keytab, /etc/postfix/postfix.keytab would be used to
bind to the directory, but i am not sure.  the KRB5_KTNAME environment
variable is set with the absolute path and keytab name. is there
something i am missing?  the etc/sasl2/smtpd.conf file has the keytab
directive listed and gssapi is in the mech_list, too.  i have the below
set in my main.cf:

import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY
DISPLAY LANG=C KRB5_KTNAME=/etc/postfix/postfix.keytab
export_environment = TZ MAIL_CONFIG LANG KRB5_KTNAME

in the directory, i am mapping the Kerberos ID to LDAP user object as such:

uid=smtp\/(.*).bpk2.com,cn=bpk2.com,cn=gssapi,cn=auth
uid=mta,ou=processUsers,ou=Users,dc=bpk2,dc=com

can anyone shed light on where i am going wrong?

thanks in advance,

brendan

Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

Viktor Dukhovni
On Fri, Jan 01, 2016 at 02:46:33PM -0500, Brendan Kearney wrote:

> Postfix version - 3.0.3 running on Fedora 22.  MIT Kerberos and OpenLDAP are
> being used.
>
> my ldap-users.cf file, for example:
> server_host = ldap://server1.bpk2.com ldap://server2.bpk2.com
> search_base = dc=bpk2,dc=com
> version = 3
>
> bind = sasl
> bind_dn = uid=mta,ou=processUsers,ou=Users,dc=bpk2,dc=com
> sasl_mechs = gssapi
> sasl_realm = BPK2.COM
>
> query_filter = (mail=%s)

Where is the credential cache for the "postfix" ($mail_owner) user?

> the above results in the below error logs:
> Jan 01 14:33:50 mail postfix/trivial-rewrite[17185]: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (No
> Kerberos credentials available)

Not surprising, you need a cred cache.

> I am assuming the keytab, /etc/postfix/postfix.keytab would be used to bind
> to the directory, but i am not sure.  

No, Kerberos keytabs are not credential caches.  You need to run "kinit"
to obtain credentials via a keytab.  I recommend an hourly cron job
that runs as "postfix":

    export KRB5_KTNAME=FILE:/etc/postfix/postfix.keytab
    export KRB5CCNAME=FILE:$(postconf -xh queue_directory)/ccache
    principal=smtp/$(uname -n)
    kinit -k "$principal"

Then in main.cf add:

    # var=import_environment
    # val=$(postconf -h "$var")
    # postconf -e "$var = $val KRB5CCNAME=FILE:\${queue_directory}/ccache"

> import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY
> DISPLAY LANG=C KRB5_KTNAME=/etc/postfix/postfix.keytab
> export_environment = TZ MAIL_CONFIG LANG KRB5_KTNAME

This suffices for Postfix as a Kerberos server, but not as a Kerberos
client.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

Wietse Venema
In reply to this post by Brendan Kearney
Brendan Kearney:
> i am looking to get SASL binds working in Postfix for user, group and
> alias lookups, and i am not sure what i might be doing wrong.
>
> Postfix version - 3.0.3 running on Fedora 22.  MIT Kerberos and OpenLDAP
> are being used.

There aren't a lot of Kerberos-experienced people on this list, so you may
have to wait for a few days before you get a reply.

One example of Postfix/OpenLDAP/MIT Kerberos is Zimbra. They have
a web page on setting this up:
https://wiki.zimbra.com/wiki/Running_Kerberos_with_Zimbra_Collaboration_Suite

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

L.P.H. van Belle
In reply to this post by Brendan Kearney
never knew this, what is the SPN postix/sasl needs?

and a simple way to make the client work, setup a samba client, if setup correctly, samba wil refres the keytab file.

if someone want info on this, i can answere monday again.

greetz,
louis

> Op 1 jan. 2016 om 21:17 heeft Viktor Dukhovni <[hidden email]> het volgende geschreven:
>
>> On Fri, Jan 01, 2016 at 02:46:33PM -0500, Brendan Kearney wrote:
>>
>> Postfix version - 3.0.3 running on Fedora 22.  MIT Kerberos and OpenLDAP are
>> being used.
>>
>> my ldap-users.cf file, for example:
>> server_host = ldap://server1.bpk2.com ldap://server2.bpk2.com
>> search_base = dc=bpk2,dc=com
>> version = 3
>>
>> bind = sasl
>> bind_dn = uid=mta,ou=processUsers,ou=Users,dc=bpk2,dc=com
>> sasl_mechs = gssapi
>> sasl_realm = BPK2.COM
>>
>> query_filter = (mail=%s)
>
> Where is the credential cache for the "postfix" ($mail_owner) user?
>
>> the above results in the below error logs:
>> Jan 01 14:33:50 mail postfix/trivial-rewrite[17185]: GSSAPI Error:
>> Unspecified GSS failure.  Minor code may provide more information (No
>> Kerberos credentials available)
>
> Not surprising, you need a cred cache.
>
>> I am assuming the keytab, /etc/postfix/postfix.keytab would be used to bind
>> to the directory, but i am not sure.  
>
> No, Kerberos keytabs are not credential caches.  You need to run "kinit"
> to obtain credentials via a keytab.  I recommend an hourly cron job
> that runs as "postfix":
>
>    export KRB5_KTNAME=FILE:/etc/postfix/postfix.keytab
>    export KRB5CCNAME=FILE:$(postconf -xh queue_directory)/ccache
>    principal=smtp/$(uname -n)
>    kinit -k "$principal"
>
> Then in main.cf add:
>
>    # var=import_environment
>    # val=$(postconf -h "$var")
>    # postconf -e "$var = $val KRB5CCNAME=FILE:\${queue_directory}/ccache"
>
>> import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY
>> DISPLAY LANG=C KRB5_KTNAME=/etc/postfix/postfix.keytab
>> export_environment = TZ MAIL_CONFIG LANG KRB5_KTNAME
>
> This suffices for Postfix as a Kerberos server, but not as a Kerberos
> client.
>
> --
>    Viktor.
>

Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

Brendan Kearney
the SPN would be smtp/host.domain.tld@REALM.

the primary is smtp
the instance is the hostname of the machine, or if in a load balanced
environment, the name of the Virtual IP (VIP) that the clients connect
to.  if you are load balancing, you create one keytab file, and
distribute that same exact keytab to all load balanced pool members.
the realm is the Kerberos realm configured in /etc/krb5.conf.
see
http://web.mit.edu/KERBEROS/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html 
for more info.

a couple of additional questions i have come up with:

how does one tell postfix/submission what principal to use, when in a
load balanced environment and the keytab differs from the smtp/$(uname
-n)@REALM formula?

while Victor's suggestion is a great help and moves me forward in terms
of postfix as a SASL client for LDAP lookups, it raises a concern about
having a local user context (root) with interactive authenticated access
to LDAP, be it read-only because of restrictions put on the LDAP user
object associated with the identity established via Kerberos.  would
there be a way to pass that script to say the postfix user (su -c or
something), which is not available as an interactive session/shell,
thereby eliminating the available access to LDAP for a user who gains
root access?

Victor's script gets a  Kerberos ticket every hour.  it does not renew
the existing ticket, it seems.  my tickets are valid for 10 hours, and
renewable for 1 week.  getting a new ticket every hour is unnecessary.  
the idea of a samba client being used to refresh tickets sounds
interesting.  Louis, please do provide more detail.

to further the idea of managing Kerberos tickets, has SSSD been looked
at?  would it provide means to handle ticketing for both the "server"
and "client" side of postfix's dealings with AuthN/AuthZ?

On 01/02/2016 08:05 AM, L.P.H. van Belle wrote:

> never knew this, what is the SPN postix/sasl needs?
>
> and a simple way to make the client work, setup a samba client, if setup correctly, samba wil refres the keytab file.
>
> if someone want info on this, i can answere monday again.
>
> greetz,
> louis
>
>> Op 1 jan. 2016 om 21:17 heeft Viktor Dukhovni <[hidden email]> het volgende geschreven:
>>
>>> On Fri, Jan 01, 2016 at 02:46:33PM -0500, Brendan Kearney wrote:
>>>
>>> Postfix version - 3.0.3 running on Fedora 22.  MIT Kerberos and OpenLDAP are
>>> being used.
>>>
>>> my ldap-users.cf file, for example:
>>> server_host = ldap://server1.bpk2.com ldap://server2.bpk2.com
>>> search_base = dc=bpk2,dc=com
>>> version = 3
>>>
>>> bind = sasl
>>> bind_dn = uid=mta,ou=processUsers,ou=Users,dc=bpk2,dc=com
>>> sasl_mechs = gssapi
>>> sasl_realm = BPK2.COM
>>>
>>> query_filter = (mail=%s)
>> Where is the credential cache for the "postfix" ($mail_owner) user?
>>
>>> the above results in the below error logs:
>>> Jan 01 14:33:50 mail postfix/trivial-rewrite[17185]: GSSAPI Error:
>>> Unspecified GSS failure.  Minor code may provide more information (No
>>> Kerberos credentials available)
>> Not surprising, you need a cred cache.
>>
>>> I am assuming the keytab, /etc/postfix/postfix.keytab would be used to bind
>>> to the directory, but i am not sure.
>> No, Kerberos keytabs are not credential caches.  You need to run "kinit"
>> to obtain credentials via a keytab.  I recommend an hourly cron job
>> that runs as "postfix":
>>
>>     export KRB5_KTNAME=FILE:/etc/postfix/postfix.keytab
>>     export KRB5CCNAME=FILE:$(postconf -xh queue_directory)/ccache
>>     principal=smtp/$(uname -n)
>>     kinit -k "$principal"
>>
>> Then in main.cf add:
>>
>>     # var=import_environment
>>     # val=$(postconf -h "$var")
>>     # postconf -e "$var = $val KRB5CCNAME=FILE:\${queue_directory}/ccache"
>>
>>> import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY
>>> DISPLAY LANG=C KRB5_KTNAME=/etc/postfix/postfix.keytab
>>> export_environment = TZ MAIL_CONFIG LANG KRB5_KTNAME
>> This suffices for Postfix as a Kerberos server, but not as a Kerberos
>> client.
>>
>> --
>>     Viktor.
>>
Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

Viktor Dukhovni
On Sat, Jan 02, 2016 at 12:00:23PM -0500, Brendan Kearney wrote:

> the SPN would be smtp/host.domain.tld@REALM.

That's what SMTP clients expect for an SMTP service at "host.domain.tld",
in Kerberos realm "REALM".

> how does one tell postfix/submission what principal to use, when in a load
> balanced environment and the keytab differs from the smtp/$(uname -n)@REALM
> formula?

A single keytab file can contain keys for multiple principals.  On the
Postfix side the service name is configurable in versions 2.11 and
later:

    http://www.postfix.org/postconf.5.html#smtpd_sasl_service

> While Victor's suggestion is a great help and moves me forward in terms of
> postfix as a SASL client for LDAP lookups, it raises a concern about having
> a local user context (root) with interactive authenticated access to LDAP,
> be it read-only because of restrictions put on the LDAP user object
> associated with the identity established via Kerberos.

This makes no sense.  The "root" user typically can "su" to any
other user, so you can't hide credentials from "root".  And my
suggestion is that both the keytab and ccache belong to "postfix",
not root, since it is "postfix" and not "root" that will be reading
these.

> would there be a way
> to pass that script to say the postfix user (su -c or something), which is
> not available as an interactive session/shell, thereby eliminating the
> available access to LDAP for a user who gains root access?

If someone has "root" access, they get "postfix" for free.

> Victor's script gets a  Kerberos ticket every hour.  it does not renew the
> existing ticket, it seems.  my tickets are valid for 10 hours, and renewable
> for 1 week.  getting a new ticket every hour is unnecessary.  the idea of a
> samba client being used to refresh tickets sounds interesting.  Louis,
> please do provide more detail.

This is a non-interactive use-case.  A fresh ticket once an hour
is by far simpler than trying to figure out when to renew and when
to get a fresh ticket.  DO NOT make this needlessly complex.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

Stephen Ingram
On Sat, Jan 2, 2016 at 10:30 AM, Viktor Dukhovni <[hidden email]> wrote:
On Sat, Jan 02, 2016 at 12:00:23PM -0500, Brendan Kearney wrote:

> Victor's script gets a  Kerberos ticket every hour.  it does not renew the
> existing ticket, it seems.  my tickets are valid for 10 hours, and renewable
> for 1 week.  getting a new ticket every hour is unnecessary.  the idea of a
> samba client being used to refresh tickets sounds interesting.  Louis,
> please do provide more detail.

This is a non-interactive use-case.  A fresh ticket once an hour
is by far simpler than trying to figure out when to renew and when
to get a fresh ticket.  DO NOT make this needlessly complex.

I'd like to add I followed Victor's suggestion some time ago when setting up a Kerberos-enabled Postfix with grabbing a new ticket every hour. Not only is it far simpler like he says here, also, should your ticket fetch fail for any reason, it gives you 10 hours to remedy the problem before your entire mail system stops working. Since with Kerberos, your mail system now depends on at least one other system functioning perfectly, this can be a welcome relief when things don't go as expected.

Steve
Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

Quanah Gibson-Mount-3
In reply to this post by Brendan Kearney
--On Saturday, January 02, 2016 12:00 PM -0500 Brendan Kearney
<[hidden email]> wrote:


> Victor's script gets a  Kerberos ticket every hour.  it does not renew
> the existing ticket, it seems.  my tickets are valid for 10 hours, and
> renewable for 1 week.  getting a new ticket every hour is unnecessary.
> the idea of a samba client being used to refresh tickets sounds
> interesting.  Louis, please do provide more detail.

I suggest reading up on kstart:

<http://www.eyrie.org/~eagle/software/kstart/>

It's really the best way to do ticket management when dealing with Kerberos.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration
Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

Brendan Kearney
In reply to this post by Brendan Kearney

What are the merits of sssd for doing something like what kstart does?  I have it running and working for other needs and I think it provides more than just kerberos token management.

The caching offers fault tolerance and resiliency in the case of problems, as one example.

brendan

On Jan 4, 2016 1:34 PM, "Quanah Gibson-Mount" <[hidden email]> wrote:
--On Saturday, January 02, 2016 12:00 PM -0500 Brendan Kearney <[hidden email]> wrote:


Victor's script gets a  Kerberos ticket every hour.  it does not renew
the existing ticket, it seems.  my tickets are valid for 10 hours, and
renewable for 1 week.  getting a new ticket every hour is unnecessary.
the idea of a samba client being used to refresh tickets sounds
interesting.  Louis, please do provide more detail.

I suggest reading up on kstart:

<http://www.eyrie.org/~eagle/software/kstart/>

It's really the best way to do ticket management when dealing with Kerberos.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration
Reply | Threaded
Open this post in threaded view
|

Re: SASL binds

Brendan Kearney
In reply to this post by Viktor Dukhovni
On 01/02/2016 01:30 PM, Viktor Dukhovni wrote:
>> how does one tell postfix/submission what principal to use, when in a load
>> balanced environment and the keytab differs from the smtp/$(uname -n)@REALM
>> formula?
> A single keytab file can contain keys for multiple principals.  On the
> Postfix side the service name is configurable in versions 2.11 and
> later:
>
>      http://www.postfix.org/postconf.5.html#smtpd_sasl_service
>
i added the line:

   -o smtpd_sasl_service=smtp/smtp.bpk2.com

to master.cf, trying to indicate the principal to be used by submission
when authenticating users.  because i want to load balance multiple
instances, i need the instance in the principal to be the name of the
load balanced VIP and not that of the individual host.  this did not
work and i got the below error message:

warning: SASL authentication failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information (No key table entry
found matching smtp\/smtp.bpk2.com/mail.bpk2.com@)

if i am understanding this correctly, the smtpd_sasl_service is used to
change the primary, but i need to change the instance, instead. how
would change the principal from:

smtp/<hostname.domain.tld>@REALM

to

smtp/<VIP.domain.tld>@RELAM

so that load balancing and kerberos work together?

thanks,

brendan