SSO or alternate secure authentication with hardend AD

My understanding:

Web Proxy uses NTLM authentication based on information provided by the browser, and is validated using the Active Directory system of which UTM is a member.   The configured Authentication Servers are not used

All other authentication uses the Authentication Servers but not the Active Directory join.   These login functions include User Portal, WAF, and VPN Client.   I don't see Client Authentication to Web Proxy as very useful, but I am guessing that it uses the Authentication Services.

So you could switch your Authencation Services to LDAPS, but it does not solve the entire concern.

My own opinion is that AD SSO has so many benefits, and keeping it in place would be my security priority.

(Fine print:   As I have posted elsewhere, I use Standard Proxy with AD SSO, as well as Transparent Proxy with Authentication None.   This ensures that all traffic is protected.

Many things you say are correct but one thing i'm absolutely not with you: Keeping SSO in place may have benefits but it's not the best solution from security perspective. That would be a seperate user on the utm with a seperate password and no connection to any DC allowed. But that way we have to do user-administration twice.

If you stay with SSO as it seems to be implemented you have to keep NTLMv2 allowed for the UTM and Terminal-Server, which are in fact the two most exposed systems in our network. You can argue about "how secure" NTLMv2 is in a properly hardened AD. We consider it "not secure enough" because of serveral reasons. Even if we could use kerberos instead that would be a problem since it's also not really secure anymore with Server 2016 AD but at least the afford to compromise an account would be much much higher. Not to mention the fact, that it's an absolutely no-go to keep SMB1 and NTLMv1 activated on an DC. Here we have to expect additional work every time we have to (re)join the UTM.

On the other hand if the terminal-server is infected, a software keylogger will also be able to read the password when a user is prompted for it. I'm not sure if the degree of infection makes much difference here. The way the authentication works in detail can make differences and i know nearly nothing about it.

To be honest i don't know what i has hoped for. Manually entering an AD-password on a potentially compromised system is surely not the best idea when thinking about keylogging. Using a potentially unsecure authentication method may really be a bit more secure because attacks are not that easy. And of course that shouldn't be the only thing you do for AD-security. A compromised "simple-user-account" shouldn't lead to much damage but in my opinion every "wall" should be as high as possible for an attacker.

Since we "only" need to apply different website-categories to different users it would be enough to read the username of the session the browser runs in and check the group-membership by LDAP to apply the correct-filter. In my opinion there is no need for real authentication at all. But since there a no other answers this seems not to be possible and i don't missed a configuration-option.

So at the end, if we want to keep using the UTM-webfilter, we have to make a choice between SSO with the known problems or doing manual authentication against the UTM, which means additional work. Since we talk about less then 50 accounts with internet-access and we don't have high fluctuation i think the choice is already be made.

If anyone has another idea it would be great to hear.

Hallo DD and welcome to the UTM Community!

Instead of setting Users' browsers to access the UTM web Proxy by using the IP address of the UTM, use an FQDN to force authentication by Kerberos instead of NTLM.  Does that do what you need?

In any case, you might be interested in the Configuring HTTP/S proxy access with AD SSO KnowledgeBase article.

Cheers - Bob

Thanks. That way it was configured before we tried to change things. We last joined the UTM in 2008R2-days and after that migrated to server 2016 DCs. No problems arised but now we started logging for NTLM-authentication and even with FQDN as proxy we got NTLM-authentication.

I then tried to rejoin the UTM to our domain (failed) and this leds to research about how SSO is working and what 's necessary. But info even here in the community forum seems to be oudated or incomplete.

With your answer now that kerberos should work i got back to the point we started: No way to rejoin the UTM to our domain. Error: "Failed to join domain: failed to lookup DC info for domain 'xy.ourdomain.zz' over rpc: Account restriction" user_name="xy(domain-admin-rights)" domain="xy.ourdomain.zz"

I already re-enebaled NTLMv1 and SMB1 but without success. Asking myself if this is really still necessary or old info for older versions.

Also gone though this without finding a problem: support.sophos.com/.../KB-000035211

Since it seems rpc-related, we currently enforce denial of vulnerable netlogon connections as stated here: support.microsoft.com/.../how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc

Any advice?

I'm no Winserver guru.  The only thing you might try is deleting the UTM account in AD before trying to rejoin the domain.  Any luck with that?

Cheers - Bob

First thing i tried and other things,too. Maybe someone else can help but i suppose i will end up with a support call.