Problems with GSSAPI and LDAP

Juha Koho juha.koho at trineco.fi
Wed Oct 12 11:52:07 UTC 2016 

On 2016-10-12 12:02, Aki Tuomi wrote:
> On 12.10.2016 10:27, Juha Koho wrote:
>> 
>> On 2016-10-11 12:10, Juha Koho wrote:
>>> On 2016-10-11 11:03, Aki Tuomi wrote:
>>>> On 11.10.2016 11:56, Juha Koho wrote:
>>>>> 
>>>>> On 2016-10-11 10:00, Aki Tuomi wrote:
>>>>>> On 11.10.2016 10:43, Juha Koho wrote:
>>>>>>> 
>>>>>>> On 2016-10-11 09:18, Aki Tuomi wrote:
>>>>>>>> On 11.10.2016 10:13, Juha Koho wrote:
>>>>>>>>> Hello,
>>>>>>>>> 
>>>>>>>>> I have a Dovecot 2.2.25 set up with OpenLDAP back end. I was
>>>>>>>>> trying to
>>>>>>>>> set up a GSSAPI Kerberos authentication with the LDAP server
>>>>>>>>> but with
>>>>>>>>> little success. Seems no matter what I try I end up with the
>>>>>>>>> following
>>>>>>>>> error message:
>>>>>>>>> 
>>>>>>>>> dovecot: auth: Error: LDAP: binding failed (dn
>>>>>>>>> (imap/host.example.com at EXAMPLE.COM)): Local error, SASL(-1):
>>>>>>>>> generic
>>>>>>>>> failure: GSSAPI Error: Unspecified GSS failure.  Minor code may
>>>>>>>>> provide more information (No Kerberos credentials available
>>>>>>>>> (default
>>>>>>>>> cache: FILE:/tmp/dovecot.krb5.ccache))
>>>>>>>>> 
>>>>>>>>> I have set the import_environment in dovecot.conf:
>>>>>>>>> 
>>>>>>>>> import_environment = TZ CORE_OUTOFMEM CORE_ERROR LISTEN_PID
>>>>>>>>> LISTEN_FDS
>>>>>>>>> KRB5CCNAME=FILE:/tmp/dovecot.krb5.ccache
>>>>>>>>> 
>>>>>>>>> And these in LDAP configuration:
>>>>>>>>> 
>>>>>>>>> dn = imap/host.example.com at EXAMPLE.COM
>>>>>>>>> sasl_bind = yes
>>>>>>>>> sasl_mech = gssapi
>>>>>>>>> sasl_realm = EXAMPLE.COM
>>>>>>>>> sasl_authz_id = imap/host.example.com at EXAMPLE.COM
>>>>>>>>> 
>>>>>>>>> I have tried with different values in dn and sasl_authz_id and
>>>>>>>>> also
>>>>>>>>> leaving them out completely but I always end up with the error
>>>>>>>>> message
>>>>>>>>> above. Using simple bind without GSSAPI works just fine.
>>>>>>>>> 
>>>>>>>>> The credentials cache file exists and is valid for the 
>>>>>>>>> principal
>>>>>>>>> imap/host.example.com at EXAMPLE.COM. The file is owned by dovecot
>>>>>>>>> user
>>>>>>>>> so it shouldn't be a permission problem either.
>>>>>>>>> 
>>>>>>>>> GSSAPI in OpenLDAP works but I suppose it is irrelevant here 
>>>>>>>>> since
>>>>>>>>> the
>>>>>>>>> connection attempt never reaches the LDAP server due to the
>>>>>>>>> error. I
>>>>>>>>> also have similar setup for Postfix and it works fine.
>>>>>>>>> 
>>>>>>>>> Any ideas what to try next?
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> Juha
>>>>>>>> 
>>>>>>>> Can you provide klist output for the cache file? Also, it should 
>>>>>>>> be
>>>>>>>> readable by dovenull user, or whatever is configured as
>>>>>>>> default_login_user.
>>>>>>> 
>>>>>>> 
>>>>>>> Here's the klist output of the cache file:
>>>>>>> --
>>>>>>> Ticket cache: FILE:/tmp/dovecot.krb5.ccache
>>>>>>> Default principal: imap/host.example.com at EXAMPLE.COM
>>>>>>> 
>>>>>>> Valid starting       Expires              Service principal
>>>>>>> 10/11/2016 09:26:25  10/11/2016 21:26:25
>>>>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM
>>>>>>>         renew until 10/12/2016 09:26:25
>>>>>>> ---
>>>>>>> 
>>>>>>> That I didn't know that also dovenull must have access to the 
>>>>>>> cache
>>>>>>> but I tried also setting 0644 permissions to the cache file with 
>>>>>>> no
>>>>>>> luck. So permissions shouldn't be the issue...
>>>>>>> 
>>>>>>> Juha
>>>>>> 
>>>>>> Your ccache has no ticket for imap/host.example.com at EXAMPLE.COM
>>>>>> 
>>>>>> please use kinit to acquire one.
>>>>> 
>>>>> 
>>>>> Now I'm confused. The cache file is created by kinit using the
>>>>> command:
>>>>> 
>>>>> sudo -u dovenull kinit -c FILE:/tmp/dovecot.krb5.ccache -k -t
>>>>> /path/to/keytab imap/host.example.com
>>>>> 
>>>>> After that:
>>>>> 
>>>>> $ sudo -u dovenull klist /tmp/dovecot.krb5.ccache
>>>>> Ticket cache: FILE:/tmp/dovecot.krb5.ccache
>>>>> Default principal: imap/host.example.com at EXAMPLE.COM
>>>>> 
>>>>> Valid starting       Expires              Service principal
>>>>> 10/11/2016 10:47:47  10/11/2016 22:47:47
>>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM
>>>>>         renew until 10/12/2016 10:47:47
>>>>> 
>>>>> Also, I can use the cache file with ldapsearch just fine by running
>>>>> the following:
>>>>> 
>>>>> sudo -u dovenull KRB5CCNAME=FILE:/tmp/dovecot.krb5.ccache 
>>>>> ldapsearch
>>>>> -Y GSSAPI -ZZ -H ldap://ldap.example.com/ -b dc=example,dc=com
>>>>> 
>>>>> After the ldapsearch has succeeded the klist output is the 
>>>>> following:
>>>>> 
>>>>> $ sudo -u dovenull klist /tmp/dovecot.krb5.ccache
>>>>> Ticket cache: FILE:/tmp/dovecot.krb5.ccache
>>>>> Default principal: imap/host.example.com at EXAMPLE.COM
>>>>> 
>>>>> Valid starting       Expires              Service principal
>>>>> 10/11/2016 10:47:47  10/11/2016 22:47:47
>>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM
>>>>>         renew until 10/12/2016 10:47:47
>>>>> 10/11/2016 10:49:32  10/11/2016 22:47:47
>>>>> ldap/ldap.example.com at EXAMPLE.COM
>>>>>         renew until 10/12/2016 10:47:47
>>>>> 
>>>>> 
>>>>> Which is what I expected. Isn't this basically what dovecot does 
>>>>> (or
>>>>> should do) or did I miss something?
>>>>> 
>>>>> Juha
>>>> 
>>>> Dovecot won't acquire service tickets for you. It requires that you
>>>> have
>>>> ticket for imap/imap.example.com at EXAMPLE.COM in the cache or keytab.
>>>> 
>>>> The default principal is used when *CONNECTING* to a service, but 
>>>> you
>>>> are *ACCEPTING* a service, so you need a service principal.
>>>> 
>>>> Aki
>>> 
>>> Sorry, all this Kerberos stuff is quite new to me and I'm still a bit
>>> confused... :) What I still fail to understand is why would I need 
>>> the
>>> service principal in the cache since I'm trying to set dovecot to use
>>> GSSAPI when connecting to the LDAP back end for passdb and userdb
>>> lookups.
>>> 
>>> My imap users can connect to Dovecot using GSSAPI without problems.
>>> This isn't the issue. Dovecot being the client to the LDAP service is
>>> the issue.
>>> 
>>> But anyway, after adding the ticket for
>>> imap/host.example.com at EXAMPLE.COM in the cache the error still
>>> remains:
>>> 
>>> dovecot: auth: Error: LDAP: binding failed (dn
>>> imap/host.example.com at EXAMPLE.COM): Local error, SASL(-1): generic
>>> failure: GSSAPI Error: Unspecified GSS failure.  Minor code may
>>> provide more information (No Kerberos credentials available (default
>>> cache: FILE:/tmp/dovecot.krb5.ccache))
>>> 
>>> $ sudo -u dovenull klist /tmp/dovecot.krb5.ccache
>>> Ticket cache: FILE:/tmp/dovecot.krb5.ccache
>>> Default principal: imap/host.example.com at EXAMPLE.COM
>>> 
>>> Valid starting       Expires              Service principal
>>> 10/11/2016 11:00:50  10/11/2016 23:00:50  
>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM
>>>         renew until 10/12/2016 11:00:50
>>> 10/11/2016 11:19:09  10/11/2016 23:00:50  imap/host.example.com@
>>>         renew until 10/12/2016 11:00:50
>>> 10/11/2016 11:19:09  10/11/2016 23:00:50
>>> imap/host.example.com at EXAMPLE.COM
>>>         renew until 10/12/2016 11:00:50
>>> 
>>> Juha
>> 
>> Just to let anyone interested know the configuration was correct but
>> this turned out to be some sort of library incompatibility or 
>> whatever.
>> 
>> I cloned the configuration to a new virtual server and compiled a
>> fresh copy of Dovecot from source (tried  git master and
>> release-2.2.25) and it worked without problems.
>> 
>> I also noticed that with the freshly compiled version the error
>> message changed to
>> 
>> dovecot: auth: Error: LDAP: binding failed (dn (none)): Local error,
>> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
>> Minor code may provide more information (No Kerberos credentials
>> available: Credentials cache permissions incorrect (filename:
>> /tmp/dovecot.krb5.ccache))
>> 
>> if the permissions of the cache file were incorrect instead of this
>> general error message above. So seems like the issue - whatever it was
>> - caused that Dovecot (or the underlying libraries) were unable to
>> locate or open the cache file in the first place.
>> 
>> Juha
> 
> I think it requires that the file is readable only by the user, so
> setting if 0644 was probably a mistake.
> 
> Aki

No, this isn't the case. In the new test environment where things work 
it doesn't care about the cache file permissions as long as it can read 
the file.

I just noticed the error when I mistakenly had created the cache file as 
root and therefore it wasn't readable by Dovecot.

Juha

More information about the dovecot mailing list