Looking for GSSAPI config [was: Looking for NTLM config example]

Edgar Pettijohn edgar at pettijohn-web.com
Wed Jun 29 16:43:12 UTC 2016



> On Jun 29, 2016, at 10:32 AM, Mark Foley <mfoley at ohprs.org> wrote:
> 
>> On Tue, 28 Jun 2016 22:52:25 -0500 Edgar Pettijohn <edgar at pettijohn-web.com> wrote:
>> 
>> What does thunderbird tell you?
> 
> Good question.  I saw Tbird's message after sending my last email.  When Tbird starts I get a
> message box in the lower right saying:
> 
> "The Kerberos/GSSAPI ticket was not accepted by the IMAP server mark at ohprs.org. Please check
> that you are logged in to the Kerberos/GSSAPI realm."
> 
> The interesting bit, to me, is that the IMAP server's hostname is not mark at ohprs.org. It should
> be mail.ohprs.org, or I would rather expect it to be mail.hprs.local using the actual local
> domain/realm name, not the public FQDN. I'm suspecting there is something wrong with the
> kerberos config.
> 
> To further confuse.  There *is* a WIN7 workstation 'mark' in the domain, though not the
> workstation from which this testing is being done (this workstation is named 'common') and host
> 'mark' is not reachable as mark at ohprs.org.  Furthermore, the Thunderbird account/user for this
> testing is also 'mark', not to be confused with the host 'mark' (though I think that's exactly
> what's being confused). 
> 
> Where is this mark at ohprs.org coming from? The Thunderbird Account Name is mark at ohprs.org, which
> is this user's email address.
> 
> Perhaps Thunderbird simply has a badly worded error message and didn't really mean "IMAP server
> mark at ohprs.org", or perhapd kerberos is not configured correctly.  My /etc/krb5.conf is shown
> below.  Any ideas on what might be wrong?
It's doubtful it's a thunderbird issue unless you've given it bad information. Unfortunately I don't use ldap or gssapi so I'm afraid I can't offer much help. 


> 
>>>>> [libdefaults]
>>>>> default_realm = HPRS.LOCAL
>>>>> dns_lookup_realm = false
>>>>> dns_lookup_kdc = true
>>>>> 
>>>>> [libdefaults]
>>>>> default_realm = HPRS.LOCAL
>>>>> dns_lookup_kdc = true
>>>>> kdc_timesync = 1
>>>>> ccache_type = 4
>>>>> forwardable = true
>>>>> proxiable = true
>>>>> fcc-mit-ticketflags = true
>>>>> 
>>>>> [realms]
>>>>> HPRS.LOCAL = {
>>>>>   default_domain = hprs.local
>>>>>   auth_to_local_names = {
>>>>>   Administrator = root
>>>>> }
>>>>> }
>>>>> 
>>>>> [domain_realm]
>>>>>   hprs.local = HPRS.LOCAL
>>>>> # this is not a mistake
>>>>>   .hprs.local = HPRS.LOCAL
> 
> Thanks, --Mark
> 
> -----Original Message-----
>> From: Edgar Pettijohn <edgar at pettijohn-web.com>
>> Subject: Re: Looking for GSSAPI config [was: Looking for NTLM config example]
>> Date: Tue, 28 Jun 2016 22:52:25 -0500
>> To: Mark Foley <mfoley at ohprs.org>
>> 
>> 
>> 
>>> On Jun 28, 2016, at 10:32 PM, Mark Foley <mfoley at ohprs.org> wrote:
>>> 
>>> Aki - partial success! I rebuilt my dovecot with ./config --with-gssapi, and restarted. Now I
>>> don't get that "Unknown authentication mechanism 'gssapi'" message in maillog, and mail is
>>> delivered successfully to the other domain users having PLAIN authentication. That's a big
>>> step. In examining my original config.log output I apparently did not have --with-gssapi enabled.
>>> 
>>> HOWEVER - the Thunderbird client configured for 'Kerberos / GSSAPI' still cannot correctly
>>> authenticate and retrieve mail. Here is the dovecot log for that host:
>> What does thunderbird tell you?
>> 
>> 
>>> Jun 28 22:44:05 imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
>>> Jun 28 22:44:05 imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
>>> Jun 28 22:44:05 auth: Debug: Loading modules from directory: /usr/local/lib/dovecot/auth
>>> Jun 28 22:44:05 auth: Debug: Read auth token secret from /usr/local/var/run/dovecot/auth-token-secret.dat
>>> Jun 28 22:44:05 auth: Debug: auth client connected (pid=24076)
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read client hello A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key exchange A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read certificate verify A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read finished A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write session ticket A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write finished A [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully [192.168.0.58]
>>> Jun 28 22:44:06 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [192.168.0.58]
>>> Jun 28 22:44:11 imap-login: Debug: SSL alert: close notify [192.168.0.58]
>>> Jun 28 22:44:11 imap-login: Debug: SSL alert: close notify [192.168.0.58]
>>> Jun 28 22:44:11 imap-login: Info: Disconnected (no auth attempts in 6 secs): user=<>, rip=192.168.0.58, lip=98.102.63.107, TLS, session=<WeZyumE25wDAqAA6>
>>> 
>>> Does this tell you anything? `doveconf -n` and krb5.conf are configured as shown in previous
>>> messages below.
>>> 
>>> Closer! --Mark
>>> 
>>> -----Original Message-----
>>> From: Mark Foley <mfoley at ohprs.org>
>>> Date: Tue, 28 Jun 2016 22:04:42 -0400
>>> To: dovecot at dovecot.org
>>> Subject: Re: Looking for GSSAPI config [was: Looking for NTLM config example]
>>> 
>>> Aki, you wrote:
>>> 
>>>> Doh. Seems your dovecot isn't compiled with gssapi support? Can you compile it yourself?
>>>> 
>>>> I'll try to check status of NTLM this week.
>>> 
>>> I'm OK with continuing to try gssapi, esp. if NTLM is restricted to v1.
>>> 
>>> I do have the Dovecot sources and will peruse the possible options after I send this.  I am on
>>> version 2.2.15 and I see that the current downloadable version is 2.2.24.  Should I upgrade? Do
>>> you think that would help? (a perusal of the changes since 2.2.15 shows nothing obvious
>>> realated to gssapi)
>>> 
>>> --Mark
>>> 
>>> -----Original Message-----
>>>> Date: Tue, 28 Jun 2016 18:06:10 +0300 (EEST)
>>>> From: aki.tuomi at dovecot.fi
>>>> To: dovecot at dovecot.org
>>>> Subject: Re: Looking for GSSAPI config [was: Looking for NTLM config example]
>>>> 
>>>>> On June 28, 2016 at 5:17 PM Mark Foley <mfoley at ohprs.org> wrote:
>>>>> 
>>>>> 
>>>>> Aki - made your suggested changes, but no joy :(
>>>>> 
>>>>> My /etc/krb5.conf:
>>>>> 
>>>>> ------SNIP--------
>>>>> [libdefaults]
>>>>> default_realm = HPRS.LOCAL
>>>>> dns_lookup_realm = false
>>>>> dns_lookup_kdc = true
>>>>> 
>>>>> [libdefaults]
>>>>> default_realm = HPRS.LOCAL
>>>>> dns_lookup_kdc = true
>>>>> kdc_timesync = 1
>>>>> ccache_type = 4
>>>>> forwardable = true
>>>>> proxiable = true
>>>>> fcc-mit-ticketflags = true
>>>>> 
>>>>> [realms]
>>>>> HPRS.LOCAL = {
>>>>>   default_domain = hprs.local
>>>>>   auth_to_local_names = {
>>>>>   Administrator = root
>>>>> }
>>>>> }
>>>>> 
>>>>> [domain_realm]
>>>>>   hprs.local = HPRS.LOCAL
>>>>> # this is not a mistake
>>>>>   .hprs.local = HPRS.LOCAL
>>>>> ------PINS-----------
>>>>> 
>>>>> you wrote:
>>>>>> You can remove the krb4_ stuff
>>>>> 
>>>>> I've remove krb4_ stuff from the [libdefaults] and eliminated the [login] section altogether.
>>>>> Question on [realms]Administrator: should that really be root or should it be my AD Administrator?
>>>>> 
>>>>> my doveconf -n is exactly the same as posted below, but in particular:
>>>>> 
>>>>> auth_krb5_keytab = /etc/krb5.keytab
>>>>> auth_mechanisms = plain login gssapi
>>>>> 
>>>>> When I reloaded dovecot no mail was delivered to anyone (even though everyone was still using
>>>>> plain/ssl, no one yet configured for gssapi).
>>>>> 
>>>>> In /var/log/maillog I got (repeatedly):
>>>>> 
>>>>> Jun 28 09:43:36 mail dovecot: imap-login: Warning: Auth process not responding, delayed sending initial response (greeting): user=<>, rip=192.168.0.54, lip=192.168.0.2, session=<Jy/e0lY2WADAqAA2>
>>>>> Jun 28 09:43:37 mail dovecot: auth: Fatal: Unknown authentication mechanism 'gssapi'
>>>>> Jun 28 09:43:37 mail dovecot: master: Error: service(auth): command startup failed, throttling for 60 secs
>>>>> Jun 28 09:43:37 mail dovecot: imap-login: Warning: Auth process not responding, delayed sending initial response (greeting): user=<>, rip=166.170.27.161, lip=98.102.63.107, TLS, session=</GXn0lY22wCmqhuh>
>>>>> 
>>>>> This looks pretty bad right off. Why "Unknown authentication mechanism 'gssapi'"?
>>>>> 
>>>>> Do you have any idea from the configs I've posted? I'm rather depressed about this. I thought I'd
>>>>> finally able to get AD authentication going for Dovecot. Not ready to give up though!
>>>>> 
>>>>> Suggestions?
>>>>> 
>>>>> THX -- Mark
>>>>> 
>>>>> -----original Message-----
>>>>>> Subject: Re: Looking for GSSAPI config [was: Looking for NTLM config example]
>>>>>> To: dovecot at dovecot.org
>>>>>> From: Aki Tuomi <aki.tuomi at dovecot.fi>
>>>>>> Date: Tue, 28 Jun 2016 15:13:11 +0300
>>>>>> 
>>>>>>> On 28.06.2016 09:27, Mark Foley wrote:
>>>>>>> Aki,
>>>>>>> 
>>>>>>> To review your 5 points:
>>>>>>> 
>>>>>>>> On Mon, 27 Jun 2016 09:18:54 +0300 Aki Tuomi <aki.tuomi at dovecot.fi> wrote:
>>>>>>>> 
>>>>>>>> 1. Functional AD or Kerberos environment
>>>>>>>> 2. Time synced against your KDC (which is your Domain Controller on Windows)
>>>>>>>> 3. /etc/krb5.conf configured
>>>>>>>> 4. Both forward / reverse DNS names correct for clients and servers.
>>>>>>>> Reverse is only mandatory for servers, but having them right will work
>>>>>>>> wonders. Most kerberos problems are about DNS problems.
>>>>>>>> 5. You need a keytab. This keytab needs to hold entries like
>>>>>>>> IMAP/your.host.name at REALM  and IMAP/$HOSTNAME at REALM. You can generate
>>>>>>>> these on any Windows DC server (at least).
>>>>>>> I believe I am good on 1,2 and 4.  I downloaded and installed kerberos and tested it with kinit
>>>>>>> and klist according to the instructions at
>>>>>>> https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Configure_Kerberos
>>>>>>> 
>>>>>>> As to the the keytab (#5) I did the following:
>>>>>>> 
>>>>>>> $ samba-tool domain exportkeytab /etc/krb5.keytab
>>>>>>> 
>>>>>>> which created the file.  I made this owned and readable by group dovecot, per instructions at
>>>>>>> http://wiki2.dovecot.org/Authentication/Kerberos.  Running `klist -k /etc/krb5.keytab` shows me
>>>>>>> configuration listing all the users and computers in the domain, mostly in triplicate.  A
>>>>>>> partial list:
>>>>>>> 
>>>>>>> Keytab name: FILE:/etc/krb5.keytab
>>>>>>> KVNO Principal
>>>>>>> ---- --------------------------------------------------------------------------
>>>>>>>  18 COMMON$@HPRS.LOCAL
>>>>>>>  18 COMMON$@HPRS.LOCAL
>>>>>>>  18 COMMON$@HPRS.LOCAL
>>>>>>>   1 MAIL$@HPRS.LOCAL
>>>>>>>   1 MAIL$@HPRS.LOCAL
>>>>>>>   1 MAIL$@HPRS.LOCAL
>>>>>>>   1 charmaine at HPRS.LOCAL
>>>>>>>   1 charmaine at HPRS.LOCAL
>>>>>>>   1 charmaine at HPRS.LOCAL
>>>>>>> 
>>>>>>> where COMMON and MAIL are hosts and charmaine is a user. I don't really understand the listing,
>>>>>>> but am assuming it is OK.
>>>>>> 
>>>>>> Strange that you do not have any host/ entries. Maybe it works without.
>>>>>> 
>>>>>>>> setspn -q is helpful here, also setspn command in general.
>>>>>>> I have no such command in my system. Is that a Windows thing?
>>>>>> 
>>>>>> Yes, but you can do those kind of things in Samba too.
>>>>>> 
>>>>>>> As to the /etc/krb5.conf, the default one generated by samba is:
>>>>>>> 
>>>>>>> [libdefaults]
>>>>>>>        default_realm = HPRS.LOCAL
>>>>>>>        dns_lookup_realm = false
>>>>>>>        dns_lookup_kdc = true
>>>>>>> 
>>>>>>> I'd like to modify that to your suggestions, but I need more help. You have (with my questions):
>>>>>>> 
>>>>>>>> Here is a *SAMPLE* configuration:
>>>>>>>> 
>>>>>>>> [libdefaults]
>>>>>>>>        default_realm = YOUR.REALM
>>>>>>>>        dns_lookup_kdc = true
>>>>>>>>        krb4_config = /etc/krb.conf
>>>>>>>>        krb4_realms = /etc/krb.realms
>>>>>>> Here, you have krb4_*. Do you mean that? My config file is krb5.conf. Should I rather have:
>>>>>> 
>>>>>> You can remove the krb4_ stuff
>>>>>> 
>>>>>>>   krb5_config = /etc/krb5.conf
>>>>>>> 
>>>>>>> Also, I have no /etc/krb*.realms file. Do I need this? If so, what should be in there?
>>>>>> You don't necessarely require that.
>>>>>> 
>>>>>>>>        kdc_timesync = 1
>>>>>>>>        ccache_type = 4
>>>>>>>>        forwardable = true
>>>>>>>>        proxiable = true
>>>>>>>>        fcc-mit-ticketflags = true
>>>>>>>> 
>>>>>>>> [realms]
>>>>>>>>        YOUR.REALM = {
>>>>>>>>                default_domain = your.domain.name
>>>>>>>>                auth_to_local_names = {
>>>>>>>>                        Administrator = root
>>>>>>>>                }
>>>>>>>>        }
>>>>>>> I suppose my "YOUR.REALM" is HPRS.LOCAL, right? Is my "your.domain.name" my FQDN for my AD
>>>>>>> server: mail.hprs.local, or is it just hprs.local? (or something else!)
>>>>>> 
>>>>>> HPRS.LOCAL is your REALM, hprs.local is your domain name.
>>>>>>> 
>>>>>>>> [domain_realm]
>>>>>>>>      your.domain.name = YOUR.REALM
>>>>>>>> # this is not a mistake
>>>>>>>>      .your.domain.name = YOUR.REALM
>>>>>>>> [login]
>>>>>>>>        krb4_convert = true
>>>>>>>>        krb4_get_tickets = false
>>>>>>> Likewise here a question on the whole krb4 versus krb5 thing.
>>>>>>> 
>>>>>>> Your closing comment:
>>>>>>> 
>>>>>>>> Also, note that kerberos can only act as AUTHENTICATION system. It
>>>>>>>> cannot act as USER DATABASE. For that you need to configure LDAP or
>>>>>>>> something else. With Active Directory LDAP is probably a damn good idea.
>>>>>>> I have the following doveconf -n:
>>>>>>> 
>>>>>>> # 2.2.15: /usr/local/etc/dovecot/dovecot.conf
>>>>>>> # OS: Linux 3.10.17 x86_64 Slackware 14.1
>>>>>>> auth_debug_passwords = yes
>>>>>>> auth_krb5_keytab = /etc/krb5.keytab
>>>>>>> auth_mechanisms = plain login gssapi
>>>>>>> auth_verbose = yes
>>>>>>> auth_verbose_passwords = plain
>>>>>>> disable_plaintext_auth = no
>>>>>>> info_log_path = /var/log/dovecot_info
>>>>>>> mail_location = maildir:~/Maildir
>>>>>>> passdb {
>>>>>>>  driver = shadow
>>>>>>> }
>>>>>>> protocols = imap
>>>>>>> ssl_cert = </etc/ssl/certs/OHPRS/GoDaddy/Apache/2015-08-14/57aa6ed6ae98b4c7.crt
>>>>>>> ssl_key = </etc/ssl/certs/OHPRS/GoDaddy/mail.ohprs.org.key
>>>>>>> userdb {
>>>>>>>  driver = passwd
>>>>>>> }
>>>>>>> verbose_ssl = yes
>>>>>>> 
>>>>>>> I assume the passwd driver for the userdb is OK? Seems to me it should work with gssapi, but in
>>>>>>> any case I still have all but this test workstation NOT using gssapi, so I still need to
>>>>>>> accomodate them.
>>>>>>> 
>>>>>>> Thanks, --Mark
>>>>>> passwd driver is fine, yes, if you ensure that users can be found.
>>>>>> 
>>>>>> Aki
>>>> 
>>>> Doh. Seems your dovecot isn't compiled with gssapi support? Can you compile it yourself?
>>>> 
>>>> I'll try to check status of NTLM this week.
>>>> 
>>>> Aki
>> 
>> 



More information about the dovecot mailing list