7

Is it possible to authenticate to SPNEGO/Kerberos server in domain A with an account from the same domain (obviously) when the client is connecting from computer in one of the following (quite similar) situations:

  • client is authenticated to domain B (different account, no trust between domains) or
  • user's computer is currently not authenticated against domain A (local login, e.g. when accessing intranet via VPN)

External SPNEGO/Kerberos authentication

Of course both these cases can not lead to integrated authentication (as the primary computer authentication is different from what needs to be used in Kerberos). However is it possible with Internet Explorer (or Firefox) to ask for credentials and use Kerberos?

When using Kerberos, a connection to KDC required (as far as I know). Is Windows or browser capable locating KDC for the server's SPN?

Pavel Horal
  • 171
  • 6
  • Just found quite similar question - http://serverfault.com/questions/594886/multiple-realms-and-multiple-tgts-under-mit-kerberos-for-windows – Pavel Horal Nov 11 '15 at 16:12

1 Answers1

2

Strictly speaking, both situations are not possible because they violate the trust semantics of Kerberos. By definition, the first scenario has a TGT into domain B and domain A doesn't trust it. Your second scenario is similar, except you may not even have a TGT because its local-only. (My statement assumes we are speaking about the use of Kerberos tickets as authentication and not a situation where you're passing plaintext credentials to a server to then present to the KDC for verification).

In both cases, the client application will not have a TGT or service ticket which is valid in domain A for the HTTP service to validate with the KDC.

That said, there is a way to do this in your second case ... but it assumes that you CAN login into domain A, even if not initially. This is done by running your client app (Firefox, IE, etc) with a RunAs that authenticates into a network account in domain A. See the /netonly flag of runas cmd (https://technet.microsoft.com/en-us/library/cc771525.aspx). This works by establishing another login context and runs the application as that context. Windows uses the application's user context to initialize its APIs when making Kerberos related calls and therefore will have a TGT into domain A to carry on its session.

Jeff Stice-Hall
  • 216
  • 1
  • 8
  • Thank you for the answer... My thoughts were that SSPI is something like let's say PAM. When the client (browser) asks to authenticate against specific SPN the TGT can be requested on the fly. But that is probably not the case. – Pavel Horal Nov 11 '15 at 15:35
  • Microsoft has gone to great lengths to hide this from the end-user. SSPI is designed to pull from current NT user session with as little user interaction as possible. That's part of the equation ... the other part is the design choice within Windows that a machine may only participate in a single Active Directory membership at one time. If KDC A trusts KDC B, this issue is bridged. But if no trust exists, you're left in the dark unless you change the machine membership to domain B. – Jeff Stice-Hall Nov 11 '15 at 15:39