Hi! If printing suddenly shows Windows “Access is denied” right after an AD password change, the most common cause is an authentication mismatch: your session is still using old Kerberos tickets (Kerberos cache) or saved credentials when it talks to the print server / shared printer.

This often looks like:
• “Access is denied” or error 0x00000005
• “Cannot connect to printer” / “Windows cannot connect to the printer”
• Works for some users, fails for others, or fails only in RDP / terminal server sessions

Quick questions so we pick the fastest fix path (no guesswork):
• Are you printing via a shared printer on a Windows print server (\\PrintServer\PrinterName), or direct IP printing?
• Does printing fail from all apps (Word/PDF/browser), or only from one app?
• Did the user only change the password, or also move groups / change permissions in AD?
• Does logging off/on fix it, or does it persist until reboot?

Once I know that, I’ll walk you through clearing the Kerberos cache (often klist purge), refreshing the session, and re-connecting the printer share cleanly.

That pattern (after password change + shared printer + inconsistent users) is very “Kerberos cache / cached credentials” flavored.

Here’s what usually happens in plain terms:
• A user logs in, Windows gets Kerberos tickets for AD resources.
• They change their AD password, but their current session still has valid-looking cached tickets (or stale credentials used by certain processes).
• When the PC tries to authenticate to the print server, the server rejects the session and Windows surfaces “Access denied” when printing or re-connecting the printer share.

We’ll fix it in the least disruptive order: refresh session → purge Kerberos tickets → remove stale printer connection → re-add printer → confirm print server permissions. This also covers related cases like GPO-deployed printers and RDS/terminal server users.

Got it — RDS makes this more likely because you can have multiple logon sessions and background processes holding old auth.

Step 1 — Confirm it’s really auth and not printer ACLs
On one affected user machine, try opening the print server share in File Explorer:
\\PRINT01
If they’re prompted for credentials, or it errors, that’s a strong sign of cached auth/credential issues (not the printer driver). Printing is just the symptom.

Step 2 — Quick Kerberos cache reset (most effective after AD password change)
On the affected workstation (or inside the affected RDS session), open Command Prompt (regular is fine) and run:
klist
This lists cached Kerberos tickets. Then run:
klist purge
That clears the user’s Kerberos ticket cache so Windows must request fresh tickets using the new password.

After that, do a full sign out (not just lock/unlock), sign in again, and test printing. This combination (purge + new logon) fixes the majority of “Access denied printing after password change” cases.

That’s a classic RDS twist: the laptop session and the RDS session have different logon contexts, so you can clear the Kerberos cache on the laptop but the RDS session still holds stale tickets or cached credentials.

Step 3 — Clear Kerberos cache inside the RDS session
Have the user launch Command Prompt inside the RDP session and run:
klist purge
Then fully sign out of the RDS session (don’t disconnect; log off), reconnect, and try printing again.

Step 4 — Remove the stale printer connection (GPO printers can still cache per-user)
If “Remove device” fails or it keeps coming back, the goal is to clear the per-user connection and re-map the printer share with fresh authentication.

A clean approach (works well with “cannot connect to printer”):
• In the RDS session, open “Run” and type: printui /s /t2
• Remove the affected printer (only if it appears).
• Sign out of the RDS session.
• Sign back in and let GPO re-deploy it, then test print.

This sequence also helps when Windows keeps a broken connection to \\PRINT01 using old tickets, causing 0x00000005.

Yes — that’s one of the biggest “why won’t it accept the right password?” traps. When Windows has saved cached credentials (Credential Manager / Windows Credentials) for the print server, it can keep reusing the wrong identity or wrong password even after you type the new one.

Step 5 — Clear saved Windows credentials for the print server
On the affected machine (or inside the RDS profile), open:
Control Panel → Credential Manager → Windows Credentials
Look for entries referencing:
• PRINT01 or \\PRINT01
• Any “TERMSRV/…” entries if this is RDS related

Remove the PRINT01-related saved credentials, then do:
• klist purge (again), and
• Sign out / sign in.

Related SEO keywords you’ll see admins use for this exact scenario: stale Kerberos tickets, cached credentials, domain account password change, and “Access denied when connecting to shared printer”.

Great diagnostic clue: if only one printer share fails, we should verify it’s not simply queue permissions or a print server policy issue.

Step 6 — Check printer share / queue permissions (print server side)
On the print server, open Print Management and check that affected users/groups have:
• Print permission on the queue, and ideally
• no accidental “Deny” on a group they’re in.

If permissions look fine, the next layer is authentication plumbing:
• Kerberos relies on correct service identity and ticketing. In normal print-server scenarios, users authenticate to the server and then to the spooler service. Misconfigurations are rare, but after changes (server rename, cloning, weird DNS, time skew), Kerberos can become picky and you’ll see intermittent “Access denied”.

Practical check that catches many cases: verify system time is correct on clients and the print server (Kerberos is time-sensitive), and ensure DNS resolves PRINT01 consistently.

Absolutely — here’s a user-friendly, non-admin workflow specifically for Windows printing “Access denied” after AD password change. It covers the most common causes: Kerberos cache + saved credentials + stale printer connection.

User checklist (no admin rights):
1) Save work, then sign out of Windows (don’t just lock) and sign in with the new AD password.
2) Open Command Prompt and run: klist purge (clears Kerberos tickets).
3) Open Credential Manager → Windows Credentials → remove anything for PRINT01 (or the print server name).
4) Reconnect the printer share (or wait for GPO printer deployment to re-map it).
5) Print a test page from Notepad/Word. If it fails, note the exact error text (0x00000005 / Access is denied).

RDS note: Users must do steps 2–4 inside the RDP session too, because the terminal server keeps its own Kerberos tickets for that session.

It can be related, but it’s usually the “second-order fix” — restarting Print Spooler can drop a stuck connection or a bad job state, which makes it look like authentication suddenly fixed itself.

Think of it this way:
• Kerberos ticket / credential problems cause the server to reject access (Access denied, 0x00000005).
• A stuck spooler or broken printer connection can keep retrying the same failing auth path until you reset it.

If you want a stable IT-side fix (especially for RDS farms):
• Ensure users purge tickets in-session after password change (klist purge).
• Remove saved credentials for the print server.
• If printers are flaky, restart the spooler on the affected machine/RDS host as a last step.

Related keywords admins search for here: print spooler access denied, cannot connect to printer after password change, Kerberos tickets not updating.

Absolutely — here’s a clean “accepted fix” that matches the real root cause (stale Kerberos cache / cached credentials) and works for Windows 10/11 + print servers + RDS:

After an AD password change, if printing to a shared printer (\\PRINT01\Printer) fails with Access is denied / 0x00000005, sign out and sign back in using the new password, then clear the user’s Kerberos tickets by running klist purge. Remove any saved Windows credentials for the print server in Credential Manager, sign out/in again, and re-connect the printer share (or let GPO re-deploy it). If the issue persists only in RDS, repeat the same steps inside the RDP session. If a single queue still fails, verify print server queue permissions for that printer. If you want, start a chat and I’ll tailor the exact steps for your environment (print server, GPO, RDS).