This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSO or alternate secure authentication with hardend AD

Hello,

Until now we used AD-SSO and it worked. Now we're in the process of hardening our AD and want to disable NTLM as far as possible.

Since the UPM uses NTLMv2 for SSO that's a problem. Of course we can define an exception to still allow NTLMv2 for the UTM but we want to avoid that. And if the UPM looses connection to the AD and needs to be joined again (had happened after some updates in the past) we still have to re-enable NTLMv1 and SMB1 on the DCs for the joining-process as far as i understand. That's alot of work in our environment.

That brings up multiple questions.

1. Is there a way to use AD-SSO without NTLM (Kerberos/Ldaps only)?

2. If not, is it "secure" to use "simple user athentication" instead with ldaps against AD? Background of that question: I don't know how authentication against the proxy works with this setting and it's hard to find information about the details. I'm worried about compromised AD-Accounts by things like extracting/cracking hashes or sniffing clear-text passwords submitted somewhere.

3. What is the most "secure" way to do proxy authentication in your opinion? Local users/groups on the utm? We need to apply different filters to different users on the same machine (Terminal-Server for Internet-Access).

Thanks for reading. Hope you can help me.



This thread was automatically locked due to age.
Parents
  • 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.

Reply
  • 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.

Children
  • 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.