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

Mark Foley
Mon, 27 Jun 2016 06:58:26 -0000

Aki, again, thanks A LOT for your reply. Concerning your checklist:

> 1. Functional AD or Kerberos environment

Check!

> 2. Time synced against your KDC (which is your Domain Controller on
Windows)

Check! (needed for AD/DC anyway)

> 3. /etc/krb5.conf configured

NO

> 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.

Check!

> 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).

NO

So, I'm apparently lacking in the kerberos stuff. Here's the problem --
Samba4 uses Heimdal
Kerberos and when I provisioned my domain apparently none of these needed
kerberos files were
set up. I can, however, kerberos authenticate from domain workstations both WIN7
and Linux.

I will (and have already) contacted the Samba list to see what needs to be done.

I'll post back what I find.

Maybe I can finally get to the bottom of this problem.

Thanks again -- 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>
> Organization: Dovecot Oy
> Date: Mon, 27 Jun 2016 09:18:54 +0300
>
> On 27.06.2016 07:31, Mark Foley wrote:
> > Thanks for the reply.  When you say it [NTLM] "should" work,
I understand you to be implying
> > you've not actually tried NTLM yourself, right? I've never
gotten a response from someone
> > saying they have or are actually using it. Your subsequent messages
about NTLM v[1|2] may be
> > the problem, but email clients I've tried (Outlook, Thunderbird)
don't really give a choice.
> >
> > That's OK, I'd be glad to try something different that would
work!!! I am trying your advice
> > for gssapi.  I've followed the instructions at
> > http://wiki2.dovecot.org/Authentication/Kerberos.  In my 10-auth.conf
I changed the
> > auth_mechanism line to:
> >
> > auth_mechanisms = plain login gssapi
> >
> > Which is only different from before with the addition of
"gssapi".  That's all I've done.  I'm
> > using the same userdb as before which is /etc/passwd.  My doveconf -n
is:
> >
> > ----------SNIP------------
> >> 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_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
> > ------------PINS-------------
> >
> > I attempted to connect from Thunderbird on Ubuntu 15.10 to Dovecot on
a Slackware 14.1 AD/DC. I
> > selected "Kerberos/GSSAPI" as the authentication method on
Tbird. When trying the connection I
> > got the following in my Dovecot log:
> >
> > Jun 27 00:04:54 imap-login: Debug: SSL: elliptic curve secp384r1 will
be used for ECDH and ECDHE key exchanges
> > Jun 27 00:04:54 imap-login: Debug: SSL: elliptic curve secp384r1 will
be used for ECDH and ECDHE key exchanges
> > Jun 27 00:04:54 auth: Debug: Loading modules from directory:
/usr/local/lib/dovecot/auth
> > Jun 27 00:04:54 auth: Debug: Loading modules from directory:
/usr/local/lib/dovecot/auth
> > Jun 27 00:04:54 imap-login: Info: Disconnected: Auth process broken
(disconnected before auth was ready, waited 0 secs): user=<>,
rip=192.168.0.99, lip=98.102.63.107, session=<Zk1rnzo2IADAqABj>
> >
> > So, any idea why this is not working? I'll say up-front that I do
not have the auth_krb5_keytab
> > configured in 10-auth.conf. I could find no such file on the host
running Dovecot. Is that file
> > needed? If so, I've got a message in to the Samba4 folks asking
where it is located.
> >
> > I'm also using Dovecot 2.2.15. Too old?
> >
> > Do you think auth_krb5_keytab is my problem or something deeper?
> >
> > THX --Mark
> >
>
> You need to set up keytab. I'll assume you know nothing about kerberos,
> so please if you already knew all this, sorry.
>
> For kerberos to work PROPERLY you need to have
>
> 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).
>
> Only bullet 5. is about Dovecot really, but since this is usually rather
> hard to gather information, I'll recap these things here:
>
> 2. Time sync
>
> Install ntpd and configure it to use *your* *ad* *server*. (Not some
> generic service).
>
> 3. /etc/krb5.conf
>
> Here is a *SAMPLE* configuration:
>
> [libdefaults]
>         default_realm = YOUR.REALM
>         dns_lookup_kdc = true
>         krb4_config = /etc/krb.conf
>         krb4_realms = /etc/krb.realms
>         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
>                 }
>         }
> [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
>
> Note that some windows environments require additional configuration to
> get this working.
>
> 4. Forward/reverse DNS.
>
> For your *server* this is *absolutely* must. It has to match for your
> clients and your server. So if your server name is mail.example.org, and
> it has IP 10.0.2.3, then 10.0.2.3 MUST resolve to mail.example.org. It
> will give you strange and convoluted errors otherwise.
>
> 5. Keytab
>
> This is bit tricky to generate, and there are various ways to do this.
> You can install samba, join it to your domain and use the samba tools to
> generate a keytab. It's not a bad idea, just remember to add the
> required spn's (service principal names) to the machine account. setspn
> -q is helpful here, also setspn command in general.
>
> You can use either system keytab file (/etc/krb5.keytab), or you can put
> the dovecot specific (mainly IMAP/something) into dedicated keytab for
> the service. Either way you need to tell dovecot about it with
> auth_krb5_keytab setting.
>
> You should have at least following entries in your keytab file. You can
> see them with klist -k /path/to/keytab. The KVNO can be different.
>
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ----
> --------------------------------------------------------------------------
>    3 host/mail.example.org at EXAMPLE.ORG
>    3 host/mail.example.org at EXAMPLE.ORG
>    3 host/mail.example.org at EXAMPLE.ORG
>    3 host/mail.example.org at EXAMPLE.ORG
>    3 host/mail.example.org at EXAMPLE.ORG
>    3 IMAP/mail.example.org at EXAMPLE.ORG
>    3 host/MAIL at EXAMPLE.ORG
>    3 host/MAIL at EXAMPLE.ORG
>    3 host/MAIL at EXAMPLE.ORG
>    3 host/MAIL at EXAMPLE.ORG
>    3 host/MAIL at EXAMPLE.ORG
>    3 IMAP/MAIL at EXAMPLE.ORG
>    3 MAIL$@EXAMPLE.ORG
>    3 MAIL$@EXAMPLE.ORG
>    3 MAIL$@EXAMPLE.ORG
>    3 MAIL$@EXAMPLE.ORG
>    3 MAIL$@EXAMPLE.ORG
>
> This will at least get you somewhere. Kerberos is notoriously hard to
> debug, but it usually is about
>
> a) DNS
> b) Keytab
> c) Mismatch of some name somewhere
> d) Encryption type support
>
> 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.
>
> If you want to try with something else first, which I recommend for the
> server in any case, is to see if you can get sssd working with Kerberos
> and LDAP. If you get that working, it's not very difficult anymore to
> get Dovecot running with it.
>
> ----
> Aki Tuomi
> Dovecot oy