NTLM is a deprecated authentication protocol that is incurably subject to relay attacks. Microsoft is actively working towards removing it and it’s best practice to try to get to the point where it can be turned off in your environment. One expects to have to leave it enabled in cases where legacy apps that cannot be rewritten to current standards must continue to be used. One does not expect to have to leave it enabled for a current version of a currently supported product from a security/firewall company to function.
How can I get the browser-based RDP client in the web SSL VPN to use Kerberos properly? Currently, there is no way to connect to any workstation which has incoming NTLM disabled.
I don’t think you can.
For Kerberos to work in this scenario, the FGT would have to domain-join and pretend to be a PC. Not aware of anything like this ever being configurable in SSL-VPN context.
You’re worried about NTLM and not the most vulnerable part of the entire Fortigate system - web mode ssl-vpn? Don’t use it at all or roll your own guacamole server. There’s been way to many vulnerabilities in ssl-vpn recently to be able to recommend anything else.
all signs are pointing to Fortinet ditching fortigate ssl vpn, i’m 100% convinced they have no interest in patching the web mode.
It absolutely doesn’t need to be domain joined. This would only be true if it needed to authenticate as an account protected with an authentication policy silo (can only sign into certain computers), or a resource protected by dynamic access control (that the user can only access from certain computers), or Kerberos armoring is required. These are the only times you need a claim in your ticket saying what computer you are logging into, and most of these are uncommon except on highly privileged accounts. Otherwise, no computer account is required at all.
Non-domain-joined Windows computers even use Kerberos if they have the necessary info to find the domain (for example, a file share is accessed, and you use the UserPrincipalName ([email protected]) when authenticating to the share). Plenty of third party solutions use Kerberos when they have sufficient info as well.
The only way not being on the domain can impact the ability to use Kerberos for a regular user is that you don’t intrinsically know the FQDN of the domain, so ancient DOMAIN\Username notation does not work. (because it can’t tell if COMPANY\User is for company.com, .net, .org, whatever, so it can’t look up DCs in DNS). But a UserPrincipalName provides all you need to find a DC.
Once you find a DC (which is a Kerberos KDC) you just request a TGT (Ticket-Granting Ticket), same as any logon. You hash the user’s password to get their AES key, you use that to encrypt the current timestamp as part of your pre-authentication when you request a TGT. The DC (only other entity that has this AES key) sees your pre-authentication is valid, and issues a TGT encrypted with that key, and sends it to you. You decrypt it and you have a TGT. Notice the computer identity never came up! Now, using the TGT you can request (from the DC) a service ticket to the target computer, and away you go.
If you’d prefer hard examples rather than theory,
- FreeRDP 3 supports Kerberos and is not Windows based.
- Non domain joined Windows personal devices with line of sight to a DC can do kerberos if you connect to an FQDN and provide your username in [email protected] form
- Macs can do the same, regardless of whether they are bound to AD or not
Those vulnerabilities have been patched. Would I prefer a product that didn’t have a history of vulnerabilities? Sure. But a refusal to address a known vulnerability (NTLM has many of those!) is a far bigger red flag than a history of issuing patches.
If it was solely up to me, we’d only be using certificate-based always-on VPN to a Windows RRAS server, but that’s because I’m not a big fan of BYOD/home devices being able to connect, managing FartiTokens, etc. But the budget and whether everyone who can sometimes WFH gets a laptop purchased is outside my scope.
I’m not the network admin here, but am the systems admin being prevented from enabling more secure settings in the AD environment due to the need to support brand-new firewalls that behave as legacy applications.
EMS 7.4 has it disabled as a feature and warns you that it’s a security issue and recommended not to enable it, so yeah.
Fair point. I didn’t consider (tl;dr) just ad-hoc gathering all the info required for Kerberos auth and just doing it.
Nevertheless, FortiOS doesn’t support this either, as far as I am aware. And it most certainly will not in the future, with SSL-VPN winding down in general.
Yep, and even if you enable SSL VPN in GUI in FortiGates (and let’s not forget them removing SSL VPN on lower end FortIGates now), web-mode is still disabled by default, you have to manually enable it in the CLI.
with SSL-VPN winding down in general
People keep saying this. Can anyone please provide an official source? I’m not aware of SSL VPN being deprecated, nor am I aware of a functional replacement from Fortinet which:
- Can reliably connect on the go, never blocked on public Wi-Fi - meaning it’s TLS over 443, indistinguishable from HTTPS unless you’re doing DPI - which public Wi-Fi never does because they don’t have a CA their users all trust.
- Has a web based option for BYOD, for granting remote access to contractors who aren’t admin on their local machines to install a client, for example.
So, where is the official announcement that Fortinet is abandoning these needs (or the announcement of a replacement)? As far as I am aware, Fortinet still tells people to deploy SSL VPN when they have either of these needs. IPsec/IKE meets neither of those needs.
TLS is not intrinsically buggy. Most of the internet runs on TLS. The fact that Fortinet has an endless stream of bugs in its TLS-based VPN implementation doesn’t mean the concept of a TLS-based VPN is flawed. I’m not saying Fortinet is wrong to give up on fixing its buggy SSL VPN - I am saying Fortinet needs to give up on the current incarnation, have qualified developers write a new one from scratch in a modern, memory-safe programming language such as Go, and not give up on the concept altogether because the need isn’t going anywhere.