NTLM-only authentication broken in 0.18.8+ when USE_SESSION_KEY is requested without Kerberos

[adrabkin]

NTLM-only authentication broken in sspi 0.18.8+ when USE_SESSION_KEY is requested without Kerberos

Summary

Starting in sspi 0.18.8 (PR #600), consumers that request ClientRequestFlags::USE_SESSION_KEY without providing a target SPN get a hard error during initialize_security_context. In 0.18.7, this worked fine — NTLM negotiation proceeded without requiring an SPN. This is a breaking change that affects any SMB client using NTLM-only authentication.

Additionally, the NTLM-on-IP-address fallback added in PR #637 (sspi 0.18.9) does not fully work — the Kerberos TGT-REQ token is still generated even after the protocol is downgraded to NTLM, causing STATUS_LOGON_FAILURE on non-domain-joined servers.

Environment

• sspi versions tested: 0.18.7 (works), 0.18.8 (broken), 0.18.9 (broken)
• SMB client: smb-rs v0.11.1, built without kerberos feature
• Server: Dell PowerScale (Isilon) OneFS — local user authentication, no Active Directory/Kerberos domain
• Auth method: NTLM only (auth_methods: { ntlm: true, kerberos: false })
• Connection target: IP address (DNS resolved before SMB connect, e.g., //10.120.4.12/share)

Reproduction

Minimal setup

Any SMB client using sspi's Negotiate SSP with:

1. ClientRequestFlags::USE_SESSION_KEY in context requirements
2. No target_name provided (or target_name provided as an IP-based SPN like cifs/10.120.4.12)
3. NTLM-only package list (no Kerberos)
4. Server is a non-domain-joined NAS (OneFS, Samba, etc.) with local user accounts

Test matrix (verified)

All tests: same smb-rs 0.11.1, same server, same credentials, same dataset (53 files), fresh SMB sessions each time.

Test	sspi version	SPN provided	Result
1	0.18.7	No	✅ 53/53 success
2	0.18.8	No	❌ 0/53 — NoCredentials: Service target name (service principal name) is not provided
3	0.18.9	No	❌ 0/53 — Same NoCredentials error
4	0.18.9	Yes (cifs/10.120.4.12)	❌ 0/53 — Logon Failure (0xc000006d)

Bug 1: USE_SESSION_KEY requires SPN even for NTLM (0.18.8+)

Location

src/negotiate/client.rs:70-82 (introduced in PR #600):

match negotiate.state {
    NegotiateState::Initial => {
        let sname = if builder
            .context_requirements
            .contains(ClientRequestFlags::USE_SESSION_KEY)
        {
            let (service_name, service_principal_name) =
                parse_target_name(builder.target_name.ok_or_else(|| {
                    Error::new(
                        ErrorKind::NoCredentials,
                        "Service target name (service principal name) is not provided",
                    )
                })?)?;
            Some([service_name, service_principal_name])
        } else {
            None
        };

Problem

USE_SESSION_KEY unconditionally requires target_name to be Some. This is incorrect for NTLM — NTLM always derives a session key during authentication regardless of whether USE_SESSION_KEY is requested. The flag is only meaningful for Kerberos, where the session key comes from the service ticket.

Previous behavior (0.18.7)

In src/negotiate.rs:600+, the initialize_security_context function did not check for USE_SESSION_KEY at all. It processed target_name only for NTLM downgrade detection (IP address check) and proceeded directly to protocol negotiation.

Impact

Any consumer that:

• Requests USE_SESSION_KEY (common — smb-rs always does)
• Doesn't provide a target_name (because Kerberos isn't being used)
• Uses NTLM-only authentication

...gets a hard NoCredentials error on every session setup.

Bug 2: NTLM-on-IP downgrade still generates Kerberos TGT-REQ token (0.18.9)

Location

src/negotiate/client.rs:68-100 and src/negotiate/generators.rs:48-80

Problem

When a consumer provides an IP-based SPN (e.g., cifs/10.120.4.12), the flow is:

1. check_target_name_for_ntlm_downgrade (called before NegotiateState::Initial) detects IP → sets negotiate.protocol = NegotiatedProtocol::Ntlm(...) ✅
2. NegotiateState::Initial → USE_SESSION_KEY check → parses SPN into sname = Some(["cifs", "10.120.4.12"])
3. generate_mech_type_list(matches!(protocol, Kerberos(_)), ntlm) → correctly uses NTLM mech types (because protocol was downgraded) ✅
4. generate_neg_token_init(sname, mech_types) → generates a Kerberos TGT-REQ token because sname is Some ❌

In generators.rs:52-72, when sname is Some, a full Kerberos TgtReq message is constructed:

let krb5_neg_token_init = ApplicationTag0(KrbMessage {
    krb5_oid: ObjectIdentifierAsn1::from(oids::krb5_user_to_user()),
    krb5_token_id: TGT_REQ_TOKEN_ID,
    krb_msg: TgtReq {
        server_name: PrincipalName { name_string: sname },
    },
});

This Kerberos token is embedded in the SPNego NegTokenInit.mech_token field. The server receives an SPNego init that says "I support NTLM" in mech_types but also contains a Kerberos TGT-REQ in mech_token. Non-domain-joined servers (OneFS, Samba with local users) attempt to process the Kerberos token, fail, and return STATUS_LOGON_FAILURE (0xc000006d).

Expected behavior

When the protocol has been downgraded to NTLM (by the IP address check or any other reason), sname should be set to None so that generate_neg_token_init produces a clean NTLM-only SPNego init without a Kerberos mech_token.

Suggested fix

In src/negotiate/client.rs, after the USE_SESSION_KEY → sname extraction, check if the protocol is NTLM and clear the sname:

let sname = if builder
    .context_requirements
    .contains(ClientRequestFlags::USE_SESSION_KEY)
{
    // ... existing SPN parsing ...
    Some([service_name, service_principal_name])
} else {
    None
};

// Don't include Kerberos TGT-REQ when protocol has been downgraded to NTLM
let sname = if matches!(&negotiate.protocol, NegotiatedProtocol::Ntlm(_)) {
    None
} else {
    sname
};

Or alternatively, don't require target_name when the negotiated protocol is NTLM — since NTLM doesn't use the SPN for session key derivation, USE_SESSION_KEY should not gate on target_name for NTLM.

Workaround

Pin sspi = "=0.18.7" in Cargo.toml. This is the last version where NTLM-only authentication works without providing an SPN.

Related

• PR fix!(sspi): correct Negotiate (SPNEGO) implementation #600 — introduced the USE_SESSION_KEY → SPN requirement (breaking change)
• PR fix(negotiate): fall back to NTLM when the target SPN is an IP address #637 — added NTLM-on-IP fallback (incomplete — doesn't clear sname)
• Issue FreeRDP connection failed with NTLM selection if use username password when KDC URL unset and Windows Server is off #620 — related regression from same PR fix!(sspi): correct Negotiate (SPNEGO) implementation #600 (FreeRDP Kerberos fallback failure, different code path)
• smb-rs — affected consumer (always requests USE_SESSION_KEY, only provides SPN with kerberos feature)

[TheBestTvarynka]

Hi,
I will reproduce mentioned cases on my environment and will address them.

Thank you for the detailed description! It's valuable

[adrabkin]

Looking through the latest release, it looks like this has been addressed and re-worked in the latest version. The rework however causes downstream issues for me due to a dependency for this module to be <0.19 (due to the changes introduced). will investigate further.

[TheBestTvarynka]

Hi, Avi Drabkin (@adrabkin)

I wrote some tests and investigated reported bugs. I could not reproduce these bugs in my tests.

Bug 1: USE_SESSION_KEY requires SPN even for NTLM (0.18.8+)

Location

src/negotiate/client.rs:70-82 (introduced in PR #600):

Linked code does not exist. I reworked it in the last PRs. So, it should work as expected now.

Bug 2: NTLM-on-IP downgrade still generates Kerberos TGT-REQ token (0.18.9)

Location

src/negotiate/client.rs:68-100 and src/negotiate/generators.rs:48-80

We also improved the NTLM fallback for IP SPN. See #637.

I assume these bugs were present in previous versions, and we fixed them without realizing it (except for #637, of course).
Can you try again, but using sspi version 0.19.2? In the meantime I will prepare a PR with additional tests to cover these features so we will not break them in the future.

cc Richard Markiewicz (@thenextman)

[thenextman]

Thank you Pavlo Myroniuk (@TheBestTvarynka) 🚀

[afiffon]

Hi Pavlo Myroniuk (@TheBestTvarynka), how are you doing?

My smb-rs main branch build breaks once upgrading to sspi = "0.19.2" (or any version that is above sspi = "=0.18.7". At first sight, it looks like IntiailizeSecurityContextResult::status is set to ContinueNeeded despite having a SPENGO accept-completed result.

• In older versions, it seems like the last authentication response is empty:

• In newer ones, we have the accept-completed content

It is worth mentioning that the failed test is test_basic_guest - which logs in to a samba server using a /GUEST user and no password.

Here's a failed CI job with the error: https://github.com/afiffon/smb-rs/actions/runs/24362699988/job/71146379656, the commit hash is 474afe20d40e704bffff1742534884eb60dc2cee.

I don't have so much time to put into debugging lately.

And here's a verbose log (that contains the full packets):

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 12 filtered out; finished in 0.00s

     Running tests/basic.rs (target/debug/deps/basic-eb31752eca7e57d9)

running 1 test
test test_basic_guest ... FAILED

failures:

---- test_basic_guest stdout ----
[2026-04-22T13:24:15Z INFO  basic::common] Connecting to 127.0.0.1
[2026-04-22T13:24:15Z DEBUG smb::client::smb_client] Creating new connection to 127.0.0.1
[2026-04-22T13:24:15Z INFO  smb::connection] Connecting to 127.0.0.1 (at 127.0.0.1:445)...
[2026-04-22T13:24:15Z DEBUG smb_transport::tcp::transport] Connecting to 127.0.0.1:445 with timeout 10s.
[2026-04-22T13:24:15Z INFO  smb::connection] Connected to 127.0.0.1. Negotiating.
[2026-04-22T13:24:15Z DEBUG smb::connection] Negotiating multi-protocol: Sending SMB1
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Sending 4 bytes.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Sending 69 bytes.
[2026-04-22T13:24:15Z DEBUG smb::connection] Sent SMB1 negotiate request, Receieving SMB2 response
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Reading 4 bytes.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Read 4 bytes OK.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Reading 202 bytes.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Read 202 bytes OK.
[2026-04-22T13:24:15Z TRACE smb_transport::traits] Received SMB message of 202 bytes from server: [254, 83, 77, 66, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 65, 0, 1, 0, 255, 2, 0, 0, 51, 100, 57, 53, 48, 52, 56, 98, 57, 57, 99, 98, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 128, 0, 0, 0, 128, 0, 0, 0, 128, 0, 242, 182, 28, 81, 91, 210, 220, 1, 0, 0, 0, 0, 0, 0, 0, 0, 128, 0, 74, 0, 0, 0, 0, 0, 96, 72, 6, 6, 43, 6, 1, 5, 5, 2, 160, 62, 48, 60, 160, 14, 48, 12, 6, 10, 43, 6, 1, 4, 1, 130, 55, 2, 2, 10, 163, 42, 48, 40, 160, 38, 27, 36, 110, 111, 116, 95, 100, 101, 102, 105, 110, 101, 100, 95, 105, 110, 95, 82, 70, 67, 52, 49, 55, 56, 64, 112, 108, 101, 97, 115, 101, 95, 105, 103, 110, 111, 114, 101]
[2026-04-22T13:24:15Z DEBUG smb::connection] Negotiating SMB2
[2026-04-22T13:24:15Z DEBUG smb::connection::worker::parallel::async_backend] Starting worker loop.
[2026-04-22T13:24:15Z DEBUG smb::connection::worker::parallel::async_backend] Starting worker loop.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Reading 4 bytes.
[2026-04-22T13:24:15Z TRACE smb::connection::worker::parallel::base] ParallelWorker::send(OutgoingMessage { message: PlainRequest { header: Header { credit_charge: 0, status: 0, command: Negotiate, credit_request: 0, flags: HeaderFlags { server_to_redir: false, async_command: false, related_operations: false, signed: false, priority_mask: 0, dfs_operation: false, replay_operation: false }, next_command: 0, message_id: 1, tree_id: Some(0), async_id: None, session_id: 0, signature: 0 }, content: Negotiate(NegotiateRequest { security_mode: NegotiateSecurityMode { signing_enabled: true, signing_required: false }, capabilities: GlobalCapabilities { dfs: true, leasing: true, large_mtu: true, multi_channel: false, persistent_handles: false, directory_leasing: true, encryption: true, notifications: true }, client_guid: 0998619c-d913-f282-0397-e12fb413d532, dialects: [Smb0202, Smb021, Smb030, Smb0302, Smb0311], negotiate_context_list: Some([NegotiateContext { context_type: PreauthIntegrityCapabilities, data: PreauthIntegrityCapabilities(PreauthIntegrityCapabilities { hash_algorithms: [Sha512], salt: [108, 210, 100, 134, 41, 161, 226, 80, 191, 133, 116, 84, 143, 236, 34, 153, 128, 1, 106, 1, 254, 208, 227, 16, 172, 182, 171, 199, 88, 238, 159, 237] }) }, NegotiateContext { context_type: NetnameNegotiateContextId, data: NetnameNegotiateContextId(NetnameNegotiateContextId { netname: SizedWideString("smb-client") }) }, NegotiateContext { context_type: EncryptionCapabilities, data: EncryptionCapabilities(EncryptionCapabilities { ciphers: [Aes128Ccm, Aes256Ccm, Aes128Gcm, Aes256Gcm] }) }, NegotiateContext { context_type: CompressionCapabilities, data: CompressionCapabilities(CompressionCapabilities { flags: CompressionCapsFlags { chained: true }, compression_algorithms: [None, PatternV1, LZ4] }) }, NegotiateContext { context_type: SigningCapabilities, data: SigningCapabilities(SigningCapabilities { signing_algorithms: [HmacSha256, AesCmac, AesGmac] }) }]) }) }, return_raw_data: true, compress: true, encrypt: false, has_response: true, additional_data: None, channel_id: None }) called
[2026-04-22T13:24:15Z TRACE smb::connection::worker::parallel::base] Message with ID 1 is passed to the worker for sending
[2026-04-22T13:24:15Z TRACE smb::connection::worker::parallel::base] Message with ID 1 is not received yet, insert channel and await.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Sending 4 bytes.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Sending 256 bytes.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Read 4 bytes OK.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Reading 284 bytes.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Read 284 bytes OK.
[2026-04-22T13:24:15Z TRACE smb_transport::traits] Received SMB message of 284 bytes from server: [254, 83, 77, 66, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 65, 0, 1, 0, 17, 3, 3, 0, 51, 100, 57, 53, 48, 52, 56, 98, 57, 57, 99, 98, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 128, 0, 0, 0, 128, 0, 0, 0, 128, 0, 216, 166, 30, 81, 91, 210, 220, 1, 0, 0, 0, 0, 0, 0, 0, 0, 128, 0, 74, 0, 208, 0, 0, 0, 96, 72, 6, 6, 43, 6, 1, 5, 5, 2, 160, 62, 48, 60, 160, 14, 48, 12, 6, 10, 43, 6, 1, 4, 1, 130, 55, 2, 2, 10, 163, 42, 48, 40, 160, 38, 27, 36, 110, 111, 116, 95, 100, 101, 102, 105, 110, 101, 100, 95, 105, 110, 95, 82, 70, 67, 52, 49, 55, 56, 64, 112, 108, 101, 97, 115, 101, 95, 105, 103, 110, 111, 114, 101, 0, 0, 0, 0, 0, 0, 1, 0, 38, 0, 0, 0, 0, 0, 1, 0, 32, 0, 1, 0, 41, 104, 15, 116, 179, 1, 227, 227, 12, 198, 157, 172, 102, 63, 98, 192, 107, 187, 229, 58, 87, 46, 105, 189, 54, 207, 116, 56, 105, 206, 172, 174, 0, 0, 2, 0, 4, 0, 0, 0, 0, 0, 1, 0, 2, 0, 0, 0, 0, 0, 8, 0, 4, 0, 0, 0, 0, 0, 1, 0, 2, 0]
[2026-04-22T13:24:15Z TRACE smb::connection::worker::parallel::base] Received message from server.
[2026-04-22T13:24:15Z TRACE smb::connection::worker::parallel::base] Waking up awaiting task for key 1.
[2026-04-22T13:24:15Z TRACE smb_transport::tcp::transport] Reading 4 bytes.
[2026-04-22T13:24:15Z TRACE smb::connection::worker::parallel::base] Received message IncomingMessage { message: PlainResponse { header: Header { credit_charge: 0, status: 0, command: Negotiate, credit_request: 1, flags: HeaderFlags { server_to_redir: true, async_command: false, related_operations: false, signed: false, priority_mask: 0, dfs_operation: false, replay_operation: false }, next_command: 0, message_id: 1, tree_id: Some(0), async_id: None, session_id: 0, signature: 0 }, content: Negotiate(NegotiateResponse { security_mode: NegotiateSecurityMode { signing_enabled: true, signing_required: false }, dialect_revision: Smb0311, server_guid: 35396433-3430-6238-3939-636200000000, capabilities: GlobalCapabilities { dfs: true, leasing: true, large_mtu: true, multi_channel: false, persistent_handles: false, directory_leasing: false, encryption: false, notifications: false }, max_transact_size: 8388608, max_read_size: 8388608, max_write_size: 8388608, system_time: FileTime(2026-04-22 13:24:15.909244), server_start_time: FileTime(1601-01-01 0:00:00.0), buffer: [96, 72, 6, 6, 43, 6, 1, 5, 5, 2, 160, 62, 48, 60, 160, 14, 48, 12, 6, 10, 43, 6, 1, 4, 1, 130, 55, 2, 2, 10, 163, 42, 48, 40, 160, 38, 27, 36, 110, 111, 116, 95, 100, 101, 102, 105, 110, 101, 100, 95, 105, 110, 95, 82, 70, 67, 52, 49, 55, 56, 64, 112, 108, 101, 97, 115, 101, 95, 105, 103, 110, 111, 114, 101], negotiate_context_list: Some([NegotiateContext { context_type: PreauthIntegrityCapabilities, data: PreauthIntegrityCapabilities(PreauthIntegrityCapabilities { hash_algorithms: [Sha512], salt: [41, 104, 15, 116, 179, 1, 227, 227, 12, 198, 157, 172, 102, 63, 98, 192, 107, 187, 229, 58, 87, 46, 105, 189, 54, 207, 116, 56, 105, 206, 172, 174] }) }, NegotiateContext { context_type: EncryptionCapabilities, data: EncryptionCapabilities(EncryptionCapabilities { ciphers: [Aes128Gcm] }) }, NegotiateContext { context_type: SigningCapabilities, data: SigningCapabilities(SigningCapabilities { signing_algorithms: [AesGmac] }) }]) }) }, raw: IoVec([Owned([254, 83, 77, 66, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 65, 0, 1, 0, 17, 3, 3, 0, 51, 100, 57, 53, 48, 52, 56, 98, 57, 57, 99, 98, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 128, 0, 0, 0, 128, 0, 0, 0, 128, 0, 216, 166, 30, 81, 91, 210, 220, 1, 0, 0, 0, 0, 0, 0, 0, 0, 128, 0, 74, 0, 208, 0, 0, 0, 96, 72, 6, 6, 43, 6, 1, 5, 5, 2, 160, 62, 48, 60, 160, 14, 48, 12, 6, 10, 43, 6, 1, 4, 1, 130, 55, 2, 2, 10, 163, 42, 48, 40, 160, 38, 27, 36, 110, 111, 116, 95, 100, 101, 102, 105, 110, 101, 100, 95, 105, 110, 95, 82, 70, 67, 52, 49, 55, 56, 64, 112, 108, 101, 97, 115, 101, 95, 105, 103, 110, 111, 114, 101, 0, 0, 0, 0, 0, 0, 1, 0, 38, 0, 0, 0, 0, 0, 1, 0, 32, 0, 1, 0, 41, 104, 15, 116, 179, 1, 227, 227, 12, 198, 157, 172, 102, 63, 98, 192, 107, 187, 229, 58, 87, 46, 105, 189, 54, 207, 116, 56, 105, 206, 172, 174, 0, 0, 2, 0, 4, 0, 0, 0, 0, 0, 1, 0, 2, 0, 0, 0, 0, 0, 8, 0, 4, 0, 0, 0, 0, 0, 1, 0, 2, 0])]), form: MessageForm { compressed: false, encrypted: false, signed: false }, source_channel_id: None }
[2026-04-22T13:24:15Z TRACE smb::connection] Negotiated SMB results: dialect=Smb0311, state=NegotiatedProperties { server_guid: 35396433-3430-6238-3939-636200000000, caps: GlobalCapabilities { dfs: true, leasing: true, large_mtu: true, multi_channel: false, persistent_handles: false, directory_leasing: false, encryption: false, notifications: false }, max_transact_size: 8388608, max_read_size: 8388608, max_write_size: 8388608, auth_buffer: [96, 72, 6, 6, 43, 6, 1, 5, 5, 2, 160, 62, 48, 60, 160, 14, 48, 12, 6, 10, 43, 6, 1, 4, 1, 130, 55, 2, 2, 10, 163, 42, 48, 40, 160, 38, 27, 36, 110, 111, 116, 95, 100, 101, 102, 105, 110, 101, 100, 95, 105, 110, 95, 82, 70, 67, 52, 49, 55, 56, 64, 112, 108, 101, 97, 115, 101, 95, 105, 103, 110, 111, 114, 101], signing_algo: Some(AesGmac), encryption_cipher: Some(Aes128Gcm), compression: None, dialect_rev: Smb0311 }
[2026-04-22T13:24:15Z DEBUG smb::connection] Negotiation successful
[2026-04-22T13:24:15Z DEBUG smb::client::smb_client] Successfully connected to 127.0.0.1
[2026-04-22T13:24:15Z DEBUG smb::session::setup] Setting up session for user /GUEST (@).
[2026-04-22T13:24:15Z ERROR smb::session::setup] Failed to setup session: Sspi error: NoCredentials: Service target name (service principal name) is not provided
[2026-04-22T13:24:15Z TRACE smb::session::setup] No session to cleanup in setup.
[2026-04-22T13:24:15Z INFO  smb::connection] Notification handler stopped.
[2026-04-22T13:24:15Z DEBUG serial_test::rwlock] End serial
Error: SspiError(Error { error_type: NoCredentials, description: "Service target name (service principal name) is not provided", nstatus: None })


failures:
    test_basic_guest

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 5 filtered out; finished in 0.05s

[TheBestTvarynka]

Aviv (@afiffon), thank you for providing the test data. It's very useful! I will look into it tomorrow

[afiffon]

Hi Pavlo Myroniuk (@TheBestTvarynka), had any luck digging into it?

[TheBestTvarynka]

Hi, Aviv (@afiffon)
Well yes, but I'm not finished yet. I will reply today's evening or tomorrow's morning 🙏

[afiffon]

Thanks :) fyi, I have some time to put into it too - I'll let you know if I get anywhere.

[afiffon]

• I took a closer look at what's going on in my test failure.
• Seems like the Negotiate provider requires a the MIC calculation (mic_needed = true) if USE_SESSION_KEY is specified in the context requirements.
• I have specified it for the \GUEST login, and the final NTLM message misses the MIC (as can be seen in the attached screenshot).

Mostly, I think we should check whether or not this behavior is alright:

1. If an accept-completed result is received - there should not be another round of messages (challenge/response) - right?
2. If no MIC is specified in such message:
   2.1. Is it okay there's no MIC and still having a key exchange (I mean, it used to work in older versions - but maybe the spec says otherwise)
   2.2 If it's not okay to try a GUEST login an get a session key, should there be an error?

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-spng/211417c4-11ef-46c0-a8fb-f178a51c2088#Appendix_A_8

[TheBestTvarynka]

Hi, Aviv (@afiffon)

Sorry for my late response. I got sick and could not finish it earlier 🤒

Seems like the Negotiate provider requires a the MIC calculation (mic_needed = true) if USE_SESSION_KEY is specified in the context requirements.

Yes, you are right!

If an accept-completed result is received - there should not be another round of messages (challenge/response) - right?

I read the attached MSDN page. Yes, I think we should not require the MIC token when the server returns accept-complete without it.

I did not count it during refactoring because I tested only on the RDP server, and they always require a MIC token to be exchanged.

How can I run smb-rs tests properly? I cloned the repo, checked out at 474afe20d40e704bffff1742534884eb60dc2cee commit, and run cargo test --no-default-features --features "multi_threaded,sign,encrypt,compress,kerberos" test_basic_guest -- --nocapture, and got connection timeout errors:

running 1 test
[2026-04-28T10:44:00Z INFO  basic::common] Connecting to 127.0.0.1
[2026-04-28T10:44:00Z INFO  smb::connection] Connecting to 127.0.0.1 (at 127.0.0.1:445)...
[2026-04-28T10:44:00Z INFO  smb::connection] Connected to 127.0.0.1. Negotiating.
[2026-04-28T10:44:00Z ERROR smb_transport::tcp::transport] Got IO error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060) -- Mapping to IO error.
[2026-04-28T10:44:00Z ERROR smb::connection::worker::parallel::threading_backend] Error in worker recv loop: Transport error: IO Error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060)
[2026-04-28T10:44:00Z ERROR smb_transport::tcp::transport] Got IO error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060) -- Mapping to IO error.
[2026-04-28T10:44:00Z ERROR smb::connection::worker::parallel::threading_backend] Error in worker recv loop: Transport error: IO Error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060)
[2026-04-28T10:44:00Z ERROR smb_transport::tcp::transport] Got IO error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060) -- Mapping to IO error.

Do I need to set up an SMB server?

[afiffon]

Pavlo Myroniuk (@TheBestTvarynka) first of all, hope you feel well.

To run the test, you'll need to launch the tests container. You should be able to run docker compose up -d test, or take an example from the CI configuration about how to start it. There's some chance you may have a port conflict on Windows, and possible configuring the env to point at the container will solve this.