• Status: Solved
  • Priority: Low
  • Security: Public
  • Views: 55
  • Last Modified:

Make Kerberos work even with wrong time on server

This is a strange one.  I have a developer who wants to test code on a dev server, but.... he has to change the clock for some reason.  Meaning the time is off on the server from the time on the rest of the domain.  So, once his PowerShell script changes the clock it then can't continue because Kerberos freaks out.  (PowerShell is running on his laptop and remoting into said server, but he doesn't change his laptop's time)

"Starting a command on the remote server failed with the following error message: WinRM cannot process the request.  The following error with errorcode 0x80090324 occured while using Kerberos authentication: There is a time and/or date difference between the client and server."

Everything I Google talks about time syncing errors and how to fix that... but that's not the problem.  I WANT time to be off and authentication to work.
Tim Phillips
Tim Phillips
  • 2
2 Solutions
Cliff GaliherCommented:
Uhhh. That's sort of core to kerberos. Usually when a developer wants to do something that seems unreasonable,  it *is* unreasonable.

Push back. Of changing time is really that important, it can be done on a sandbox (non-domaon-joined or a separate dev-only domain)  and the dev/test client can also be set to the wrong time so they are still in sync.
Tim PhillipsWindows Systems AdministratorAuthor Commented:
They found a work around.  They are sending script block over that changes the date and then after a certain amount of time it resyncs the clock via NTP.  The idea is to run his process outside of that but within the time constraint (300 seconds).  Example:

here's the script
Invoke-Command -ComputerName DEVSERVER -ScriptBlock {$DateTime = New-Object DateTime 2019, 5, 10
    Set-Date $DateTime -ErrorAction SilentlyContinue
    Start-Sleep -Seconds 300
    w32tm /resync /force
    Start-Sleep -Seconds 5
    w32tm /resync /force} -ErrorAction SilentlyContinue

He had to run the w32tm command twice because the first time it says "stale".
Tim PhillipsWindows Systems AdministratorAuthor Commented:
Essentially Cliff is correct, but we came up with a nifty work around for our issue.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now