Debugging Samba Authentication Failures: Complete Guide to Enable Verbose Logging for Windows Client Connections


14 views

When Windows clients report "invalid username or password" errors while connecting to Samba shares, the problem often lies deeper than simple credential mismatches. Let's implement comprehensive logging to diagnose the authentication workflow.

Edit your smb.conf file (typically at /etc/samba/smb.conf) and add these directives in the [global] section:

[global]
   log level = 3 auth:5
   log file = /var/log/samba/log.%m
   max log size = 1000
   debug timestamp = yes
   debug uid = yes

The authentication flow involves multiple stages where things can break:

  • NetBIOS name resolution
  • Initial connection handshake
  • NTLM/NTLMv2 negotiation
  • Password hash comparison
  • Share permission validation

Here's a sample log entry showing successful authentication:

[2023/12/15 14:30:45.123456,  3] ../source3/auth/auth.c:320(check_ntlm_password)
  check_ntlm_password: Authentication for user [bob] -> [bob] succeeded

And a failed attempt might show:

[2023/12/15 14:31:22.654321,  2] ../source3/auth/auth.c:315(check_ntlm_password)
  check_ntlm_password: Authentication for user [bob] FAILED with error NT_STATUS_WRONG_PASSWORD

For deeper analysis, enable packet-level logging:

log level = 10
   include system = yes

Then use tcpdump to capture network traffic:

tcpdump -i eth0 port 445 -w samba_debug.pcap
  1. Username case sensitivity (Windows vs Linux)
  2. Password encoding differences
  3. Incorrect workgroup settings
  4. Kerberos vs NTLM conflicts
  5. System clock skew exceeding 5 minutes

Use smbclient to verify credentials:

smbclient -L localhost -U%username%

Or for specific share access:

smbclient //server/share -Uusername -d3

When troubleshooting Samba authentication issues, it's crucial to understand the complete auth chain. The process involves multiple components: Samba's smbd daemon, the underlying system authentication (PAM or local), and name resolution services. A failed login could originate at any of these stages.

Add these parameters to your smb.conf under the [global] section:

[global]
    log level = 3 auth:5
    log file = /var/log/samba/log.%m
    max log size = 1000
    debug timestamp = yes
    debug uid = yes

Verify these critical settings in your smb.conf:

    security = user
    passdb backend = tdbsam
    encrypt passwords = yes
    name resolve order = lmhosts wins bcast host

Here's how to trace a failed authentication attempt:

# Monitor logs in real-time
tail -f /var/log/samba/log.clienthostname

# Test authentication manually
smbclient -L localhost -U testuser -d3

# Check user mapping
pdbedit -L -v

1. Password sync issues:
Ensure passwords are synchronized between system and Samba:

smbpasswd -a username

2. Windows credential caching:
Clear cached credentials on Windows clients:

cmdkey /delete:servername
net use * /delete /y

For enterprise environments, consider these additional tools:

# Packet capture for protocol analysis
tcpdump -i eth0 port 445 -w samba.pcap

# SELinux context verification
ls -Z /var/lib/samba/
getsebool -a | grep samba

Create a test script to verify configurations:

#!/bin/bash
SERVER=localhost
SHARE=testshare
USER=testuser
PASS=testpass

smbclient -L $SERVER -U $USER%$PASS && \
    echo "Authentication successful" || \
    echo "Authentication failed"