[Samba] Trouble with Kerberos authentication

[Mark Foley]

Yes, there is a keytab file used by Dovecot, and reverse DNS is set up. 

I've actually been using this setup for more than a year. This is the first time I've tried to
set up a new user email account in all that time. Not a new user, but a new email account on a
new workstation.

As I've been experimenting, I've found I cannot set up a new Kerberos/GSSAPI authenticated
email client for *any* user, including those listed below as examples (mark, sue) which have
been working for well over a year with Kerberos/GSSAPI. 

So, something has changed. I have not updated Dovecot since I first installed it back in 2015.
Samba and Linux modules have been routinely updated on the AD/AC since then.

Not sure where to turn to debug this. Ideas?

THX --Mark

Vinicius Bones Silva via samba <samba at lists.samba.org> wrote:

> Did you create a kerberos keytab file to use with dovecot?
> https://wiki2.dovecot.org/Authentication/Kerberos
>
> Also, make sure there's a reverse DNS entry for the dovecot server, kerberos usually fails 
> if the reverse address is not resolvable.
>
> Regards,
> Vinicius.
>
> Em 11/07/2017 06:41, Mark Foley via samba escreveu:
> > I'm not sure whether this is a Dovecot issue or a Samba issue, but as it deals with
> > authentication I think it's worth trying the samba experts first.
> >
> > Here's the scenario ...
> >
> > I have an AD/DC running Samba 4.4.14.  I have 3 AD users: mark, sue, dennis.  Mark and Dennis
> > use both Windows 7 and Linux (also running PAM-enabled Samba 4.4.14) domain member
> > workstations.  Sue is Windows 7 only.  All are able to log onto the domain using their domain
> > credentials and all are able to connect the the Dovcot mail server (also running on the AD/DC)
> > from their workstations using Thunderbird and Kerberos/GSSAPI authentication.
> >
> > Dovecot authentication is set to auth_mechanisms = plain login gssapi. The first two mechanisms
> > use /etc/passwd for authentication. The gssapi presumably uses gssapi and kerberos to
> > authenticate via AD. I believe Dovecot tries these mechanisms in order, left-to-right.
> >
> > As it turns out, user Dennis also had an entry in /etc/passwd - yes, I know it shouldn't be
> > there, but it was, although it did have the correct AD user and group IDs.  No problem, I
> > though, I'll just remove that entry.
> >
> > However, when I did that, Dennis was not longer able to authenticate from Thunderbird.  He
> > could still log into his Linux workstation.  Tbird would give the error
> >
> >    "The Kerberos/GSSAPI ticket was not accepted by the IMAP server ...  please check that you are
> >    logged into the Kerberos/GSSAPI realm."
> >
> > Wnen I put Dennis back in /etc/passwd, with the correct domain password, he is able to
> > authenticate from Thunderbird again.
> >
> > I know next to nothing about how kerberos works, but my theory is that Dennis' kerberos
> > credentials somehow got associated with his /etc/passwd credentials, not his AD credentials and
> > when the /etc/passwd entry is removed kerberos authentication fails. This is true on both his
> > Linux and Windows workstations.
> >
> > I need to fix this so Dennis' AD credentials alone are used for authentication. How can I do
> > this?
> >
> > btw, `getent passwd dennis` works just fine from Dennis' Linux workstation.
> >
> > Thanks --Mark
> >
>
> -- 
>
> 	
> Vinicius Silva
> SOC
>
>
> BRA: + 55 51 2117.1000 | 55 11 5521.2021
> USA: + 1 888 259.5801
> vbs at e-trust.com.br
> skype: vinicius.bones.silva
>
> 	
>
>
>
>
>
>
>
> 	Smiley face
>
> www.e-trust.com.br <http://www.e-trust.com.br/>
>
>
> Esta mensagem pode conter informações confidenciais ou privilegiadas. Se você recebeu esta 
> mensagem por engano, você não deve usar, copiar, divulgar ou tomar qualquer atitude com 
> base nestas informações. Solicitamos que você apague a mensagem imediatamente e avise a 
> E-TRUST, enviando um e-mail para suporte at e-trust.com.br. Opiniões, conclusões ou 
> informações contidas nesta mensagem não necessariamente refletem a posição oficial da 
> E-TRUST. Caso assinada digitalmente, a autenticidade desta mensagem pode ser confirmada 
> pela Autoridade Certificadora Privada E-TRUST, disponível em www.e-trust.com.br.
>
> This message may contain privileged and confidential information for the use of the 
> intended recipients only. If you are not an intended recipient then you should not 
> disseminate, copy, or take any action based on its contents. If you have received this 
> message in error then please notify E-TRUST by sending an e-mail message to 
> suporte at e-trust.com.br immediately. Views and opinions expressed in this message do not 
> necessarily reflect the position of E-TRUST. If this message is digitally signed, its 
> authenticity can be confirmed by E-TRUST Private Certificate Authority, available at 
> www.e-trust.com.br.
>