Repository navigation
Kerberos ticket is not fetched when target is a user #16576
Description
The xplat NegotiateStream implementation is able to successfully use Kerberos auth when the target of AuthenticateAsClientAsync is a service principal eg. HOST/machine, HTTP@machine etc. However, if the target is a user like foo@domainfqdn, the auth is failing. Perhaps in this case, the gss_import_name needs to be called with some OID other than GSS_KRB5_NT_PRINCIPAL_NAME
Activity
iamjasonp commentedon Mar 3, 2016
Awesome, thanks @vijaykota.
Should we also be considering whether or not to translate the domain part of the UPN into uppercase as well? In our testing, we have found that the UPN must be in uppercase for the scenario to work.
Not sure if that would be a safe operation though.
vijaykota commentedon Mar 3, 2016
Translation of domain would not be safe since the Linux default is to be case-sensitive.
This seems like a complex issue to solve on Linux:
On a Windows server I see failure like:
But Windows NegotiateStream is able to successfully get a ticket.
vijaykota commentedon Mar 3, 2016
Looks like this requires User2User protocol support. We need to figure out if the MIT Kerberos implementation has this support
karelz commentedon Feb 2, 2017
The scenario seems to be rather corner-case.
@zhenlan @mconnew is it something you guys use in WCF?
davidsh commentedon Mar 15, 2019
User2User protocol support is unlikely to be needed in cloud scenarios.
Closing this for now until we get more customer feedback.
mconnew commentedon Mar 18, 2019
I just saw this issue. This is a scenario that WCF uses quite extensively and is NOT a corner case for us. If you run a server as non-system (ie self-hosted), then you must use a non-default service identity. As configurating a custom SPN requires additional domain permissions and isn't very friendly for quickly setting something up, most users will use a UPN instead.
Edit:
This issue is also related to issue dotnet/corefx#27745. Once WCF is able to set a custom SPN, we will be able to be a client to console hosted WCF servers using Windows auth. This is a broken scenario for us right now and have been waiting several years for this support. Once issue dotnet/corefx#27745 has be completed, this issue will affect HTTP Negotiate authentication too.
davidsh commentedon Mar 18, 2019
.NET Core doesn't support NegotiateStream as a server on Linux. So, are you referring to a scenario where NegotiateStream (acting as a server) is being used on a Windows machine? And your requirement is that Linux clients be able to connect to it?
mconnew commentedon Mar 18, 2019
@davidsh, that is exactly the case. Linux client connecting to a Windows WCF service.
Enterprise Testing System
Enterprise Testing System (#463)
6 remaining items
mconnew commentedon Nov 16, 2023
@wfurt, yes it is still important. I should be able to create a solution using CoreWCF and WCF Client relatively easily, along with a WCF equivalent on .NET Framework. Super backed up with tasks right now though. Ping me a couple of weeks before you want to start work on this and I will put something together for you.