Samba uses `server role` parameter to decide in which configuration it runs. If the machine is not joined to any domain, it is in `standalone` mode. Standalone server accepts Kerberos but does not expect MS-PAC authorization data be present. MIT Kerberos 1.20+ always adds minimal PAC records (https://web.mit.edu/kerberos/krb5-1.20/) and this breaks standalone mode because we do not expect PAC blobs being present: $ KRB5_TRACE=/dev/stderr smbclient --use-kerberos=required --use-krb5-ccache KCM:0 //`hostname`/home [5090] 1707997619.379807: Getting credentials admin@MACH.EXAMPLE.TEST -> cifs/mach.example.test@MACH.EXAMPLE.TEST using ccache KCM:1000:60786 [5090] 1707997619.379808: Retrieving admin@MACH.EXAMPLE.TEST -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from KCM:1000:60786 with result: -1765328243/Matching credential not found [5090] 1707997619.379809: Retrieving admin@MACH.EXAMPLE.TEST -> cifs/mach.example.test@MACH.EXAMPLE.TEST from KCM:1000:60786 with result: 0/Success [5090] 1707997619.379810: Creating authenticator for admin@MACH.EXAMPLE.TEST -> cifs/mach.example.test@MACH.EXAMPLE.TEST, seqnum 363102074, subkey aes256-sha2/11DD, session key aes256-sha2/C4A1 session setup failed: NT_STATUS_BAD_TOKEN_TYPE The setup above uses locally available KDC, purely for authentication purposes (see https://github.com/abbra/local-kdc for details). We end up refusing such ticket due to the following code in auth3_generate_session_info_pac(): /* This is the standalone legacy code path */ if (pac_blob != NULL) { /* * In standalone mode we don't expect a PAC! * we only support MIT realms */ status = NT_STATUS_BAD_TOKEN_TYPE; DBG_WARNING("Unexpected PAC for [%s] in standalone mode - %s\n", princ_name, nt_errstr(status)); if (!NT_STATUS_IS_OK(status)) { goto done; } } smbd would produce the following error: [2024/02/15 11:46:59.389238, 1, pid=5095, effective(0, 0), real(0, 0)] ../../source3/auth/auth_generic.c:211(auth3_generate_session_info_pac) auth3_generate_session_info_pac: Unexpected PAC for [admin@MACH.EXAMPLE.TEST] in standalone mode - NT_STATUS_BAD_TOKEN_TYPE The content of PAC is not important at this point -- it is the fact that the blob is present throws us away. But this is going to be a norm soon as Windows Server 2025 and Windows 11 will add a local KDC on each machine even not joined to a domain. So we will need to deal with that. In fact, there will be three modes where Kerberos is expected to be provided from more than one realm/domain: - local KDC always available on any machine, service the machine's realm (domain sid = machine sid) - (optionally) domain-joined KDC is provided, we are either domain member or domain controller - (optionally) cloud-available KDC is provided, we are joined to Entra ID or similar service and have access to our domain, our local KDC, and the cloud KDC. I think this means we probably have to treat local KDC scenario as a separate standalone 'domain' that would need to be managed in parallel to existing modes. -
Entra ID details about Kerberos can be found in this FAQ document: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-faqs#under-the-hood and in Steve's blogs: https://syfuhs.net/how-azure-ad-kerberos-works Details on how Microsoft expects to use local KDC: https://syfuhs.net/deprecating-ntlm-is-easy-and-other-lies-we-tell-ourselves and https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-evolution-of-windows-authentication/ba-p/3926848