[Dovecot] LDAP and GSSAPI problems
This is a continuation of a problem I have been having. Samba 4 has recently changed to require binds. I need LDAP to verify users exist. I am using Kerberos (GSSAPI) as the passdb. Samba can handle GSSAPI/Kerberos SASL binds.
I have the following in my dovecot-ldap setup for userdb:
dn = smtp/mailhost.example.org@EXAMPLE.ORG sasl_bind = yes sasl_mech = GSSAPI sasl_realm = EXAMPLE.ORG sasl_authz_id = smtp/mailhost.example.org@EXAMPLE.ORG
Which gives me the following error.
Debug: ldap(trever): user search: base=dc=example,dc=org scope=subtree filter=(&(objectClass=person)(|(mail=trever)(sAMAccountName=trever)(userPrincipalName=trever))) fields=userPrincipalName
dovecot: auth: Error: LDAP: binding failed (dn smtp/mailhost.example.org@EXAMPLE.ORG): Local error, SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_97' not found)
Additionally, I have "auth_krb5_keytab = /etc/dovecot/krb5.keytab" setup for the GSSAPI user login.
The credential cache should be that file should it not? If not, how do I go about setting that up so that it will work.
Thank you, Trever
"The only true happiness comes from squandering ourselves for a purpose." -- William Cowper
On Wed, 2011-02-02 at 14:29 -0700, Trever L. Adams wrote:
LDAP SASL authentication goes through Cyrus SASL library, nothing Dovecot can do about it, except for me to write my own LDAP library.
Additionally, I have "auth_krb5_keytab = /etc/dovecot/krb5.keytab" setup for the GSSAPI user login.
So this setting is never used. If that's the problem, you could try if you can work around it in a bit kludgy way:
service auth { executable = /usr/local/bin/auth-wrapper.sh }
Which contains:
#!/bin/sh export KRB5_KTNAME=/etc/dovecot/krb5.keytab exec /usr/local/libexec/dovecot/auth -k
On 02/02/2011 02:38 PM, Timo Sirainen wrote:
Postfix (the other half of my solution -- though the version I am using doesn't do SASL LDAP yet, but 2.9.x does) allows you, in the configuration, to set what environment variables it should not unset and even define new ones (an example -- import_environment = KRB5_KTNAME=/etc/dovecot/krb5.keytab). This may be a good solution for Dovecot specifically for things like this.
I would rather not have to run bash or any other shell just to set the environment variable. I will for the time being.
Thank you, as always, Trever
On Wed, 2011-02-02 at 16:13 -0700, Trever L. Adams wrote:
It does set that, but only on first GSSAPI authentication. I guess it wouldn't hurt moving it to do it always. If that script helps you, I can do this change.
Maybe.. But there haven't really been all that many uses for it.
On Thu, Feb 03, 2011 at 01:17:02AM +0200, Timo Sirainen wrote:
Windows AD's LDAP server behaves by default in the same way, in that all LDAP must be authenticated - this makes alot of sense, IMHO. It would be nice to have LDAP out of the box support kerberos authentication using the machine principle setup by samba.
Jason
On 02/02/2011 04:17 PM, Timo Sirainen wrote:
It appears that the script you recommended doesn't do the trick. Does /usr/libexec/dovecot/auth clear the environment. Even doing it manually from the command line the openldap stuff doesn't seem to pick up the KRB5_KTNAME environment variable.
I can kinit on the command line and get auth to work, but the kinit doesn't hold over to the dovecot process (for good reasons I am sure).
Some how this needs to be fixed so that GSSAPI through SASL will work. I am not sure where to go from here as I am learning LDAP as I mess with this stuff. Is there anyone on the list who has any ideas? (I would prefer this be service principals as well, if possible.)
Thank you, Trever Adams
"All this technology has somehow made you a stranger in your own land." -- Robert M. Pirsig
On Fri, Feb 04, 2011 at 12:57:11PM -0700, Trever L. Adams wrote:
Isn't it called KRB5CCNAME?
Ie if you are using a AD type environment then I think the only way this can work is if you do these steps:
JGGL is the name of your machine in AD klist -k should tell
you what it is, and you must have samba setup properly, the
machine joined, and samba must be set to write the system keytab.
See 'net ads keytab'
$ KRB5CCNAME="/tmp/machine" kinit -k JGGL$
$ KRB5CCNAME="/tmp/machine" klist
Ticket cache: FILE:/tmp/machine
Default principal: JGGL$@ADS.ORCORP.CA
Valid starting Expires Service principal 02/05/11 18:26:34 02/06/11 04:26:34 krbtgt/ADS.ORCORP.CA@ADS.ORCORP.CA renew until 02/12/11 18:26:34 $ KRB5CCNAME="/tmp/machine" ldapsearch uid=jgg SASL/GSSAPI authentication started SASL username: JGGL$@ADS.ORCORP.CA SASL SSF: 56 SASL data security layer installed. [..]
Presumably if dovecot has SASL setup properly for Openldap then it will work just fine if KRB5CCNAME is properly exported to it.
However! Be aware that the TGT must be refreshed periodically, that is just how kerberos works.
I can kinit on the command line and get auth to work, but the kinit doesn't hold over to the dovecot process (for good reasons I am sure).
Maybe dovecot isn't enabling SASL for openldap?
eg the python wrappers for openldap require this sequence:
conn = ldap.initialize(server); auth_tokens = ldap.sasl.gssapi(); conn.sasl_interactive_bind_s("",auth_tokens);
Before they attempt gssapi - so this will also be true for the C version.
The *ideal* world would be if dovecot supported an in-memory ticket cache that it stored a TGT for a given UPN that it initializes using a given keytab. This is what samba does internally and realistically is required to use kerberos as a client.
IMHO, doing ldap without kerb is kinda sketchy unless you completely trust your network - it is easy to spoof ldap replies, kerb fixes that and has low overhead compared to ssl.
Jason
On 02/05/2011 06:35 PM, Jason Gunthorpe wrote:
Thank you for all your input. I am afraid this is the same problem I am going to hit with Postfix (it does a similar setup to Dovecot, I am just not running the recent version yet that supports it).
Timo, is it possible for you to add that "import_environment =KRB5_KTNAME=/etc/dovecot/krb5.keytab KRB5CCNAME =/etc/dovecot/krb5.cc" (does this really need to be set over and over or can the master process set it and have the environment inherited... it has been a long time since I did any coding related to environment variables accross forks, etc.)? This will solve all the problems (whether keytab or credentialcache) other than the fact that OpenLDAP as a client won't work with a keytab (SPN) and that Kerberos will require a refresh of the credential cache.
Thank you Jason and Timo for helping me find a good solution, Trever
"All that is necessary for the triumph of evil is that enough good men do nothing." -- Edmund Burke
On Sat, Feb 05, 2011 at 08:49:21PM -0700, Trever L. Adams wrote:
Amanda is doing what I described below internally. The keytab file contains kerberos shared secrets so Amanda uses that to get a TGT. You can't use kerberos without a TGT. The fact it is using a SPN or UPN shared secret doesn't matter at the client.
Put the kinit -k line in a crontab. That command gets a fresh TGT for the machine account.
Service principles just avoid having to create a new UPN in MIT kerberos. In AD kerberos a SPN cannot get a TGT so that is undoable. The machine account works in very similarly to how a SPN would be used in MIT kerberos except that it is a UPN at the KDC. Samba writes a keytab entry for the machine account that contains the shared secret which lets kinit -k work.
Yes. Same answer, run it pointing to the same CC cache you setup for dovecot.
Be aware that both the keytab and the creditial cache are 'password equilvients' and must be protected.
Jason
On Sat, 2011-02-05 at 20:49 -0700, Trever L. Adams wrote:
Timo, is it possible for you to add that "import_environment =KRB5_KTNAME=/etc/dovecot/krb5.keytab KRB5CCNAME =/etc/dovecot/krb5.cc"
So you've tried that doing this via auth.sh script that sets those before calling dovecot/auth works?
Environment is inherited, but Dovecot explicitly clears it at the startup of each process, so any unnecessary stuff gets dropped out. But it would be possible to add e.g. DOVECOT_PRESERVE_ENVS that lists which environments variables should be preserved.
On Thu, 2011-02-10 at 01:17 +0200, Timo Sirainen wrote:
This is very good. A safe default (no import_environment) maybe TZ USER and
HOME. Just to maintain functionality if people don't set this up.
-----Original message----- From: Timo Sirainen <tss@iki.fi> To: Dovecot Mailing List <dovecot@dovecot.org> Cc: "Trever L. Adams" <trever.adams@gmail.com> Sent: Wed, Feb 9, 2011 23:55:06 GMT+00:00 Subject: Re: [Dovecot] LDAP and GSSAPI problems
On Thu, 2011-02-10 at 01:17 +0200, Timo Sirainen wrote:
participants (3)
-
Jason Gunthorpe
-
Timo Sirainen
-
Trever L. Adams