0

I have a security problem. I don’t know if it is WinHttp or if it is Kerberos or Windows Security.

We have a desktop version of our application and web version that runs as a service. They share many, many DLLs where much of the functionality lies. Both versions of these applications have to connect sometimes to a third server (Hadoop) which is configured to use kerberos for authentication using a Windows server as the domain controller--using Active Directory.

We use WinHttp to connect to the Hadoop server in both the desktop version and the Web version. On the desktop version, we use WinHttpSetOption with the WINHTTP_AUTO_LOGON option set to WINHTTP_AUTOLOGON_SECURITY_LEVEL_LOW.

For the desktop version, everything works fine. However, for the web version, it does not work. For the web version, after they login, we have Token for the login. Before we use use WInHttp to talk to the Hadoop server, we call SetThreadToken() with the login token to impersonate the login user. Calling functions that get what the system thinks the user is returns the login user and not the service user. When we use WinHttp to make the request, it fails with an error 403 with some text returned:

org.apache.hadoop.security.authentication.client.AuthenticationException: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

So, it doesn’t like my token. But, the token is good...at least on the machine the user is running on. These are from tests on a customer machine. They have 3 machines I need to worry about. #1) Windows server with desktop and server applications #2) Hadoop server #3) Windows Server that is domain controller / Active Directory server

For more info, typically the user logins to the server application through a browser using automatic windows integrated authentication.

For the desktop, the user runs the application on the remote machine through RDP.

In our local (well, cloud) test bed, everything works ok. Both the desktop and server application authenticate correctly to Hadoop. but the configuration is different than what the customer has. Our test config has 2 computers #1) Windows server with desktop and server application which is also the domain controller / Active directory server, #2) Hadoop server

I currently don’t have the resources to try and duplicate the customer config or else I would.

And to reiterate, the desktop application authenticates correctly to Hadoop, but the server version (after doing impersonation with SetThreadToken() with the login token) does not authenticate correctly with Hadoop.

Is the token used in impersonation less trusted than the session that runs on the desktop?

What can I try? What maybe am I not understanding?

Joseph Willcoxson
  • 5,853
  • 1
  • 15
  • 29
  • Since you're doing WIA to the web, and within that context trying to auth to Hadoop, you're likely involving kerberos delegation. The account of the web service should be configured to allow delegation to hadoop. – Steve May 17 '19 at 17:29
  • @Steve Could I have a few more details? Is that something I need to configure on the Windows server box, or specially configure the windows server application, or something to configure on the Hadoop box/server? – Joseph Willcoxson May 17 '19 at 17:36
  • 1
    This is something you configure in AD. It looks like the desktop app can just get a ticket to hadoop because you're running as the user. The web service is running as it's own service, impersonating the logged in user. That impersonation introduces a delegation hop. You need to configure AD to let the web service delegate to hadoop on behalf of the user. see https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview – Steve May 17 '19 at 18:48
  • Ok, thanks. I will investigate it further. – Joseph Willcoxson May 17 '19 at 19:22

0 Answers0