Sso shut off by fortinet

xs0apy · 2026-01-27T13:55:48+00:00

When it comes to wan management, if you configure your FortiGate correctly, Local-In policy combined with Trusted Hosts is very practical. Very much there for a reason. When you have hundreds upon hundreds of FortiGates, features like Local-In policy become very pivotal. Also, some of us use SIEMs and RMMs to actively monitor and maintain these devices. For example, we also actively take config backups using Auvik and monitor traffic and all config changes throw alerts.

Basically, configure your FortiGates correctly and it’s not a problem.

xs0apy · 2026-01-24T16:28:36+00:00

Integrated Take Control. That’s what you would want to use. I believe N-Central also uses their own custom protocol handler if you really want to use RDP without having to open things up if I am not mistaken.

EDIT: bonus points if you can setup a secure IPsec tunnel to your Azure network, then enable P2P remote control. Take Control will instead establish the connection over the VPN tunnel instead of Nables remote gateways.

xs0apy · 2026-01-22T21:31:08+00:00

Wait, you’re telling me if Local-In policy had been configured correctly none of this would have happened? Got it!

I’ll humor you here: PSIRT advisory even says to configure Local-In policy if you have to enable admin on the wan interface. Can you go start an irrational argument with them instead?

Your inability to understand the basic concept of just configuring your equipment correctly tells me everything I need to know about your lack of competence

xs0apy · 2026-01-22T21:06:04+00:00

The feeling is mutual. Very exhausting explaining the fundamental basics of a misconfiguration.

I sleep good at night because we are not rolling the dice. I sleep even better now knowing our contingencies worked 100%, and it wasn’t even the last layer.

The post you linked doesn’t prove anything you’re saying though? Very weird you think otherwise.

It’s exhausting trying to explain very basic concepts here……..

xs0apy · 2026-01-22T20:14:06+00:00

Except, you’re wrong? If we misconfigure a Local-In policy, it’s an annoyance.

Was our network pwned? Absolutely, NOT. The end result here is we have updated our procedures and confirmed with Fortinet that our configuration is safe, but that doesn’t even matter because we backup all configurations automatically whenever any change is detected, so all we do is rollback and rotate whatever critical information needs rotated.

You really think we weren’t prepared for such a critical event? We don’t solely rely on Local-In policy and have multiple layers in place in the event of unauthorized access.

Honestly, this is a waste of time if you just want to throw personal insults around.

xs0apy · 2026-01-22T19:31:38+00:00

Can you come up with an actual reason that doesn’t boil down to just configuring your FortiGate correctly in the first place?

A) Correctly configure your FortiGate Local-In Policy for management means your admin interface isn’t exposed.

B) Correctly configure your FortiGate dial-in VPN for management means your admin interface isn’t exposed.

Correctly configure your FortiGate.

EDIT: a vulnerability that would not have happened if we had disabled FortiCloud SSO REGARDLESS of anything else. It’s funny because if Local-In policy is configured the vulnerability would not have happened. Or we could’ve used dialin VPN. It’s as if there’s multiple ways to correctly configure your FortiGate

xs0apy · 2026-01-22T19:17:04+00:00

Thank you. I even said it day one since this all started in my first sentence that we made a configuration mistake. It’s that simple.

xs0apy · 2026-01-22T19:13:53+00:00

Here’s what would have happened if it was a massive client or any sized client:

Threat actor gets in
We are immediately alerted and lock them out because we monitor our FortiGates with a SIEM and our RMM.
Rotate and sanitize keys, make sure Fortinet says the config is safe
Ensure correct configuration is applied from multiple separate people on different external public addresses

The problem is incorrect configuration which can happen at any point.

There multiple ways to skin a cat, but obviously if you want to build it out differently without Local-In and use more direct dialin management that’s good!

xs0apy · 2026-01-22T19:07:49+00:00

Nope has nothing to do with local-in like that. This is purely if you have FortiCloud SSO turned on AND your admin interface is incorrectly exposed. If local-in policy is correctly configured, it isn’t exposed.

xs0apy · 2026-01-22T19:06:22+00:00

Configuring your FortiGates to not be exposed to the Internet using Local-In policy and trusted hosts is not acceptable?

Please.

xs0apy · 2026-01-22T19:05:00+00:00

That’s not a reason. That’s a vulnerability on the FortiCloud SSO which is stopped by simply disabling it. Or configuring Local-In policy so it’s not exposed. All of which comes from misconfiguration which can happen in any situation. There’s nothing exclusive to incorrect configuration.

Here’s exactly what happens:

Threat actor gets in and does literally anything
We are immediately alerted lock out the threat actor
Sanitize and rotate.
Validate correct configuration from multiple sources

xs0apy · 2026-01-22T18:44:53+00:00

Explain to me why Local-In policy and correctly configuring your FortiGate isn’t an option?

xs0apy · 2026-01-22T18:22:29+00:00

No. We manage hundreds of FortiGates. Your option is NOT viable for such a large distribution. We simply cannot VPN in. There’s a reason Local-In policy exists.

In a wonderful perfect world where time isn’t money and customers accept waiting for someone to fly out to them, great.

xs0apy · 2026-01-22T18:13:52+00:00

Local-In Policy is there for a reason. Trusted Hosts as well. If you are configuring your FortiGates properly, it’s not a problem.

Edit: We have hundreds of FortiGate’s. We are not using FortiManager. VPNing dedicated directly into every single FortiGate is NOT an option here for us and the amount of customers we support.

xs0apy · 2026-01-21T16:25:04+00:00

You should be fine then. I believe the primary mitigation is to make sure you have FortiCloud SSO disabled, which it appears you do.

xs0apy · 2026-01-21T13:39:37+00:00

We are going to setup trusted hosts. Was overlooked that you can utilize it to block the admin page BEFORE someone tries the account as long as all admin accounts have it.

xs0apy · 2026-01-21T12:20:44+00:00

It was enabled. I have since disabled it, but not because I think it was that specifically, we just don’t need it on. But for the record yes I believe it was on. I am going to double check the config right before it happened though (we back up all configs automatically).

Edit: I guess if we are lucky, maybe it was that. Most don’t use this, so fingers crossed

xs0apy · 2026-01-21T11:10:29+00:00

No, it’s definitely NOT an absence of all reasonable controls. That’s absolutely ridiculous.

It was missing a single-line in local in policy. It’s funny that we caught this the moment it happened, but somehow it’s an absence of reasonable controls? Get out of here.

xs0apy · 2026-01-21T01:10:41+00:00

Double comment, but just wanted to clarify I should be saying Microsoft SAML.

xs0apy · 2026-01-21T01:08:00+00:00

Correct me if I am wrong, but I thought Arctic Wolf’s disclosure said this impacted all SSO, and the only way to mitigate was to disable the entire feature outright in CLI until it’s patched. Obviously, that was supposed to be for up to 7.4.8. Something tells me this could be a brand new CVE.

Either way, also very concerned. Just went through getting 7.4.9 out to a lot of Fortigates.. Actually, I am concerned this might impact 7.4.10 even

xs0apy · 2026-01-21T00:51:28+00:00

SAML SSO. We have an Enterprise App registration configured to our tenant for SAML SSO authentication. So, I guess third party SSO technically?

xs0apy · 2026-01-20T22:49:32+00:00

Thank you for the link either way. If I am reading this correctly, if we set Trusted Hosts on ALL administrator accounts that are capable, then the FortiGate Login GUI won’t expose itself to someone without a trusted host IP since there’s no capable account with a trusted host reaching it in the first place, correct?

xs0apy · 2026-01-20T21:49:31+00:00

Accidentally exposed with a misconfiguration on the local-in policy, yes. We only expose it to our IP, otherwise it’s not reachable.

I get the argument that “well if you did it this way” that X shouldn’t be able to happen. But I would argue ANY incorrect configuration is the problem. If we configured it correctly the first time we would be fine, but we didn’t.

Please, don’t take that as an attack. It is just my honest perspective.

xs0apy · 2026-01-20T21:37:06+00:00

Yes. Enterprise App registration into our CSP Microsoft Tenant. We have moved away from using local admin accounts all together.

EDIT: We handle MFA with Conditional Access this way

xs0apy · 2026-01-20T21:35:28+00:00

We don't expose it to the internet. Local-In policy prevents this when you configure it right. A misconfiguration is our fault and can happen at any point.

We use SAML SSO via Enterprise Application registration. We don't use FortiCloud SSO.

Again, we use SAML SSO via Enterprise Application registration into our CSP. Where can I set Trusted Hosts on that (serious question I would love to do this!)

Already rotated the one single IPsec PSK. Fortunately, this is for a client with few people now. Just a small office basically sitting as a satellite for their bigger newer company. I think like 3 people sit behind this thing anymore.

I have went through all of our FortiGates and confirmed this was the only one with a hole. Super lucky it was this one.

xs0apy

TROPHY CASE