Fix 0x530 Logon Hours Restriction: Step-by-Step

Cause #1: Active Directory Logon Hours Are Set Too Restrictive

If you're on a domain, the most common reason for 0x530 is that an admin set logon hours in Active Directory. This happens more than you'd think — someone configures "allow only 9-5" and forgets that a batch job or a service account needs off-hours access. The error shows up at the exact moment the system tries to authenticate outside the allowed window.

Here's how to check and fix it:

1. Open Active Directory Users and Computers (dsa.msc) on a domain controller.
2. Find the affected user account, right-click, and select Properties.
3. Go to the Account tab, then click Logon Hours.
4. You'll see a grid — blue means allowed, white means blocked. Update the hours to cover the times that user actually needs.

If you're managing a service account, you might want to set it to Logon Permitted for all hours. That's usually safer than trying to fine-tune it and breaking something at 2 AM. I've seen companies lose a whole night's batch processing because someone left a lunch break blocked.

Remember: Changes to logon hours take effect immediately, but existing sessions are not dropped. The user gets kicked out only when they attempt a new logon.

Cause #2: Local Security Policy on a Standalone Machine

For non-domain machines — maybe a kiosk or a lab computer — the same error comes from the local security policy. Windows has a built-in setting that restricts logon hours per user, and it's often misconfigured by accident.

Check it like this:

1. Press Win + R, type secpol.msc, and hit Enter.
2. Go to Security Settings → Local Policies → User Rights Assignment.
3. Look for Log on locally or Allow log on through Remote Desktop Services. If the user isn't listed there, they're blocked.

But wait — the real culprit is often the Logon Hours setting under Local Users and Groups (lusrmgr.msc). Open that, double-click the user, and check the Hours button. I've seen new techs overlook this because they only check the user rights, not the actual time constraints.

To fix, just set the allowed hours to all-day or adjust to what they need. Then reboot or run gpupdate /force if it's GPO-driven.

Cause #3: Cached Credentials and Offline Logons

Here's a sneaky one: the error can pop up even when logon hours are fine, because Windows has cached credentials from a previous session. This happens on laptops that went to sleep during an allowed period and woke up outside it. The cached credential timestamp is stale, and the system thinks the logon is still in the restricted window.

The fix is simple:

1. Have the user log on while the domain controller is reachable and within allowed hours.
2. Clear the cached credentials using cmdkey /list to see what's stored, then cmdkey /delete <target> for the relevant one.
3. Or just reboot the machine after the allowed hours start — sounds dumb, but it clears the stale state.

I've also seen this happen when a user changes their password and immediately tries to log in with old cached credentials. The error message is misleading, but the underlying cause is a credential mismatch combined with logon hour checks.

If you're in a hurry, the quickest workaround is to have the user log in as another account (like a local admin) and then switch users. That forces a fresh authentication against the DC.

Quick-Reference Summary

Bottom line: 0x530 is almost always a time restriction, not a password problem. Start with AD logon hours if you're domain-joined. If that's clean, move to local policy. And don't forget the cached credential angle — it's rare, but it'll bite you when you least expect it.