Windows 11 authentication with kerberos trust: date/time difference between client and server

Question

We operate a kerberos trust between our domain controllers and a Linux-based kerberos KDC for user authentication; users in Active Directory have an altSecurityIdentity field set pointing to "Kerberos:<username>@<REALM>" to authenticate user <username> via the kerberos KDC. We have a significant Linux install base, and this allows us to keep all password authentication in one source.

Windows 11 clients, once joined to our domain, report "There is a time and/or date difference between the client and server." Windows 10 clients and Server 2016/2019/2022 systems authenticate as expected without the time/date error. All are configured to sync clocks from a local NTP server on-site. Time and date, as seen on the desktop or via the "date" and "time" commands. Windows 11 clients do correctly report if the kerberos password is typed incorrectly.

Any idea why Windows 11 is failing these kerberos authentications? It's as if Windows 11 isn't using the same base time when authenticating against our KDCs, perhaps not applying timezone information appropriately.

Answer 1

Time zones don't really have anything to do with it. The times are all compared via UTC times.

All are configured to sync clocks from a local NTP server on-site

A better method is to make use of the windows time service. You could sync the PDC emulator with your local NTP source then let NT5DS domain time take care of the reset.

Some general info

• All domain members should use NT5DS domain time.
• Desktops and member servers sync with any domain controller.
• Domain controllers sync with PDC emulator (one per domain)
• PDC emulator in child domain can sync with any domain controller in parent domain.
• PDC emulator in parent domain syncs with either a hardware clock or possibly an external source. https://blogs.technet.microsoft.com/nepapfe/2013/03/01/its-simple-time-configuration-in-active-directory/

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 2

For the PDC emulator you can do

w32tm /unregister
net stop w32time
w32tm /register
net start w32time
w32tm /config /manualpeerlist:<ntp ip address> /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time

then check

w32tm /query /source
w32tm /query /configuration

Answer 3

For all other members and domain controllers you could do

w32tm /unregister
net stop w32time
w32tm /register
net start w32time
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time

then check

w32tm /query /source
w32tm /query /configuration

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 4

Glad to hear of progress. You may need to reach out to the kerberos-based security identity provider for assistance with that issue.

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 5

It turns out this was an issue with the age of the KDC we had in service.

Our KDC was running MIT Kerberos 1.15.1 from the CentOS 7 Linux distribution. Turns out it is afflicted by the issue detailed in this post: https://github.com/heimdal/heimdal/issues/1011 (The linked git issue was against the Heimdal Kerberos distribution, not MIT Kerberos...both distributions had the problem.)

The TGS request would come through with "until time" listed greater than what our old KDC could deal with and proceeded to fail with a less-than-intuitive response.

Spinning up a Ubuntu Linux 22.04 KDC using MIT Kerberos 1.19.2 authenticates as expected.

It was time to update the old KDCs anyway. We are able to get a replica server for Windows 11 hosts to authenticate against as a short-term fix until all KDCs are running more modern code.

Thank you, Dave Patrick, for your detailed information on sync'ing clocks. I wish our problem were as simple as sync'ing clocks...certainly less work than upgrading KDCs.