Why is smbd looking for Kerberos principal cifs/host at DOMB when it is a member of DOMA?
Nathaniel W. Turner
nathanielwyliet at gmail.com
Tue Nov 26 19:55:05 UTC 2019
Perhaps someone on samba-technical can answer a slightly different question
about this: Since I know that this configuration can successfully
authenticate users in both domains when NTLMSSP is used, it would be nice
if it could fall back to ntlmssp after gse_krb5 fails to find a keytab
entry for the (seemingly bogus) principal name. Is that possible given the
This seems similar in some respects to
https://bugzilla.samba.org/show_bug.cgi?id=14106, though that case is
different, as my server *is* an AD domain member, and in that issue, the
server is *not* a domain member, and is starting out with GENSEC mechanism
spnego from the beginning, and just choking on a client token that doesn't
make sense in that context (if I understand it correctly).
If it's not possible for the server to fall back to ntlmssp after going
partway down the gse_krb5 path, would be be reasonable to somehow
disable krb5 for client authentication (while still using it for
communication with the domain controllers, of course)? As a practical
matter, Windows domain member clients seem to work fine when samba just
uses ntlmssp (which it seems you can force by using an IP address instead
of a hostname in the UNC path when connecting), but maybe there are
scenarios where that's not the case.
On Fri, Nov 15, 2019 at 12:23 PM Nathaniel W. Turner <
nathanielwyliet at gmail.com> wrote:
> Hi all. I’m trying to understand a weird authentication failure:
> I have two domains (TC83.LOCAL and TC84.LOCAL), each in a diferent forest,
> with a bidirectional forest trust.
> The samba server kvm7246-vm022.maas.local is a domain member of TC83 and
> is running a recent build from git master (f38077ea5ee).
> When I test authentication of users in each domain by running ntlm_auth on
> the samba server, it is successful for users in either domain.
> When I try to connect from a Windows client in TC84 using SMB, it is only
> successful for users in the TC83 domain. For users in the TC84 domain, smbd
> seems to go off the rails looking for a Kerberos machine principal in the
> TC84 domain, even though it is not a member of that domain (it's a member
> of TC83, which trusts TC84):
> Nov 15 15:53:04 kvm7246-vm022 smbd: [2019/11/15 15:53:04.524996,
> 1, pid=15209, effective(0, 0), real(0, 0)]
> Nov 15 15:53:04 kvm7246-vm022 smbd: gss_accept_sec_context failed
> with [ Miscellaneous failure (see text): Failed to find
> cifs/kvm7246-vm022.maas.local at TC84.LOCAL(kvno 10) in keytab
> MEMORY:cifs_srv_keytab (aes256-cts-hmac-sha1-96)]
> Why is smbd looking for a principal of the form
> "cifs/kvm7246-vm022.maas.local at TC84.LOCAL"?
> https://drive.google.com/drive/folders/1jsVWHL--mVEnK9pDFUajyt2nQQ5cLpOQ for
> full logs and smb.conf]
More information about the samba-technical