Kerberos fallback to form chain authentication gets basic pop up for external users

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER

Issue/Introduction

Customer implemented Kerberos fallback on login form chain authentication in their environment, which means if the user tries to log in to Siteminder protected applications within company VPN, Kerberos seamless login should work. If users are not in company VPN (or external users) network, they should get form login page directly.

For most part, this is working already for internal users.
However, some applications are external facing and customer has no control over browser settings. When users access the application from external network and get basic login popup first, they have to cancel it in order to see login form.

If users enter credential at basic login popup, they will get stuck. If they hit cancel, then they will see the login form.
The expectation is that, external user who is not in company network should see login form directly.

The basic login popup resembles NTLM pop up login.

When external users test for this chain authentication from external network.

1. Firefox is persistently working fine in this use case flow.
2. Chrome, IE, Edge do not work. User gets basic login prompt. When this happens, we can see set-cookie SMKRBCHALLENGE=yes.
3. Tired to set "Ambient Authentication mode in guest session", via Chrome config "chrome://flags/", but it has no effect.

In last step of IE/Chrome request, browser stops at HTTP/1.1 401 Unauthorized.

Content-Length: 176

<!DOCTYPE html><HTML><HEAD><meta name="robots" content="noindex, nofollow" /><meta http-equiv="refresh" content="0" /></HEAD><BODY>Redirecting credential page...</BODY></HTML>

The above code is generated by agent plugin from access gateway side, in an attempt to redirect to form login. This will require browser to support <meta http-equiv="refresh" content="0" />.

In fact, this is one of the pre-requisites of implementing Kerberos chain authentication.

Environment

Release : 12.8

Component : SITEMINDER SECURE PROXY SERVER

Cause

The cause comes down to how Kerberos authentication is performed and how SiteMinder implements the authentication chaining flow. An HTTP server does not send an HTTP response specifically requesting Kerberos authentication. To begin authentication with the web browser the HTTP server sends an HTTP 401 Unauthorized response with a "WWW-Authenticate:" header. The value of the header determines the kinds of authentication mechanisms supported by the web server. In the case of Kerberos the mechanism is "Negotiate", but this includes both Kerberos authentication as well as NTLM authentication.

If the browser can perform Kerberos authentication, then it acquires a Kerberos service ticket to the web server and sends it in an HTTP "Authorization:" header to the web server to be authenticated.

If the browser cannot perform Kerberos authentication (not configured to do so, cannot contact the Kerberos Key Distribution Center (KDC), etc.) then the browser falls back to attempting NTLM. To perform NTLM the browser prompts for username and password. This is the pop up that appears (often mistakenly called a "basic pop up" used for HTTP Basic authentication).

At this point, the browser shows the NTLM authentication pop up and does not automatically move forward, falling back to the HTML form.

If the user enters credentials, authentication will fail since SiteMinder is expecting Kerberos credentials not NTLM. Because Kerberos authentication chaining is configured the browser will then be redirected to the HTML form page.

If the user presses the Cancel button in the pop up dialog, the browser typically sends another request without credentials. Because Kerberos authentication chaining is configured, the first HTTP 401 response includes a cookie (SMKRBCHALLENGE=YES). On the second request, after pressing Cancel without credentials but with the cookie, the browser will be redirected to the HTML form page (and the cookie value cleared).

The SiteMinder web agent code does include an HTML body in the initial HTTP 401 response with an HTML "meta redirect" that immediately reloads the page. The intent is to try a workaround to prevent display of the pop up dialog. If Kerberos is working, then the reload will contain Kerberos credentials. If Kerberos is not working, then the reload will not contain Kerberos credentials but will have the state cookie and the browser will be redirected to the HTML form.

The problem is that the HTML "meta redirect" may or may not be honored depending on browser, browser version, and operating system. Thus the pop up dialog cannot always and consistently be avoided.

Resolution

Browser support is out of Siteminder product scope. And no one can have full control over external users' browser settings.

It is best to use HTML login form for external users and keep Kerberos for internal users. Or have a main landing page for everyone, and let the users decide what option they would like to do (external vs. internal).

Additional Information

https://support.google.com/chrome/thread/38855209?hl=en
NTLM / Kerberos authentication disabled by default in Incognito mode and guest sessions
Ambient authentication (NTLM/Kerberos) will be disabled by default in Incognito mode and guest sessions in Chrome 81. To revert to the old behavior and allow ambient authentication, use the AmbientAuthenticationInPrivateModesEnabled policy.

Kerberos troubleshooting guide
https://community.broadcom.com/communities/community-home/librarydocuments/viewdocument?DocumentKey=bc3b8de9-fe6a-4394-94b4-4d549a943ab0

The sequence of Kerberos Authentication
https://knowledge.broadcom.com/external/article?articleId=14920