Kerberos.NET
Kerberos.NET copied to clipboard
dotnet
When getting ticket from FreeIPA server, an extra "\" is being added to the username.
Describe the bug When I go to get a TGT from the FreeIPA Kerberos server, the Kerberos.NET client is adding a backslash to the username instead of sending it as described. Logs from the krb5kdc are below.
This first log is from when I use the MIT Kerberos for Windows client, it is successfully able to get a TGT.
Dec 04 17:04:59 idm1.cust.chs.devel krb5kdc[42139](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.0.10.252: NEEDED_PREAUTH: [email protected] for krbtgt/[email protected], Additional pre-authentication required
Dec 04 17:04:59 idm1.cust.chs.devel krb5kdc[42138](Error): PAD authorization data is requested but currently not supported.
Dec 04 17:04:59 idm1.cust.chs.devel krb5kdc[42138](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.0.10.252: ISSUE: authtime 1638655499, 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]
And this log is from when I attempt to get a TGT using Kerberos.NET. This always ends in the connection being aborted by the host machine.
Dec 04 17:05:13 idm1.cust.chs.devel krb5kdc[42139](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)}) 10.0.10.252: NEEDED_PREAUTH: admin\@[email protected] for krbtgt/[email protected], Additional pre-authentication required
Dec 04 17:05:13 idm1.cust.chs.devel krb5kdc[42139](info): closing down fd 12
To Reproduce You'll need to stand up a FreeIPA server, then attempt to get a ticket from it.
Expected behavior A TGT is requested and received by Kerberos.NET successfully.
Please let me know if you need any more information.
Thanks!
We don't ever include a backslash in the name. We try very hard not to muck with the values given to us and try to treat them verbatim. In some cases we've accidentally created weird name/othername/otherothername@domain errors, but that's really only in display cases and not on-the-wire cases. I'd guess what you're seeing is actually an artifact of the of FreeIPA logging. However, what does look weird is if you strip the slash you get [email protected]@CUST.CHS.DEVEL which seems wrong.
Can you share a bit of code to repro this? What value(s) are you passing to the client? FWIW I've run the library against FreeIPA in the past without issue, but I don't have a standing test harness for it so something may have regressed.
Also, ideally if you could capture a network trace of the working MIT AS-REQ and the failing Kerb.NET AS-REQ that would be greatly appreciated. That would be fairly definitive.
I'm attaching sample code, and a trace from the client-side and server-side, albeit taken at different times.
The odd part is, in the packets themselves, they look correct, at least to my admittedly untrained eye, it's only when the server parses them that we start to see the oddities above.
Files are zipped due to GitHub being an oddball. krb5.zip.zip
Also, only the client trace has the working MIT AS-REQ, but both have the failing Kerb.NET AS-REQ.
Ah, here's the most likely culprit. Kerberos.NET sends NT-ENTERPRISE-PRINCIPAL which approximately says "I have no idea what kind of name I'm sending you so...figure it out will ya?"
Whereas MIT sends NT-PRINCIPAL which approximately says "I know for a fact this is the name you must be looking for and I won't accept substitutes". Ish.
My guess is that FreeIPA isn't liking the former for whatever reason. It's possible it doesn't support it, but that's a bit surprising. Curiously this is the second time this exact issue has come up in the last week. I guess I need to make a knob for folks to fiddle with this.
In your sample you have code
string username = "[email protected]";
For completeness what happens if instead you set username = "user"; and then set the credential as new KerberosPasswordCredential(username, password, "example.com");. Alternatively leave the username alone but also explicitly pass the domain name to the credential?
For completeness what happens if instead you set username = "user"; and then set the credential as new KerberosPasswordCredential(username, password, "example.com");. Alternatively leave the username alone but also explicitly pass the domain name to the credential?
No dice either way.
My guess is that FreeIPA isn't liking the former for whatever reason. It's possible it doesn't support it, but that's a bit surprising.
Funnily enough, I'm actually a support engineer on the IPA team at Red Hat, so if this is actually a bug with FreeIPA, I can get a BZ opened and hopefully someone can figure it out. I'll also ask one of our backline folks in a bit, maybe they can shed some light into this behavior.
Oh, I see. :)
I think I need to add that knob anyway, but if you can [have someone] take a look at how the NT-ENTERPRISE-PRINCIPAL logic is handled then maybe we can figure out if it's supported and buggy, supported and working as expected and my implementation is wrong, or not supported and we just need to figure out a way to be smart about it in the library.
Incidentally I've been having a conversation with another person that ran into a rather similar issue. The PR #271 gives you at least an escape hatch to work around this if you want to try and verify a fix. Once it's merged in there'll be a new nuget package.
client.Configuration.Defaults.DefaultNameType = PrincipalNameType.NT_ENTERPRISE;
I'm going to add a bit more smarts to let the client figure this out on its own without requiring a caller to figure it out, but that'll be in another fix.
Sorry for the delay!
So, no dice. I don't have a packet capture on this computer, but I ran one on the other computer and it was still sending NT-ENTERPRISE-PRINCIPAL. I'll get a fresh capture uploaded here ASAP.
Hi @SteveSyfuhs, FreeIPA developer here. We didn't have proper enteprise principal support in KDB backend at that time (~2021). It should work now -- at least it works for me with kinit -E.
I think this bug can be closed.
