[Usage Question] impersonation for kerberos authenticated users

[giuliohome]

Only a support/help question.
Let say I have a user authenticated via kerberos SSO.
Now my node backend is running under system user and it has no access to a certain network folder.
The authenticated user instead has access to such network folder, so I want to impersonate the user; question: how to do that?
Should I use the access token from sso? I can't find an example, a tutorial or more instructions.
I've tried to look at the source code here.
The point is that I see that SSO.ts is doing sspi.ImpersonateSecurityContext(this.serverContextHandle); but to do that it is using a serverContextHandle that is kept private(*)! I would be tempted to fork and modify the code at that point (here, conceptually, I should be able to open the shared folder as the impersonated user, correct?), but it seems complex and before doing that, I would rather gather a better overall understanding. Also because I see also sspi.OpenThreadToken() immediately after the impersonation: is that needed for the impersonation (maybe not, I guess the user is already impersonated here, correct?) or just to save the access token? I guess it is for the latter goal, but, again, as I said before, I miss the usage of this access token.

(*) Well, it is passed via contructor from the auth.ts that in turn is gathering the serverSecurityContext.contextHandle, basically from sspi.AcceptSecurityContext(input) where the input is more or less the Kerberos authorization token... ok, but I believe I'm not supposed to repeat all that procedure (starting from Kerberos token and passing it to AcceptSecurityContext) again in my usage code: that would mean that saving the access token is useless, so I'm not considering this option.

[giuliohome]

I think I have to call ImpersonateLoggedOnUser with the with sso.user.accessToken in input.

Will try (if I find an example for node.js: this package export appears to be a good fit, I'm going to install it) and close the issue, if it works.
Thanks

[giuliohome]

I'm getting

0|node.js express sso  | TypeError: 'handle' should be an External returned from logonUser()
0|node.js express sso  |     at F:\Apps\ng\angular-sso-example\back\src\server.ts:62:3

for this code

const { impersonateLoggedOnUser,  revertToSelf} = require('F:\\Apps\\ng\\angular-sso-example\\back\\build\\Release\\users.node');
const accessToken = req?.session?.sso?.user?.accessToken;
impersonateLoggedOnUser(accessToken);

[giuliohome]

The two libraries have different ways to treat the handles.
I think I have to deserialize the handle from this utility in such a way that is expected from here...

edit

Ehm.... this is what you use to retrieve a HANDLE from a string, I'll try to modify the other lib users.cc accordingly...

[giuliohome]

Now the access token is correctly transformed into a napi value and viceversa (code below), but still ImpersonateLoggedOnUser throws invalid handle.

std::string p2s(void *ptr) {
  std::stringstream s;
  s << "0x" << std::setfill('0') << std::setw(sizeof(ULONG_PTR) * 2) << std::hex
     << ptr;
  std::string result = s.str();
  return result;
}

Value impersonateLoggedOnUser(CallbackInfo const& info) {
    auto env = info.Env();
	// return info[0];
	
	HANDLE token =
		s2p(info[0].As<Napi::String>().Utf8Value());
	
	Value ret_handle = External<void>::New(env, token, [](Env env, HANDLE handle) {
			CloseHandle(handle);
		});
	
	auto handle = get_handle(env, 
		ret_handle
	);
	
    if (!ImpersonateLoggedOnUser(handle)) {
		throw createWindowsError(env, GetLastError(), "ImpersonateLoggedOnUser");
    }
	
	//std::string str = p2s(handle);
	//return Napi::String::New(env, str);
	return ret_handle;
}

[giuliohome]

I have recompiled the library to have access to the private server context handle.
So now I can run again all the sequence

        const getServerHandle = (req : any) => req?.session?.sso?.serverContextHandle
        const input = getServerHandle(req);
	sspi.ImpersonateSecurityContext(input);
	const new_access_token = sspi.OpenThreadToken();
	impersonateLoggedOnUser(new_access_token);

and in this case I'm getting a different error: 'Access is denied.'

asked on SO, but it has been closed.

In conclusion, the results of my tests of reusing serverContextHandle and OpenThreadToken are

1. impersonateLoggedOnUser : 'Access is denied.'
2. sqlite connection: 'SQLITE_CANTOPEN: unable to open database file'
3. ms sql with windows auth: "[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user 'domain\owner'."

[giuliohome]

Unfortunately also MS SQL windows authentication fails because it sees the process owner user and not the impersonated SSPI token.
Sharing this last commit for future reference and review.

[giuliohome]

I doubt that other debug details are needed. All this boils down to saying that Kerberos ticket is only valid to authenticate Alice to Bob but can't be used for Bob to impersonate Alice (typically for windows authentication on ms sql server). I only see 2 possible answers: either 1) yes, it's by design (hopefully that is true IMO) or 2) no, one could be able to use Kerberos ticket to impersonateLoggedOnUser or to connect via windows auth to a SQL Server and the like... In either case it can be answered, in principle, without further details about my debug environment. My conclusion written here.