What 0X000008C1 Actually Means
You try to log in. Windows says no. The event log or the error dialog spits out 0X000008C1, which maps to NERR_InvalidLogonHours. In plain English: the account you're using has a time-of-day restriction baked into it, and right now you're outside the allowed window. Windows isn't confused. It's enforcing a schedule.
This is almost always a domain account issue. Local accounts can have logon hours too, but 99% of the tickets I see come from Active Directory, where an admin set hours via the "Logon Hours" button in ADUC and forgot about it. The user shows up at 7:15 AM. Their window starts at 8:00 AM. Boom, 0X000008C1.
Here's the thing: the error can pop on a workstation login, an RDP session, a mapped drive auth, or even a scheduled task running under that account. You'll see Event ID 4625 in the Security log with a Status of 0xC000006F if it's an interactive logon, but the underlying reason is the same restriction.
Work through the fixes below in order. Stop when it works.
Fix 1: The 30-Second Check (Are You Actually Outside the Window?)
Before you touch anything, verify the account's allowed hours. If you don't have admin rights, you'll need whoever does. If you're the admin, open an elevated Command Prompt on the domain controller (or any machine with RSAT and the right creds).
net user "username" /domainScroll to the bottom. You'll see a line that says Logon hours allowed followed by a series of blocks like M 12:00 AM - 11:59 PM or a broken-up schedule. If that line shows anything other than all days, all hours, the account has a restriction.
Compare that to the current local time on the machine the user is logging into. Time zone mismatches bite people here. The domain controller evaluates hours in the DC's local time, not the user's. If your DC sits in UTC and the user is in Dallas, a window that looks fine on paper can still block them.
Expected result: You'll see whether the current time falls inside or outside the allowed blocks. If it's outside, that's your cause. Move to Fix 2. If everything looks open, jump to Fix 3 — something else is enforcing the limit.
Fix 2: The 5-Minute Fix (Remove or Adjust the Hours)
You've got two ways to do this: the GUI or the command line. I'll give you both because the GUI is easier for one-offs and the command line is what you want when you're scripting or working over SSH.
Option A: Active Directory Users and Computers (ADUC)
- On a machine with RSAT installed, open Active Directory Users and Computers.
- Find the user account. Right-click it and choose Properties.
- Click the Account tab. Look for the Logon Hours button near the middle. Click it.
- A grid appears — days down the left, hours across the top. Click All to select everything, then click Logon Permitted.
- Click OK, then OK again on the Properties window.
Expected result: The user's logon hours are now 24/7. Have them try again. If they were hitting the restriction, this clears it immediately — no reboot, no waiting for replication for the local DC. If they're in a different AD site, give replication 15 minutes or force it with repadmin /syncall /AdeP.
Option B: Command Line
Want to nuke the restriction from a script or a remote session? Use net user. The trick is the /time switch and the ALL keyword.
net user username /time:all /domainThat's it. One line. It sets the account to allow logon at all times. If you want to set a specific schedule instead of wiping it entirely, the syntax is clunky but workable:
net user username /time:M-F,8am-5pm /domainThat gives Monday through Friday, 8 AM to 5 PM. Note the region settings on the machine running the command affect how "8am" is parsed. On a US-English box it's fine. On a German locale you might need 08:00-17:00. Test before you assume.
Expected result: The command returns The command completed successfully. Have the user retry. If the error is gone, you're done. If it's still there, the restriction isn't the only thing in play — go to Fix 3.
Fix 3: The 15-Minute Fix (When Hours Aren't the Real Problem)
Sometimes the hours look wide open and 0X000008C1 still fires. That's when you stop trusting the GUI and start digging. Here's where I go.
Check the PDC Emulator's Time
Logon hour evaluation happens against the PDC Emulator's clock. If that DC has drifted — even by 20 minutes — schedules that look fine break. Check it:
w32tm /query /status /verbose
w32tm /stripchart /computer:time.windows.com /samples:3If the offset is more than a minute or two, resync:
w32tm /resync /forceOn a virtualized DC, disable time sync with the host. VMware Tools and Hyper-V Integration Services both try to sync the guest clock to the host, and that fights w32time. This is a real, common cause of phantom logon failures in shops that virtualized their DCs and never thought about it again.
Check for Fine-Grained Password Policies
An AD admin may have applied a Fine-Grained Password Policy (PSO) that includes logon hours. These override the standard domain policy and don't show up in ADUC's Account tab. Check it with PowerShell:
Get-ADUserResultantPasswordPolicy -Identity usernameIf that returns a PSO, look at its settings. If a PSO is enforcing hours, you'll need to edit it via Set-ADFineGrainedPasswordPolicy or remove the user from the PSO group.
Check for Local Policy on the Target Machine
If this is a local account (not domain), the restriction lives on the box itself. Run on the affected machine:
net user usernameThe same "Logon hours allowed" line appears. Fix it with:
net user username /time:allNo /domain flag this time — you're targeting the local SAM.
Check Event 4625 for the Full Story
Open Event Viewer. Go to Windows Logs > Security. Filter for Event ID 4625 (failed logon). Find the one that matches your attempt. The Status field will show 0xC000006F if it's truly logon-hours related. If you see 0xC000006A instead, the password is wrong. If you see 0xC0000234, the account is locked. Don't chase the wrong error.
When to Escalate
If you've cleared hours, checked time sync, ruled out PSOs, and it still fails, something upstream is wrong. Common culprits:
- A GPO that applies Network security: Force logoff when logon hours expire and is doing its job a little too well.
- A third-party identity provider (Okta, Azure AD Connect, Duo) syncing a bad hours attribute down from the cloud.
- An old service account that a scheduled task runs under and someone changed the hours without telling anyone.
Pull a full gpresult /h report.html on the target machine and read the Applied GPOs section. That's where the paper trail usually lives.
The Bottom Line
0X000008C1 isn't mysterious. It's Windows politely telling you that an account has a curfew. Fix the curfew — net user username /time:all /domain is your fastest path — and the error goes away. If it doesn't, the problem isn't the hours anymore. It's time sync, a hidden policy, or a cloud sync pushing stale data. Work the flow, and you'll get there.