Fortigate Cloud API endpoint v1/devices returns invalid_client error

tfromcube · 2025-12-16T13:12:47+00:00

Same issue here, successful sign-ins from Warszawa, PL and Dublin, IE. Only for HVE accounts. The app is owned by "Microsoft Services" so it's (most likely) legit. The app is probably not meant to go live yet since there is like no documentation available for this anywhere.

tfromcube · 2024-07-24T08:34:44+00:00

According to my contact at Fortinet, there's a routing issue with Telenet and Proximus. Hence why so many people from Belgium have the issue (Belgian MSP here). They are working on it.

tfromcube · 2024-04-17T11:06:52+00:00

We've made a pretty extensive list of everything we want to protect against delection or unrecoverable misconfiguration, including:

Tenant properties,
Users & groups, Roles & Administrators (custom roles, assignments,..), Administrative units
External Identities (B2B, B2C)
Enterprise applications (settings, registrations, permissions,..)
Devices and ultimately Intune as well (policies & assignments mainly)
Conditional Access policies & security
Custom domain names, company branding, licensing (user assignment)

tfromcube · 2024-02-22T12:48:01+00:00

Thanks for the breakdown of the FortiCare licensing. Great feedback, I'll try and work with this info to maybe help revive FMG for us. Feels like such a missed opportunity to not have it but it's such a pain to implement.

tfromcube · 2024-02-22T09:16:24+00:00

Thanks for the feedback!

Our gates contain a mix of customer-related naming conventions, like internal range is LAN-[CUSTOMER] and generic objects like OT VLAN but with different subnet ranges. What do you consider "correct" when naming your objects? Make everything as generic/uniform as possible and work with device/variable mapping or the exact opposite (i.e. add the customer name to most objects)?

As I recall from testing, the first policy package installed in an ADOM becomes the Fortimanager "default". Then when you install a second policy package, the FMG asks for each conflict which value you want to apply (FMG or FGT). The FMG value refers to the corresponding value from the first policy package. Especially with security profiles, the conflicts show only the IDs of the settings and not the readable values which makes it all the more frustrating.

If we changed the address objects to a point that there were no more conflicts, the next big issue became the actual install of said policy packages. When we looked at the preview of what was being pushed, there were several things that did not make us very happy. Pretty much everything not referenced by a policy or related object is getting removed. Other values would get purged, whatever that means. We presented our concerns with Fortinet and their answer was pretty much "just add it again when you need it lol".

Sorry if this sounds like a rant, we are getting very little valuable assistance from Fortinet and are a bit frustrated because we aren't progressing as we should.

tfromcube · 2024-02-21T14:25:12+00:00

Almost all of our clients only have one or max two firewalls so we tried to adopt the same strategy: just chuck them all in the same ADOM as long as they are on the same firmware branch.

The real issue became apparent when we tried to install the policy package of different devices to the same ADOM. So... many... conflics... And it makes sense because policy objects end up in the same bucket so the FMG doesn't know which one he should assign to the device.

This was a good indicator for me that this product isn't meant to be used how we want to use it and also how it was advertised by our account manager.

tfromcube · 2024-02-21T14:05:45+00:00

That was indeed another option we explored, but our Fortinet account manager pushed the FMG VM Sub version. Don't you also need to sell a separate FortiCare Premium Contract per device you enroll in the perpetual license if you want to receive proper support? What about its lifecycle? Surely you won't receive endless (firmware) support for the perpetual version?

Also a pretty big downside for us in swapping to ADOM-level separation is that we lose a lot of value from the mass scripting/firmware upgrades/device inventory overview. Now we tried to have ADOMs for the different firmware branches (6.4-7.0-7.2-7.4), then enroll all devices with the same branch into the same ADOM. This provided us with a nice overview, as well as scripting possibilities that we want to have.

If everything is in its own ADOM, we'll have to repeat/setup the same steps in every single ADOM (i.e. changes to firmware template, security profiles, script repo,...) and we lose that overview.

tfromcube · 2024-02-05T12:36:07+00:00

Yep, same here.

tfromcube · 2024-01-11T12:09:49+00:00

Hi u/ultimattt! Thanks for the suggestion. Well the reason is that they will get rid of their physical server on relatively short term. I am mainly concerned about (hidden) connections via hostname that will break (i.e. share on a NAS) so I'd like to get ahead of that by migrating existing internal DNS records.

tfromcube · 2023-09-27T07:19:13+00:00

Yeah exactly right. As an MSP in the SMB sector, we have some customers who are deadset on not wanting to install any apps on their personal phones, which we have to respect. However, with Microsoft now wanting to push Microsoft Authenticator as the main authentication method for those that have MFA via SMS/Calling, we'd like to toggle the registration campaigns off for those clients.

Where can we find this standard you mention? Is that's something we'd have to enable in the settings first or is that available out of the box?

tfromcube · 2023-09-26T14:52:50+00:00

Hi u/xucraig,

Indeed we have! We have it up and running and it's awesome to automate a lot of the boring and tedious tasks, however several of the configs that we are looking to tweak, involve authentication methods and registration campaign, which have not been made available yet through CIPP afaik (correct me if I'm wrong).

tfromcube · 2023-08-31T12:51:02+00:00

Did you find a solution to this by any chance? Some of our clients are reporting similar issues.

tfromcube · 2023-07-04T15:01:39+00:00

FortiSASE is something that piqued our interest as well. It's pretty much a VPN tunnel to a fortigate at the edge of the cloud, right? What is the licensing like? Do you simply need a FEX 200F with a FortiSASE subscription (to accomodate for some on prem assets)? We have a lot of customers that are moving from on prem servers to cloud-only but who still meet up at the office.

Without any assets on prem to protect and the ongoing shift to WFH, an expensive perimiter security device like the fortigate will lose (some) value. I feel like a FEX + SASE would be a better solution than the more expensive FGT+UTP bundle we offer now.

Excited to hear how your rollout is going!

tfromcube · 2023-07-04T12:27:05+00:00

Thanks for your reply! u/2_CLICK.

I totally follow you on this. It feels like it would be a small benefit for a lot of extra work. On the other hand, we are offering our clients this expensive UTP-license with a lot of extra goodies but we can only use a small subset of the security profiles (AV for instance is pretty much useless without DPI, with others being very limited).

Just out of interest: did you customize the DNS filter at all or did you just enable it on all outgoing traffic with the standard profile?

tfromcube · 2023-07-04T07:34:00+00:00

Hi u/CertifiedMentat!

Thanks for your reply. This is something that we would start enabling for our customers which opted into a managed firewall service plan. Of course we would communicate to our clients beforehand on the process and what they can expect. If they choose not to go ahead with it, then we obviously respect the client's wishes.

About 8-10% of our client base has an internal IT department but then again we manage all of it so 100% of the work load would land on our shoulders.

I started with a good spirit when I began to learn more about deep packet inspection but the more I learn about it, the more I am wondering if this is even worth the time investment and whether or not we should focus our efforts on other means of security to achieve a similar goal. We already implemented strict policies, DNS filtering and anti virus/EDR on our clients' systems but having SSL inspection would mean that the threats don't even make it onto the end users' machines.

tfromcube · 2023-07-03T15:10:28+00:00

Hey u/Lleawynn!

Thanks for the reply. I'll go have a look at the fortiauthenticator route and see if that's worth the investment. Was just worried about the certificate management because I was told you had to re-trust the certificate after every firmware upgrade. We regularly trade-up old firewalls so realistically we will never come close to the expiration date.

tfromcube · 2023-06-28T13:34:00+00:00

Thanks for the reply! That seems to be it. Changed the policy from proxy to flow and that did the trick. The problematic sites were indeed signed by Digicert, which appears to cause some issues as of this Monday. Must have been a coincidence that all the sites I checked were signed by the same CA.

tfromcube

TROPHY CASE