1

Currently trying to implement a simple KDC using the Kerberos.Net nuget..

I have successfully gotten a token via the bruce tools that follow along, but if I try via java's kinit or MIT Kerberos client windows I get: (NOTICE i get same error with the kerberos.net samples)

kinit: ASN.1 failed call to system time library while getting initial credentials

If I try from a Ubunto 20.04 machine, with knit (installed krb5-client), I get the following error.:

Kerberos.NET.KerberosValidationException: Timestamp window is greater than allowed skew. Start: 7/14/2042 1:04:05 AM +00:00; End: 10/15/2021 12:13:14 PM +00:00; Skew: 00:05:00 at Kerberos.NET.Server.PaDataTimestampHandler.Validate(KrbKdcReq asReq, PreAuthenticationContext preauth) in C:\Kerberos.NET-develop\Kerberos.NET\Server\PaDataTimestampHandler.cs:line 60

Setup running is a:

AD-DC windows serv. 2019 Windows 10 client (Joined above domain) Console app (KDC) on a second windows 10 client Ubuntu 20.04

Goal have own kdc be trusted by AD-DC, and allow login.

enter image description here

Rune Jørgensen
  • 281
  • 1
  • 3
  • 7

1 Answers1

0

Well that's a new one (I'm the project maintainer). Basically what's happening is you've somehow sent a request where the timestamp is the year 2042.

The KDC code knows the current time is 10/15/2021 12:13:14 PM (I guess you typed a random value there 12-13-14?), and it's expecting a value sent by the client to be that time +/- the skew of five minutes. Since 2042 falls outside now +/- 5 minutes it's going to fail the request.

I don't have much more guidance other than the client time is way out of whack and needs to be better aligned with the KDC's time source.

Steve
  • 4,463
  • 1
  • 19
  • 24
  • Well I run both the windows 10 client (Kerberos MIT Client) and Ubuntu on Hyper-V's both are in sync with my local time, and if I use bruce (nice tool btw) the token seems to be alright.. From what I can research 1 issue is pre-auth :) And I have tried reading through your articles also, but nothing has helped so far... – Rune Jørgensen Oct 15 '21 at 17:47
  • Could it have something to do with that C# has minDate = 0001-01-01 and java uses 1970-01-01 as seen here https://alvinalexander.com/java/jwarehouse/openjdk-8/jdk/src/share/classes/sun/security/krb5/internal/KerberosTime.java.shtml (search for Krb5.ASN1_BAD_TIMEFORMAT) – Rune Jørgensen Oct 18 '21 at 09:29
  • Kerberos.NET.KerberosValidationException: Timestamp window is greater than allowed skew. Start: 7/14/2042 1:04:05 AM +00:00; End: 10/18/2021 11:49:30 AM +00:00; Skew: 00:05:00, while the end date is the current date time (as returned by time sync in windows) From a Test I just did, where my Ubuntu machine was set to a date of 1 april 2032, note that the start date is still the same – Rune Jørgensen Oct 18 '21 at 11:51
  • I've added a picture that shows the asReg body, seems the 2042 date is the till date, so the code might actually take in the wrong date – Rune Jørgensen Oct 18 '21 at 12:53
  • Date/time is sent in absolute values as strings, so `7/14/2042 1:04:05 AM +00:00` (in ASN's own format) is the literal value being sent over the wire. There's no funky date math going on. The client is sending that value. You can verify it by looking at the request through wireshark, which will have an independent value parser. – Steve Oct 18 '21 at 15:22
  • And for completeness it's probable that the reason AD doesn't care is because it has a special error handling model that returns the KDC's current time so the client can retry with that. Kerb.net doesn't have that. – Steve Oct 18 '21 at 15:30
  • Well I overrided the PaDataTimestampHandler to set the timestamp in case it is in the future (currently only for testing) The MIT Kerberos Windows client issue was resolved by updating KrbError for pre-auth to actually set the stime via Wireshark I noticed that Windows Server 2019 does the same, this should probably be implement in the trunk of the project Issues is that 0001-01-01 (C# mindate) does not work with the java implementation it only accepts 1970-01-01 and higher. Let me hear what you think? – Rune Jørgensen Oct 19 '21 at 08:13
  • I'm not following the wireshark change? I think the 0001/1970 min date issue is likely a red herring as the library shouldn't be doing any significant date math. As far as I can tell the client is still sending a literal value of `7/14/2042`, which is the root of the issue. – Steve Oct 19 '21 at 14:59
  • Yeah the wireshark problem is prolly a red herring agreed, for now I can circumvent it since im only working on a Proof-of-concept. the min date part is part of the KrbError the ones in KdcAsReqMessageHandler -> PreAuthFailed / RequirePreAuth they dont set stime (or call StampServerTime()) – Rune Jørgensen Oct 20 '21 at 06:05
  • I can certainly update it to return those values set, or as always PRs are welcome, but I don't think that's going to affect things. – Steve Oct 20 '21 at 15:29