Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
matt4 Honored Contributor.
Honored Contributor.
623 views

Kerberos Auth: Can the NTLM dialog be prevented?

I've used Kerberos auth with NAM for many years and one of the things I've always wondered is, is there a way to prevent IE (and now Chrome) from doing a fall-back to NTLM auth when Kerberos fails?

My understanding is that when the browser gets the "WWW-Authenticate: negotiate" header it will try Kerberos first and if that fails fallback to NTLM (which NAM of course does not support). This generates the familiar NTLM dialog box in IE and Chrome. This typically confuses users and so we always have to resort to using some other mechanism (e.g. Kerberos include/exclude lists, header injection at the load balancer, etc.) to prevent non-domain machines from attempting to negotiate auth. Firefox allows you to control the NTLM auth separately so it doesn't have this issue. I've looked on and off for a while, and I can't find any way to control this with IE (and Chrome since it uses the Windows settings).

Is there any local policy or registry key in Windows that will prevent the NTLM fall back on a negotiate auth? I'm more interested in preventing it in Chrome than IE, but I have been unsuccessful in finding anything (it looks like Chrome used to have a registry setting where you could control auth mechanisms, but it's not clear to me if that is still supported by current Chrome).

Or is the only option to keep tight control on the networks that are allowed to use Kerberos?

Matt
0 Likes
4 Replies
Highlighted
matt4 Honored Contributor.
Honored Contributor.

Re: Kerberos Auth: Can the NTLM dialog be prevented?

So an update to my post.....

I found that Chrome does indeed have a registry key for controlling authentication mechanisms. So I added this to my Windows machine:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthSchemes"="negotiate,digest"


The valid values are negotiate, digest, basic, and ntlm.

With the setting above, the browser does NOT fallback to ntlm and the dialog box never pops up! So I got what I wanted.

However, there is one caveat. I had to leave off BOTH ntlm AND basic, if I left either one in the key, I'd still get a dialog box to pop up. So what this means is that anything that uses/requires basic auth will FAIL (and I verified that, auth fails when attempting to access a resource that requires BASIC auth).

Not a perfect solution, but basic auth should be pretty rare now for normal users I think. I'm not sure why I had to leave off BOTH ntlm and basic. I find a lot of conflicting info on what exactly happens with WW-Authenticate: negotiate.

Still no option for IE though that I have been able to find.

Matt
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Kerberos Auth: Can the NTLM dialog be prevented?

On 08-01-2019 10:26 AM, matt wrote:
>
> So an update to my post.....
>
> I found that Chrome does indeed have a registry key for controlling
> authentication mechanisms. So I added this to my Windows machine:
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
> "AuthSchemes"="negotiate,digest"
>
>
> The valid values are negotiate, digest, basic, and ntlm.
>
> With the setting above, the browser does NOT fallback to ntlm and the
> dialog box never pops up! So I got what I wanted.
>
> However, there is one caveat. I had to leave off BOTH ntlm AND basic,
> if I left either one in the key, I'd still get a dialog box to pop up.
> So what this means is that anything that uses/requires basic auth will
> FAIL (and I verified that, auth fails when attempting to access a
> resource that requires BASIC auth).
>
> Not a perfect solution, but basic auth should be pretty rare now for
> normal users I think. I'm not sure why I had to leave off BOTH ntlm and
> basic. I find a lot of conflicting info on what exactly happens with
> WW-Authenticate: negotiate.
>
> Still no option for IE though that I have been able to find.


Are all domain joined PCs on specific subnets and non-domain joined PCs on others? If so, you could use a risk based policy, or from memory there is
also a file that controls whether to use kerberos auth or fall straight back to form based auth. If they are mixed its hard.


--
Cheers,
Edward
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Kerberos Auth: Can the NTLM dialog be prevented?

On 08-01-2019 12:56 PM, Edward van der Maas wrote:

> Are all domain joined PCs on specific subnets and non-domain joined PCs on others? If so, you could use a risk based policy, or from memory there is
> also a file that controls whether to use kerberos auth or fall straight back to form based auth. If they are mixed its hard.


The file is called:

/opt/novell/nam/idp/webapps/nidp/WEB-INF/classes/kerb.properties

#kerberos.include= range of IPAddress of client machines will be challenged for Negotiate and out this range client IPAddress will not be challenged
for Negotiate(kerberos)
#kerberos.exclude= range of IPAddress of client machines will not be challenged for Negotiate, All other IP ranges will be challenged for Negotiate
authentication (kerberos)
#
# IMPORTANT: Either use include or exclude property
#
# e.g., kerberos.include=164.99.84.0-164.99.84.204,164.99.84.205 or
# kerberos.exclude=164.99.84.0-164.99.84.204,164.99.84.205
#

I'd always prefer to do things server side rather than client side.




--
Cheers,
Edward
0 Likes
matt4 Honored Contributor.
Honored Contributor.

Re: Kerberos Auth: Can the NTLM dialog be prevented?

edmaa;2493267 wrote:
On 08-01-2019 12:56 PM, Edward van der Maas wrote:

> Are all domain joined PCs on specific subnets and non-domain joined PCs on others? If so, you could use a risk based policy, or from memory there is
> also a file that controls whether to use kerberos auth or fall straight back to form based auth. If they are mixed its hard.


The file is called:

/opt/novell/nam/idp/webapps/nidp/WEB-INF/classes/kerb.properties

#kerberos.include= range of IPAddress of client machines will be challenged for Negotiate and out this range client IPAddress will not be challenged
for Negotiate(kerberos)
#kerberos.exclude= range of IPAddress of client machines will not be challenged for Negotiate, All other IP ranges will be challenged for Negotiate
authentication (kerberos)
#
# IMPORTANT: Either use include or exclude property
#
# e.g., kerberos.include=164.99.84.0-164.99.84.204,164.99.84.205 or
# kerberos.exclude=164.99.84.0-164.99.84.204,164.99.84.205
#

I'd always prefer to do things server side rather than client side.




--
Cheers,
Edward



Yes, I mentioned this in the original post actually. Typically I've done this with the kerb.properties file. I've also done it where I had an f5 switch inject a header variable that I then used to determine whether or not to do Kerberos auth (negotiate or no negotiate).

I've thought about doing it using RBA now instead of kerb.properties since it is maintained in the GUI, but in this particular case I'm using RBA to require additional auth (2FA) when on untrusted networks and I couldn't quite figure out how to come up with a proper policy to handle both situations (the RBA implementation in NAM is quite confusing!). So I just used kerb.properties to include the same trusted networks. But I wouldn't mind seeing an example that did all of it in RBA without using kerb.properties.

The problem is, I have run into a few situations where I do have mixed requirements on the same subnet (e.g. both domain member and non-domain member). That is why I was trying to figure out a way to eliminate the NTLM fall back on the client side. I think it has to happen on the client side because all the IdP is doing is injecting "WWW-Authenticate: negotiate" and it is up to the browser to implement that. There is nothing you can do at that point from a server perspective AFAIK (someone correct me if I'm wrong here!).

Matt
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.