README misleading about how Negotiate works

[slominskir]

The README says:

mod_auth_gssapi/README

Lines 77 to 87 in 796000a

	### gssapi-no-negotiate
	This environment variable is used to suppress setting Negotiate headers. Not
	sending these headers is useful to work around browsers that do not handle
	them properly (and incorrectly show authentication popups to users).
	#### Example
	For instance, to suppress negotiation on Windows browsers, one could set:
	BrowserMatch Windows gssapi-no-negotiate

The example effectively disables mod_auth_gssapi for Windows clients, which turns out to often be a reasonable thing to do, but isn't explained and instead suggests that the Windows browsers don't work properly, when in fact, they're dutifully working as originally designed (by Microsoft).

The www-authenticate: Negotiate behavior is hinted at here, but also not explained particularly well:

mod_auth_gssapi/README

Lines 405 to 427 in 796000a

	### GssapiNegotiateOnce
	When this option is enabled the Negotiate header will not be resent if
	Negotiation has already been attempted but failed.
	Normally when a client fails to use Negotiate authentication, a HTTP 401
	response is returned with a WWW-Authenticate: Negotiate header, implying that
	the client can retry to use Negotiate with different credentials or a
	different mechanism.
	Consider enabling GssapiNegotiateOnce when only one single sign on mechanism
	is allowed, or when GssapiBasicAuth is enabled.
	**NOTE:** if the initial Negotiate attempt fails, some browsers will fallback
	to other Negotiate mechanisms, prompting the user for login credentials and
	reattempting negotiation. This situation can mislead users - for example if
	krb5 authentication failed and no other mechanisms are allowed, a user could
	be prompted for login information even though any login information provided
	cannot succeed. When this occurs, some browsers will not fall back to a Basic
	Auth mechanism. Enable GssapiNegotiateOnce to avoid this situation.
	- **Enable with:** GssapiNegotiateOnce On
	- **Default:** GssapiNegotiateOnce Off

The missing information is troubling because a substantial number of browsers (Windows browsers such as Edge and Chrome) are affected by this behavior and it is a detail that should be front and center before someone invests time into setting up mod_auth_gssapi.

My understanding is this module supports Microsoft's IANA registered Negotiate auth scheme, which turns out to be very problematic. It is defined in RFC4559, and relies on RFC2478. The Negotiate scheme is designed to first try Kerberos and then fall back onto NTLM unless the client browser has disabled NTLM. Turns out Firefox defaults to disabling NTML on all OSes whereas on Windows OS Chrome and Edge default to the OS settings (which generally default to NTLM enabled).

Ideally default behavior on all browsers on all platforms would be to ignore NTLM. That hasn't happened yet, but Microsoft is starting to phase NTLM out in Windows 11 with IAKerb.

See Also:

• Docs are misleading about mixed domain Kerberos SPNEGO keycloak/keycloak#16981
• https://bugs.chromium.org/p/chromium/issues/detail?id=458369

[simo5]

The issue with windows browsers is that they seem to unconditionally ask (via UI prompt) for NTLM credentials that will never work, even if we do not advertize NTLM as available.
If there is a way to let the bowsers understand that we can support Krb5 but no NTLM and therfore they can try krb5 negotiation but not fallback to NTLM then I am all ears, and I would immediately implement whatever is necessary to do that.

Note that mod_auth_gssapi can support NTLM (via GSS-NTLMSSP for example), it's just that most deployments don't.

[slominskir]

Since this mod_auth_gssapi software is ultimately about using Microsoft's www-authenticate: Negotiate scheme I think the dirty details and caveats should be clearly stated to minimize user frustration and so users can plan accordingly. If the explanation is too long for the README maybe just drop a link to another document into the README that explains what's up with Negotiate and Windows clients.

It is tricky to explain. The wording should be careful as you say above that "windows browsers...unconditionally ask... for NTLM... that will never work". Well, not exactly. Firefox is a windows browser that does not use an NTLM fallback prompt by default even on Windows (recent browser versions anyway). Plus it is possible for NTLM to work, it's just likely not something admins want to setup and use (as NTLM is less secure compared to Kerberos). Maybe the short explanation added to the mod_auth_gssapi docs could read something like:

Negotiate behavior is client specific and some browsers on Windows still use an NTLM fallback per the original Microsoft specification in RFC4559. It may be possible to disable NTLM fallback if an admin has control of every user OS and user browser, but in that scenario (corporate network/intranet) the admin has presumably correctly configured Kerberos so fallback is unlikely to occur. The larger issue is if you have an external facing auth server and therefore no control over all clients some of whom may be on Windows using a browser that delegates to the Windows Authentication subsystem. Browsers which delegate to the Windows Authentication subsystem, and therefore historically fall back to NTLM if Kerberos fails, include chromium based browsers such as Chrome and Edge as well as older browsers such as IE. Neither Kerberos nor NTLM are designed to work in a public Internet scenario and therefore using IP-based request filtering on the auth server to conditionally prompt only internal managed Kerberos clients (corporate intranet) users with www-authenticate: Negotiate is a reasonable solution.

It is certainly disappointing that some Windows clients still default to NTLM fallback and the "negotiation" piece is entirely up to the client-side it seems. If Chromium were to change the default behavior to disable NTLM entirely by default and require opt-in this would also likely resolve this issue. Saving that, it appears Microsoft may be phasing NTLM out of the Windows Authentication subsystem in upcoming Windows releases.

[simo5]

It seem you are turning this discussion into an issue?
If you want to see a code/doc change would you mind actually creating an issue (there is a button up on the right-side menu that will do just that for you).