Looking for GSSAPI config [was: Looking for NTLM config example]
Aki Tuomi
aki.tuomi at dovecot.fi
Mon Jun 27 06:18:54 UTC 2016
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
More information about the dovecot
mailing list