macOS Kerberos printing fails on SMB shares — ticket renew fix

Hi! We can fix macOS Kerberos printing fails on SMB shares by narrowing down which layer is breaking: (1) the Mac doesn’t have a valid Kerberos ticket (TGT), (2) the SMB connection is falling back to NTLM and then prompting for credentials, or (3) the print queue is configured in a way that forces credentials even when Kerberos SSO should work.

This shows up as: SMB shared printer won’t print, “authentication failed”, “unable to connect to printer”, print job stuck in queue, or repeated password prompts on macOS (Sonoma/Ventura/Monterey). In many environments (Active Directory / Windows print server), it works for a while and then fails after sleep/VPN/network change because the Kerberos ticket expires and doesn’t renew in the way printing expects.

Quick questions so I can give you the right “ticket renew” fix without guesswork:
• What macOS version are you on (Sonoma / Ventura / etc.)?
• Is this a Windows print server shared printer (e.g., `smb://printserver/printershare`) or a direct SMB share on a file server?
• Do you see a password prompt when printing, or does it fail silently / “hold for authentication”?
• Are you on VPN or switching networks (Wi-Fi ↔ Ethernet, office ↔ home) when it fails?
• If you can, what’s the exact error text (even a short line from the printer queue or macOS notification)?

Once you answer, I’ll walk you through a step-by-step: check tickets with klist, renew with kinit, clear stale creds (Keychain + cached tickets), validate time sync/clock skew, and if needed rebuild the SMB/CUPS queue so Kerberos/GSSAPI is used correctly.

That pattern is classic: Kerberos ticket renew doesn’t happen the way the SMB print path expects after sleep/VPN/network changes, so macOS tries SMB auth again, fails Kerberos, and then falls back to NTLM (which triggers the password prompt). Even if you type credentials, it can keep failing if the Mac is holding stale Keychain SMB credentials or the print queue is stuck using an old auth context.

Let’s fix this in the safest order (quick wins first). We’ll confirm whether you currently have a valid Kerberos TGT, then renew it, then clean up anything that forces NTLM/credentials prompts.

Step 1 — Check if your Kerberos tickets are present and not expired
On the Mac, open Terminal and run:
• klist
Look for a ticket-granting ticket (TGT) like yourname@YOUR.REALM and check the Expires time. If it’s missing or expired, printing to an SMB shared printer often fails immediately or prompts for credentials.

Step 2 — Renew/acquire a fresh Kerberos ticket (the “ticket renew fix”)
If the ticket is expired or missing, run:
• kinit yourname@YOUR.REALM
Enter your password when prompted. Then run klist again to confirm a fresh ticket appears with a new expiry time.

Step 3 — Confirm the SMB share/printer connection is using the expected identity
If you can, also tell me the printer path format you’re using (something like smb://server/printer or a Windows share name). The exact SMB URL can affect how macOS chooses Kerberos vs NTLM.

Perfect — that confirms the root cause: printing fails when the Kerberos ticket expires, and a manual kinit ticket renewal restores access temporarily. Now the goal is to stop the “works → expires → SMB printing fails” loop and prevent macOS from caching the wrong thing (like NTLM creds in Keychain) when Kerberos isn’t available.

There are three common reasons Kerberos tickets don’t stay usable for SMB printing on macOS Sonoma:
(A) Ticket renewal isn’t happening automatically after sleep/VPN/network changes.
(B) Time drift / clock skew (even a few minutes) breaks Kerberos, causing immediate auth failures to SMB shares/print servers.
(C) Credential conflicts — stale SMB passwords saved in Keychain force NTLM or confuse the auth negotiation (Kerberos vs NTLM fallback).

Let’s do a “clean renew” and remove the main blockers:

Step 1 — Do a clean ticket reset (not just kinit)
In Terminal:
• kdestroy (this clears existing cached Kerberos tickets)
• kinit yourname@YOUR.REALM (get a fresh TGT)
• klist (verify the new ticket and expiry)

Step 2 — Fix the #1 silent killer: clock skew
On corporate networks, Kerberos is strict about time. If your Mac’s time is off (sleep, travel, VPN), SMB Kerberos auth can fail and then printing breaks. Check: System Settings → General → Date & Time → ensure “Set time automatically” is on. If you’re on VPN, the time source should still be reliable (NTP).

Step 3 — Remove cached SMB credentials that trigger NTLM prompts
Open Keychain Access and search for entries like:
• print01, company.local, smb, cifs, or the printer share name.
If you see saved passwords for that server/share, remove them (or at least remove duplicates/old ones). Stale entries can cause “it keeps asking for a password” even when Kerberos is valid.

After these steps, try printing again. If it still fails later, we’ll make it resilient across sleep/VPN by checking how the queue authenticates and how Sonoma reacquires tickets.

Great question — it’s usually both, but in a specific way: CUPS is the print system on macOS, and it hands off the job using an SMB backend. When Kerberos is valid, the SMB backend negotiates Kerberos/GSSAPI and it prints. When the Kerberos ticket is missing/expired or the network path changes (VPN reconnect), the SMB auth negotiation fails and CUPS reports it as “hold for authentication” or “unable to connect”.

Here’s how we make it stable across VPN reconnects and sleep on macOS Sonoma:

1) Confirm ticket state immediately after VPN reconnect
Right after you reconnect VPN (before printing), run:
• klist
If you don’t see a valid TGT, printing to an SMB share printer will almost always fail. The practical fix is to reacquire a ticket right after network changes (manual or managed via your org’s SSO configuration).

2) Make sure macOS isn’t “locking in” NTLM
If you ever typed a password prompt, macOS may have saved it (Keychain), and subsequent attempts may try NTLM first (or the server may reject NTLM). This creates the loop: password prompt → fails → queue holds. Clearing Keychain entries for the print server helps keep Kerberos as the primary method.

3) Verify the Mac can reach the domain controllers when on VPN
Kerberos requires contacting AD/domain services to get/renew tickets. If VPN allows print server access but blocks domain controller access, you’ll see: SMB printing fails + no automatic ticket renewal. That’s a network/policy issue (not your fault), but we can still work around it: renew the ticket while you still have a valid path to AD, or adjust VPN split-tunnel rules (IT side).

4) CUPS queue sanity check
If jobs stick frequently, we may rebuild the queue so it doesn’t keep using an old auth state. Rebuilding is often faster than chasing a poisoned queue after multiple failed auth attempts.

Fastest “back to printing” checklist (works for most macOS SMB printer Kerberos authentication failed cases):

Fast Fix A — Renew tickets (most common)
1) Terminal: klist
2) If missing/expired: kdestroy then kinit yourname@YOUR.REALM
3) Confirm with klist and try printing again.

Fast Fix B — Stop the NTLM/password prompt loop (Keychain)
If it keeps prompting even after a fresh ticket, open Keychain Access and remove old saved passwords for print01 / company.local. This prevents stale SMB creds from overriding Kerberos and helps avoid NTLM fallback behavior.

Fast Fix C — Clear the stuck print job state
In the printer queue: delete the held jobs, then print a small test page. After an auth failure, a queue can sit in “held for authentication” and won’t recover until the failed jobs are cleared.

Related/secondary keywords that match what you’re describing (and what we’re fixing): Kerberos ticket expired macOS, SMB shared printer prompts for password, macOS print server authentication failed, SMB Kerberos not renewing after VPN, CUPS hold for authentication SMB, NTLM fallback macOS SMB.

If you tell me whether you’re using a managed SSO tool (Kerberos SSO extension / Jamf Connect / enterprise login), we can often make the “renew” happen automatically on network changes instead of manual kinit.

Yes — you can verify Kerberos vs NTLM behavior with a practical, non-invasive approach (and it helps isolate “valid ticket but still fails”).

How to tell if SMB printing is using Kerberos
• If printing works immediately after kinit and fails when tickets expire, that’s already a strong Kerberos signal.
• When Kerberos fails, macOS often shows a credentials prompt (username/password). That prompt is usually NTLM/basic auth fallback, not true Kerberos SSO.

When the ticket looks valid but printing still fails, these are the top causes:
1) Ticket is valid, but the service ticket needed for the print server can’t be obtained
You may have a TGT, but the Mac can’t reach a domain controller to get the right service ticket after VPN changes (common with split-tunnel VPN). This results in “auth failed” even though klist shows a TGT.

2) SPN / service mapping issues on the Windows side (IT-side, but common)
If the print server service principal name (SPN) is mismatched (or duplicated), Kerberos can fail and then you get prompts or errors. This is often intermittent and user-visible as “worked yesterday, fails today.”

3) SMB settings / signing / protocol mismatch
Some environments require SMB signing or restrict NTLM. If macOS flips to NTLM and the server blocks it, you’ll see repeated prompts and failures. The fix is keeping Kerberos healthy (tickets + reachability) and removing stale credentials that push NTLM.

4) “Poisoned” CUPS queue after repeated auth failures
After multiple failed attempts, rebuilding the SMB printer queue can reset the auth context and clear “hold for authentication” behavior.

If you want a quick next step: right after it fails (before you run kinit), run klist. If the TGT is missing/expired, ticket renewal is the fix. If the TGT is present but printing fails, we focus on reachability to domain controllers over VPN + Keychain cleanup + queue rebuild.

Deleting duplicate/stale SMB passwords in Keychain is usually safe — and in this scenario it’s often the difference between Kerberos SSO working and macOS constantly prompting for credentials.

Keychain cleanup (safe approach)
• In Keychain Access, search for the exact server and domain: print01, company.local, smb, cifs.
• If you see multiple “Internet password” items for the same host/share, remove the older duplicates first. The goal is to prevent macOS from offering the wrong credentials (NTLM) when Kerberos should be used.
• If something needs credentials later, it will prompt once and you can store the correct one — but in Kerberos environments, the ideal is that you don’t get prompted at all when the ticket is valid.

Rebuild the SMB printer queue (safe method)
1) System Settings → Printers & Scanners → select the printer → remove it.
2) Restart the Mac (this clears stuck CUPS state in many cases).
3) Add the printer again using the same SMB path (or the method IT recommends). If there’s an option for the protocol (SMB vs IPP), stick to what your org expects for Kerberos SMB printing.
4) After adding: run klist to confirm you still have a valid Kerberos ticket, then print a small test page.

Why this works: after repeated “authentication failed” events, CUPS can keep retrying with the wrong cached auth context. A rebuild resets the queue and forces a fresh negotiation (Kerberos first, if tickets and reachability are correct).

If VPN is blocking domain controller reachability, you may still need the “ticket renew fix” (kdestroy/kinit) after reconnect — unless IT configures Kerberos SSO to reacquire tickets on network changes.

Absolutely — here’s the practical playbook for macOS Kerberos printing fails on SMB shares (short-term recovery + long-term stability).

Immediate fix (when SMB printing suddenly fails)
1) Check tickets: klist
2) If expired/missing: kdestroy → kinit yourname@YOUR.REALM → confirm with klist
3) Clear stuck jobs: delete held print jobs (“hold for authentication”), then retry a small test print.
4) If you see password prompts: remove stale SMB credentials in Keychain for the print server/share (prevents NTLM loop).

Long-term prevention (stop recurring failures)
1) Time sync: ensure Date & Time auto-sync is enabled (avoids Kerberos clock skew).
2) VPN reachability: confirm VPN allows access to domain controllers/AD for ticket renewal (otherwise tickets won’t refresh and SMB Kerberos auth fails).
3) Avoid credential conflicts: don’t store multiple passwords for the same SMB host; keep Keychain clean for that server.
4) If the queue keeps poisoning: remove/re-add the SMB printer to reset CUPS and force a clean Kerberos negotiation.

If you want, start a chat and share your macOS version + whether you’re domain-joined/SSO-managed + your exact SMB printer URL, and I’ll tailor the most stable setup (and tell you what to ask IT about VPN/DC reachability).

If tickets are fresh and Keychain/queue are clean but SMB Kerberos printing still fails intermittently, the next likely causes are usually IT-side (or network-policy-side). Here’s the priority list so you can speak their language:

Next causes to check (often IT-owned)
• VPN split-tunnel blocks AD/DC traffic: you can reach the print server, but not the domain controllers, so the Mac can’t get/renew the correct service tickets after reconnect. Result: “authentication failed” even though you’re “on VPN.”
• SPN / Kerberos service mapping issues on the Windows print server: duplicate/mismatched SPNs can cause Kerberos errors and force fallback. This is invisible to end users but shows up as random auth failures across devices.
• Server policy changes: disabling NTLM or tightening SMB signing/encryption requirements can change behavior overnight. macOS then prompts for creds or fails if negotiation doesn’t match policy.
• Account/password policy: expired AD password or lockouts can present as Kerberos renew failures and break printing first (because printing is a frequent background auth use).

If you chat me the exact moment it fails (after sleep, after VPN reconnect, after password change) plus what klist shows at that moment, I can tell you whether it’s a local ticket/Keychain problem you can fix, or a domain/VPN/SPN issue that needs IT to adjust.