Question about using NegotiateStream in linux and TokenImpersonationLevel

[deryaza]

Is the check in this line still valid? I don't know about impersonation, but delegation should work, and it works for us via gssapi (linux client -> windows server scenario).

https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Security/src/System/Net/Security/NegotiateStreamPal.Unix.cs#L36

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is the check in this line still valid? I don't know about impersonation, but delegation should work, and it works for us via gssapi (linux client -> windows server scenario).

https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Security/src/System/Net/Security/NegotiateStreamPal.Unix.cs#L36

Author:	deryaza
Assignees:	-
Labels:	area-System.Net.Security
Milestone:	-

[wfurt]

It may be possible. It is there probably since the initial Linux port. I'm looking at #28460 at the moment and I was planning to do more testing with Linux.

The difficult part may be testing. We have some tests with Linux KDC but I'm not sure if/how we would construct test automation. If you can share some details @deryaza it would be useful.

[deryaza]

I just want to clarify that my "is it still valid" (or is it actually not supported) question was because some time ago, when I investigated the possibility, I used System.Net.Security code as a reference to get an idea of the native functions that could be called. After that and with some tries, I was able to get the user token and impersonate the user on the server.

So that just me being curious :) Is there some concerns why NegotiateStream or the new api (that calls the same function, iirc) are limited to identification? I alse remembered seeing some flags mappings that mention delegation.

Actually, after posting this, I tried to build from source and extend the check to delegation and it worked. I even got WindowsIdentity as an Identity property of NegotiateStream.

So yeah, I'm just asking why validation is still like this (I could guess that it's because lack of testing?).

[wfurt]

I think it is lack of demand (you are really first one IMHO) and lack of testing infrastructure. I think we would be happy to take community PR.
cc: @filipnavara

[filipnavara]

There's definitely a lack of testing for this but the underlying code for Unix (Linux/macOS) seems to be there.

[ryannewington]

Just adding another voice to this ask

The restriction to identification in this file

https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Security/src/System/Net/Security/NegotiateStreamPal.Unix.cs#L36

prevents the use of impersonation on linux systems.

internal static void ValidateImpersonationLevel(TokenImpersonationLevel impersonationLevel)
{
    if (impersonationLevel != TokenImpersonationLevel.Identification)
    {
        throw new ArgumentOutOfRangeException(nameof(impersonationLevel), impersonationLevel.ToString(),
            SR.net_auth_supported_impl_levels);
    }
}

This is blocking us from being able to support linux clients talking to Windows servers and using Kerberos authentication where impersonation is required. As this library is widely used, it also impacts other services like WCP's net.tcp stream.

By contrast, NegotiateStreamPal.Windows.cs contains

internal static void ValidateImpersonationLevel(TokenImpersonationLevel impersonationLevel)
{
    if (impersonationLevel != TokenImpersonationLevel.Identification &&
        impersonationLevel != TokenImpersonationLevel.Impersonation &&
        impersonationLevel != TokenImpersonationLevel.Delegation)
    {
        throw new ArgumentOutOfRangeException(nameof(impersonationLevel), impersonationLevel.ToString(), SR.net_auth_supported_impl_levels);
    }
}

Another side note is that currently the error message returned by the Unix PAL incorrectly reports the following message in it's exception text

The supported values are Identification, Impersonation or Delegation.

The message is incorrect, as currently only Identification is allowed.

I'm certainly happy to contribute to resolving this issue, if there is a way forward here.

[wfurt]

yes, we would take contributions @ryannewington. As I mentioned above lack of testing and low priority is probably main reason for the gap.

You can look at https://github.com/dotnet/runtime/tree/main/src/libraries/Common/tests/System/Net/EnterpriseTests/setup to see if we can somehow integrate it with current Docker tests.

We would only add Delegation, right? e.g. no Impersonation on Unix?

[ryannewington]

Ok! Great! So there's a few dimensions to this to consider

Linux client to Windows Server

First, let's talk about the linux client to windows server scenario. This is going to be the most common use case.

The client sets the TokenImpersonationLevel on the token it sends to the server, which specifies how the windows server can use the token. The action itself isn't performed client side, it's a flag to say what the server is permitted to do with it's identity. Eg 'you can identify me (Identification)', 'you can impersonate me locally (Impersonation)' or 'you can impersonate me on other servers (Delegation)'.

This scenario is broken in my case, because i can't give permission for the Windows server to impersonate me with the access token I provide when coming from Linux.

I think in the client scenario, there's no consequence to having the same checks as Windows, that is, allow the client to use any of the TokenImpersonationLevels supported by NegotiateStream, as windows does.

For testing, this would be as simple as pointing the linux NegotiateStream client at the same Server as the Windows NegotiateClient, and validating that the server receives the correct impersonation level as specified client side.

(FWIW I've patched NegotiateStream and confirmed it does work as expected from Linux)

Windows or Linux Client to Linux server scenario

This one has a little more nuance to it.

When i set the TokenImpersonationLevel on a server, I'm saying 'the client must present me with this minimum impersonation level'. Impersonation levels are cumulative, in that an Impersonation token allows for both Identification and 'impersonation on the local system'. Delegation allows for Identification, and local Impersonation.

While impersonation may not apply to a linux system, delegation technically can, and delegation (with impersonation levels being cumulative), includes the right of impersonation.

If I set my Linux server-side 'minimum impersonation level' to Identification, I can still be sent an Impersonation token by the client.

Since the token I receive is really dependent on the client at the end of the day, perhaps it's best left to the developer to work out what they want to support? There doesn't seem to be much to gain from restricting the token types you can receive on the Linux side. And given that dotnet provides no mechanism to impersonate an identity on Linux, having an impersonation token in your possession doesn't appear to be too great of a problem.

I think it's also fair to say that if a developer wanted to use the delegation token, they'd have some work to do. This is also normally handled on Windows by the WindowsIdentity class's impersonation function. However, it doesn't rule out the possibility of doing it, perhaps with using something like Kerberos.NET.

That all being said, I think the likelihood of someone wanting to run a NegotiateStream server on Linux is low.

Options for a way forward

1. Modify the ValidateImpersonationLevel function in the Unix PAL to match windows (or move it back into the shared PAL). This would allow NegotiateStream clients on any OS to correctly specify their impersonation level. It would also allow NegotiateStream servers on any platform to request client impersonation levels of any type, but the onus would be on the developer as to what they would do with that. Since NegotiateStream is a low level construct, and doesn't actually use the impersonation token itself in any way, the behavior can be left implementation-specific?

2. Add an isServer parameter to the ValidateImpersonationLevel function, ignored in the Windows PAL, but used in the Unix PAL to enable the additional levels when working as a client, but leave servers set to Identification only as they are today.

Test updates

I've had a look at the existing test cases, and there doesn't appear to be any Impersonation or Delegation token level tests at all, even for Windows, but I might just not be seeing them?

Would we be looking at adding additional test cases validating the expected impersonation levels to:
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Security/tests/FunctionalTests/NegotiateStreamStreamToStreamTest.cs

or adding additional tests here?
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Security/tests/EnterpriseTests/NegotiateStreamLoopbackTest.cs

I guess it depends if need to validate that a) The TokenImpersonationLevel is correctly negotiated between both ends. This can be done with a StreamToStream test. Or b) we actually want to try to impersonate/delegate the resulting access token? But it doesn't look like the tests go as far as this today (and seems out of scope for the NegotiateStream's capabilities anyway) .

[wfurt]

To the Linux client. While I agree in principal this is server's job there may be practical limits.
https://datatracker.ietf.org/doc/rfc5896/ talks about OK_AS_DELEGATE but I did not see anything about impersonation. (may be just hidden somewhere else) We will need to pass the given desire to GSSAPI and that may be limiting factor.

The functional tests you linked have only NTLM tests. To run Kerberos, you obviously need KDC. That was done as manual tests in the past and the EnterpriseTests is attempt to build on ad-hoc in container. And yes, there are currently no test for this.

Windows is even more complicated. AFAIK you cannot run DC in container and our automated test infrastructure does not have capability to proved test server. That really leaves only ad hoc manual tests in place.

@filipnavara did great job in 7.0 to pull in Kerberos.Net so we can do more detailed tests. But that still does not have coverage in this are.