Bug 15582 - PAC handling in standalone mode
Summary: PAC handling in standalone mode
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.20.0rc2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2024-02-15 12:01 UTC by Alexander Bokovoy
Modified: 2024-02-15 12:40 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bokovoy 2024-02-15 12:01:35 UTC
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.