Re: [Dovecot] LDAP and GSSAPI problems
On 02/05/2011 09:40 PM, Jason Gunthorpe wrote: On Sat, Feb 05, 2011 at 08:49:21PM -0700, Trever L. Adams wrote: Isn't it called KRB5CCNAME? Yes. Some things (Amanda, at least from the directions, I haven't done it yet) actually still use service principals which are KRB5_KTNAME. For credentials in most clients, yes, KRB5CCNAME and that does work. 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. Great to know. Thank you. Yes, this refresh is EXACTLY what I have been trying to avoid with service principals. I am starting to wish that Samba 4 supported SASL CRAM-MD5 or something so that I could just use that; no refresh. 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. Ok, I had to use SPNs for part of the setup. I am now using the UPN they run under for my tests and everything seems to work ok. I cannot test it directly in Dovecot as the Linux distro I am using doesn't have the Postfix counterpart needed just yet, but the kinit -k works from the keytab I have setup. Hopefully I can test that soon. 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). 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 Yes, I was aware of this. Thank you very much for the reminder. So, all this time I just needed to be able to set an environment variable and since Samba and AD don't allow you to login using SPNs, just use the UPN I had the SPNs under for this CC setup. Thank you, Trever Adams -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
Re: [Dovecot] LDAP and GSSAPI problems
On 02/09/2011 04:17 PM, Timo Sirainen wrote: 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? Yes, this works. It was a difference in how Samba/Windows AD use/or don't use SPNs but allow UPNs that was causing the problem. Can you push the patch that has DOVECOT_PRESERVER_ENVS into a stable release sometime soon? With documentation on the variables that used to be preserved and probably should be? This is fantastic. Sorry for the long delay in my responses; I am very grateful. Trever -- It was as true as taxes is. And nothing's truer than them. -- Charles Dickens (1812-70) signature.asc Description: OpenPGP digital signature
Re: [Dovecot] LDAP and GSSAPI problems
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? (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.)? 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.
Re: [Dovecot] LDAP and GSSAPI problems
On Thu, 2011-02-10 at 01:17 +0200, Timo Sirainen wrote: (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.)? 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. http://hg.dovecot.org/dovecot-2.0/rev/cec7fa92ff48
Re: [Dovecot] LDAP and GSSAPI problems
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 t...@iki.fi To: Dovecot Mailing List dovecot@dovecot.org Cc: Trever L. Adams trever.ad...@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: (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.)? 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. http://hg.dovecot.org/dovecot-2.0/rev/cec7fa92ff48
Re: [Dovecot] LDAP and GSSAPI problems
On Fri, Feb 04, 2011 at 12:57:11PM -0700, Trever L. Adams wrote: On 02/02/2011 04:17 PM, Timo Sirainen 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. 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. 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 ExpiresService principal 02/05/11 18:26:34 02/06/11 04:26:34 krbtgt/ads.orcorp...@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
Re: [Dovecot] LDAP and GSSAPI problems
On 02/05/2011 06:35 PM, Jason Gunthorpe wrote: On Fri, Feb 04, 2011 at 12:57:11PM -0700, Trever L. Adams wrote: On 02/02/2011 04:17 PM, Timo Sirainen 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. 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. Isn't it called KRB5CCNAME? Yes. Some things (Amanda, at least from the directions, I haven't done it yet) actually still use service principals which are KRB5_KTNAME. For credentials in most clients, yes, KRB5CCNAME and that does work. 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. Yes, this refresh is EXACTLY what I have been trying to avoid with service principals. I am starting to wish that Samba 4 supported SASL CRAM-MD5 or something so that I could just use that; no refresh. 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). 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. I would prefer an SPN if it were at all possible. On reading that again, I think we are saying about the same thing. This would be fantastic. Heck, if I knew how to do that manually I could just script it, but, being new to Kerberos and LDAP I am missing a lot as I read the documentation, I am sure. 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 Yes, this is exactly the reasons I am trying to get there. The problem is the refresh. Somehow I need to get around having to refresh the CC or use a keytab with SPNs. 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 signature.asc Description: OpenPGP digital signature
Re: [Dovecot] LDAP and GSSAPI problems
On Sat, Feb 05, 2011 at 08:49:21PM -0700, Trever L. Adams 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. Isn't it called KRB5CCNAME? Yes. Some things (Amanda, at least from the directions, I haven't done it yet) actually still use service principals which are KRB5_KTNAME. For credentials in most clients, yes, KRB5CCNAME and that does work. 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. However! Be aware that the TGT must be refreshed periodically, that is just how kerberos works. Yes, this refresh is EXACTLY what I have been trying to avoid with service principals. I am starting to wish that Samba 4 supported SASL CRAM-MD5 or something so that I could just use that; no refresh. 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. 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). 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
Re: [Dovecot] LDAP and GSSAPI problems
On 02/02/2011 04:17 PM, Timo Sirainen 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. 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 signature.asc Description: OpenPGP digital signature
[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@example.org sasl_bind = yes sasl_mech = GSSAPI sasl_realm = EXAMPLE.ORG sasl_authz_id = smtp/mailhost.example@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@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 signature.asc Description: OpenPGP digital signature
Re: [Dovecot] LDAP and GSSAPI problems
On Wed, 2011-02-02 at 14:29 -0700, Trever L. Adams wrote:
dn = smtp/mailhost.example@example.org
sasl_bind = yes
sasl_mech = GSSAPI
sasl_realm = EXAMPLE.ORG
sasl_authz_id = smtp/mailhost.example@example.org
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
Re: [Dovecot] LDAP and GSSAPI problems
On 02/02/2011 02:38 PM, Timo Sirainen wrote:
On Wed, 2011-02-02 at 14:29 -0700, Trever L. Adams wrote:
dn = smtp/mailhost.example@example.org
sasl_bind = yes
sasl_mech = GSSAPI
sasl_realm = EXAMPLE.ORG
sasl_authz_id = smtp/mailhost.example@example.org
LDAP SASL authentication goes through Cyrus SASL library, nothing
Dovecot can do about it, except for me to write my own LDAP library.
Ok. I can understand that.
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
I thought I saw a patch on the mailing list in 2007 that set KRB5_KTNAME
if auth_krb5_keytab was set in the configuration. I guess it was either
ntlm specific or was not accepted.
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
--
signature.asc
Description: OpenPGP digital signature
Re: [Dovecot] LDAP and GSSAPI problems
On Wed, 2011-02-02 at 16:13 -0700, Trever L. Adams wrote: #!/bin/sh export KRB5_KTNAME=/etc/dovecot/krb5.keytab exec /usr/local/libexec/dovecot/auth -k I thought I saw a patch on the mailing list in 2007 that set KRB5_KTNAME if auth_krb5_keytab was set in the configuration. I guess it was either ntlm specific or was not accepted. 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. 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. Maybe.. But there haven't really been all that many uses for it.
Re: [Dovecot] LDAP and GSSAPI problems
On Thu, Feb 03, 2011 at 01:17:02AM +0200, 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. Maybe.. But there haven't really been all that many uses for it. 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
