Quote Originally Posted by edmaa View Post
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