Failing to authenticate when used against MIT Kerberos Server #323

macsux · 2022-10-25T17:17:10Z

Describe the bug
The library seems to be failing when trying to talk to MIT Kerberos Server. I've setup a test MIT Kerberos Server, create a principal and trying to use Kerberos.NET to try to obtain TGT. This is failing with

System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at Kerberos.NET.Transport.Tcp.ReadFromStream(Memory`1 readResponse, NetworkStream stream, CancellationToken cancellation, TimeSpan readTimeout) in D:\a\1\s\Kerberos.NET\Transport\Tcp.cs:line 57
   at Kerberos.NET.Transport.TcpKerberosTransport.ReadResponse[T](NetworkStream stream, CancellationToken cancellation, TimeSpan readTimeout) in D:\a\1\s\Kerberos.NET\Client\Transport\TcpKerberosTransport.cs:line 129
   at Kerberos.NET.Transport.TcpKerberosTransport.SendMessage[T](String domain, ReadOnlyMemory`1 encoded, CancellationToken cancellation)
   at Kerberos.NET.Transport.KerberosTransportSelector.SendMessage[T](String domain, ReadOnlyMemory`1 encoded, CancellationToken cancellation)
   at Kerberos.NET.Client.KerberosClient.RequestTgt(KerberosCredential credential) in D:\a\1\s\Kerberos.NET\Client\KerberosClient.cs:line 1205
   at Kerberos.NET.Client.KerberosClient.AuthenticateCredential(KerberosCredential credential) in D:\a\1\s\Kerberos.NET\Client\KerberosClient.cs:line 374
   at Kerberos.NET.Client.KerberosClient.Authenticate(KerberosCredential credential) in D:\a\1\s\Kerberos.NET\Client\KerberosClient.cs:line 357
   at UserQuery.Main() in C:\Users\astakhov\AppData\Local\Temp\LINQPad7\_mkttxexs\eshxoi\LINQPadQuery:line 15

I am able to authenticate with kinit without issues

To Reproduce

Create a docker-compose file like this

version: '3.0'
services:
  demo:
    image: gcavalcante8808/krb5-server
    ports:
      - '88:88'
      - '749:749'
      - '464:464'
      - '888:888'
    environment:
      KRB5_REALM: MACSUX.DC
      KRB5_KDC: localhost
      KRB5_PASS: password

Launch the server from shell via docker-compose up command
Add user to the kerberos server by executing the following command (adjust container name if necessary)
docker exec krb-test-server-demo-1 /bin/sh -c "echo password | kadmin -r MACSUX.DC -p admin/[email protected] -q 'addprinc -pw password [email protected]'"
Try to authenticate to this server via a program like this:

var realm = "MACSUX.DC";
var config = Krb5Config.Default();
config.Realms[realm].Kdc.Add("localhost");
config.Realms[realm].DefaultDomain = realm.ToLower();
config.DomainRealm.Add(realm.ToLower(), realm.ToUpper());
config.DomainRealm.Add($".{realm.ToLower()}", realm.ToUpper());
var client = new KerberosClient(config);
var credentials = new Kerberos.NET.Credentials.KerberosPasswordCredential("iwasvc", "password", "macsux.dc");
await client.Authenticate(credentials);

Linqpad snippet: http://share.linqpad.net/stcnk6.linq

Expected behavior
Authentication successful

Screenshots

Additional context
Tested on Windows with server running in docker. kinit test was performed from WSL and was successful.

The text was updated successfully, but these errors were encountered:

SteveSyfuhs · 2022-10-25T17:58:49Z

Are there any logs from MIT about the request? Can you enable verbose/debug logging?

The error itself is that the client timed out waiting for the KDC to send it a response. The protocol is a length/value pair, so the way the code works is that it reads the length and queries the socket until it can get that length of bytes, OR until the socket is closed intentionally (FIN/RST), OR until the cancellation has triggered from timeout. It's only hitting the last case, which would be a weird behavior on the MIT side of things to let the socket linger open if the client sent a bad request.

Can you capture a wireshark trace of a working/failing attempt?

macsux · 2022-10-25T18:26:36Z

Ok, some clues...

Oct 25 18:23:56 7ce22535e0f1 krb5kdc[20](info): closing down fd 15
Oct 25 18:24:27 7ce22535e0f1 krb5kdc[20](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 127.0.0.1: SERVER_NOT_FOUND: admin/[email protected] for kadmin/[email protected], Server not found in Kerberos database
Oct 25 18:24:27 7ce22535e0f1 krb5kdc[20](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 127.0.0.1: NEEDED_PREAUTH: admin/[email protected] for kadmin/[email protected], Additional pre-authentication required
Oct 25 18:24:27 7ce22535e0f1 krb5kdc[20](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 127.0.0.1: ISSUE: authtime 1666722267, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, admin/[email protected] for kadmin/[email protected]
Oct 25 18:24:59 7ce22535e0f1 krb5kdc[20](info): AS_REQ (4 etypes {aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha384-192(20), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 172.25.0.1: CLIENT_NOT_FOUND: iwasvc\@[email protected] for krbtgt/[email protected], Client not found in Kerberos database
Oct 25 18:24:59 7ce22535e0f1 krb5kdc[20](info): closing down fd 15

macsux · 2022-10-25T18:28:12Z

This is what the log output looks like when I do same thing successfully via kinit [email protected]

Oct 25 18:27:00 7ce22535e0f1 krb5kdc[20](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.25.0.1: NEEDED_PREAUTH: [email protected] for krbtgt/[email protected], Additional pre-authentication required
Oct 25 18:27:00 7ce22535e0f1 krb5kdc[20](info): closing down fd 15
Oct 25 18:27:03 7ce22535e0f1 krb5kdc[20](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.25.0.1: ISSUE: authtime 1666722423, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, [email protected] for krbtgt/[email protected]
Oct 25 18:27:03 7ce22535e0f1 krb5kdc[20](info): closing down fd 15

SteveSyfuhs · 2022-10-25T19:02:54Z

The name formatted in the log looks a bit fishy. Can you try setting the DefaultNameType to something like PrincipalNameType.NT_ENTERPRISE

client.Configuration.Defaults.DefaultNameType = PrincipalNameType.NT_ENTERPRISE

SteveSyfuhs · 2022-10-25T19:05:29Z

CORRECTION: NT_PRINCIPAL

…

________________________________ From: Andrew Stakhov ***@***.***> Sent: Tuesday, October 25, 2022 11:28:23 AM To: dotnet/Kerberos.NET ***@***.***> Cc: Steve Syfuhs ***@***.***>; Comment ***@***.***> Subject: Re: [dotnet/Kerberos.NET] Failing to authenticate when used against MIT Kerberos Server (Issue #323) This is what the log output looks like when I do same thing successfully via kinit ***@***.*** Oct 25 18:27:00 7ce22535e0f1 krb5kdc[20](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.25.0.1: NEEDED_PREAUTH: ***@***.*** for ***@***.***, Additional pre-authentication required Oct 25 18:27:00 7ce22535e0f1 krb5kdc[20](info): closing down fd 15 Oct 25 18:27:03 7ce22535e0f1 krb5kdc[20](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 172.25.0.1: ISSUE: authtime 1666722423, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, ***@***.*** for ***@***.*** Oct 25 18:27:03 7ce22535e0f1 krb5kdc[20](info): closing down fd 15 — Reply to this email directly, view it on GitHub<#323 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJHTYKGFALFUT23RXW7CELWFAREPANCNFSM6AAAAAAROF3UUE>. You are receiving this because you commented.Message ID: ***@***.***>

macsux · 2022-10-25T19:12:22Z

Doesn't seem to affect anything - it still formats the requested principal as iwasvc\@[email protected]

SteveSyfuhs · 2022-10-25T20:15:30Z

So it looks like it's the same issue as this: #270

I'd guess there's a bug somewhere along the way that's rewriting the name type back to NT_ENTERPRISE.

SteveSyfuhs · 2022-10-25T20:16:56Z

Grr, hit submit too early.

Can you try setting the PrincipalNameType on the credential itself?

var credentials = new Kerberos.NET.Credentials.KerberosPasswordCredential("iwasvc", "password", "macsux.dc") { PrincipalNameType = PrincipalNameType.NT_PRINCIPAL };

SteveSyfuhs · 2022-10-25T20:23:46Z

Also, interestingly we must have hit this basic issue in the past because we already have a way to handle this automatically. Hmm.

Kerberos.NET/Kerberos.NET/Client/KerberosClient.cs

Lines 407 to 412 in df33af4

    
           if (pex?.Error?.ErrorCode == KerberosErrorCode.KDC_ERR_C_PRINCIPAL_UNKNOWN && 
        
               credential.PrincipalNameType == PrincipalNameType.NT_ENTERPRISE) 
        
           { 
        
               credential.PrincipalNameType = PrincipalNameType.NT_PRINCIPAL; 
        
               continue; 
        
           }

macsux · 2022-10-25T20:38:08Z

Tried it by configuring on credential level - same thing.

macsux · 2022-10-26T16:12:53Z

Any other suggestions to try, or this will require a code fix in lib?

JanMaier97 · 2024-07-03T18:14:55Z

Hello, I have a similar setup and the same issue. I am running the kerberos server in a local docker container and I want to authenticate against it using Kerberos.NET running in the windows host. From a second docker container I am able to authenticate against the server with kinit.
I used tcpdump to trace the packages received by the server. I compared kinit request with the Kerberos.NET request. I found that the request differ in their cname value. The Kerberos.NET request is sending "[email protected]" while kinit is only sending "bob".
I debugged the authentication method and edited the cname value, before it is sent. The request is still running into TaskCanceledExceptions. However, when executed multiple times in a loop, it works eventually.

Here are the network traces if any one would like to check them:
kerberos_traces.zip

Could this be the root cause for this issue? Or should the server usually be able to handle the Kerberos.NET request properly?

SteveSyfuhs · 2024-07-03T18:46:53Z

The CName field is a function of the credential you're using:

Kerberos.NET/Kerberos.NET/Entities/Krb/KrbAsReq.cs

Lines 135 to 149 in 6828266

    
           private static KrbPrincipalName ExtractCName(KerberosCredential credential) 
        
           { 
        
               var principalName = KrbPrincipalName.FromString(credential.UserName); 
        
               if (principalName.IsServiceName) 
        
               { 
        
                   return principalName; 
        
               } 
        
               return KrbPrincipalName.FromString( 
        
                   credential.UserName, 
        
                   credential.PrincipalNameType, 
        
                   credential.Domain 
        
               ); 
        
           }

And the logic for that is somewhat complicated, but can be forced by setting the name type explicitly:

https://github.com/dotnet/Kerberos.NET/blob/develop/Kerberos.NET/Entities/Krb/KrbPrincipalName.cs#L232-L259

If the issue is that the client only works when you're sending just the short name instead of a UPN, this can be handled by setting the credential username to that.

macsux · 2024-07-04T12:54:54Z

Given that MIT Kerberos is defacto library on Linux side (and one .net core is hardcoded relies on to do IWA on linux), perhaps it makes sense to add some kind of "compatibility" enum where all these minor variances between implementations are automatically accounted for. Consumers of this lib usually don't have in-depth knowledge of these minute differences.

JanMaier97 · 2024-07-10T18:37:45Z

I tried various combinations of username + domain + PrincipalNameType, however, I am unable to force just the short name and the udp name is always sent. So code like this would also have [email protected] as the cname in the AS_REQ request:

var kerbCred = new KerberosPasswordCredential("bob, "***", "EXAMPLE.COM");
kerbCred.PrincipalNameType = PrincipalNameType.NT_PRINCIPAL;
await client.Authenticate(kerbCred);

During debugging I found that SplitAsUpn always combines the username with @<realm-name>, if the username does not already contains an @ character.

Kerberos.NET/Kerberos.NET/Entities/Krb/KrbPrincipalName.cs

Lines 339 to 362 in 89ae633

    
           private static KrbPrincipalName SplitAsUpn(string principal, string realm, PrincipalNameType type) 
        
           { 
        
               var nameSplit = principal.Split('@').ToList(); 
        
               if (!string.IsNullOrWhiteSpace(realm) && nameSplit.Count == 1) 
        
               { 
        
                   nameSplit.Add(realm); 
        
               } 
        
               if (type == PrincipalNameType.NT_SRV_INST) 
        
               { 
        
                   return new KrbPrincipalName 
        
                   { 
        
                       Type = type, 
        
                       Name = nameSplit.ToArray() 
        
                   }; 
        
               } 
        
               return new KrbPrincipalName 
        
               { 
        
                   Type = type, 
        
                   Name = new[] { MakeFullName(nameSplit, PrincipalNameType.NT_PRINCIPAL) } 
        
               }; 
        
           }

I looked for information about the kerberos protocol and as far as I can understand, the cname is usually just the username and not the full udp. Could this be the cause of the bug we are encountering here?

Otherwise, are there any other client and credential options that I may have missed to set the username correctly?

A6blpka · 2024-11-13T12:50:03Z

I tried various combinations of username + domain + PrincipalNameType, however, I am unable to force just the short name and the udp name is always sent.

I tried changing the library source code to send the short name to cname for kRB5-NT-PRINCIPAL, but that did nothing. I checked the sent request via wireshark.

Maybe that's not the problem.

macsux added the bug label Oct 25, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Failing to authenticate when used against MIT Kerberos Server #323

Failing to authenticate when used against MIT Kerberos Server #323

macsux commented Oct 25, 2022 •

edited

Loading

SteveSyfuhs commented Oct 25, 2022

macsux commented Oct 25, 2022

macsux commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022 via email

macsux commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022

macsux commented Oct 25, 2022

macsux commented Oct 26, 2022

JanMaier97 commented Jul 3, 2024

SteveSyfuhs commented Jul 3, 2024

macsux commented Jul 4, 2024

JanMaier97 commented Jul 10, 2024

A6blpka commented Nov 13, 2024

Failing to authenticate when used against MIT Kerberos Server #323

Failing to authenticate when used against MIT Kerberos Server #323

Comments

macsux commented Oct 25, 2022 • edited Loading

SteveSyfuhs commented Oct 25, 2022

macsux commented Oct 25, 2022

macsux commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022 via email

macsux commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022

SteveSyfuhs commented Oct 25, 2022

macsux commented Oct 25, 2022

macsux commented Oct 26, 2022

JanMaier97 commented Jul 3, 2024

SteveSyfuhs commented Jul 3, 2024

macsux commented Jul 4, 2024

JanMaier97 commented Jul 10, 2024

A6blpka commented Nov 13, 2024

macsux commented Oct 25, 2022 •

edited

Loading