Closed vijaykota closed 6 months ago
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.
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:
kinit -S $user $user
foo@DOMAIN.CORP.MICROSOFT.COM's Password:
kinit: krb5_get_init_creds: Server (foo@DOMAIN.CORP.MICROSOFT.COM) unknown
On a Windows server I see failure like:
e:\>klist get %user%
Current LogonId is 0:0x28e0ff
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x52e
klist failed with 0xc0000408/-1073740792: Kerberos sub-protocol User2User is required.
But Windows NegotiateStream is able to successfully get a ticket.
Looks like this requires User2User protocol support. We need to figure out if the MIT Kerberos implementation has this support
The scenario seems to be rather corner-case. @zhenlan @mconnew is it something you guys use in WCF?
User2User protocol support is unlikely to be needed in cloud scenarios.
User-to-user authentication is a special Kerberos application protocol, that allows users to host secure application services on their desktop machines. It is increasingly common for users to offer desktop services that merit secure authentication, such as nfs and ftp. When users configure their desktop servers with a long-lived srvtab key, this long-lived key becomes a very attractive target for theft. User-to-user authentication enables a user to run a server without keeping a long-lived key on disk. Instead, the user's short-lived TGS session-key takes the place of the usual srvtab secret key, in the server's authentication handshakes.
Closing this for now until we get more customer feedback.
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.
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.
.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?
@davidsh, that is exactly the case. Linux client connecting to a Windows WCF service.
Do you feel this is still important @mconnew ? It is pretty old issue and we would probably need more specific repro if we want to approach it.
This issue has been marked needs-author-action
and may be missing some important information.
@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.
This issue has been automatically marked no-recent-activity
because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity
.
This issue will now be closed since it had been marked no-recent-activity
but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.
This issue has been automatically marked no-recent-activity
because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity
.
This issue will now be closed since it had been marked no-recent-activity
but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.
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, thegss_import_name
needs to be called with some OID other thanGSS_KRB5_NT_PRINCIPAL_NAME