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