How to Grant CLI Access to VDOM Administrator for Debugging Purposes

[5q46n2te8jPWJY]

Hello,

I have a Fortigate with several VDOMs (root, VDOM1, VDOM2), all managed with Fortimanager.

For debugging purposes, I need to give the administrator of VDOM2 access to the CLI of VDOM2. How can I do this?

From Fortimanager? From Fortigate?

Thank you for your assistance.

[Elmir]

In Fortigate, just create a new administrator account. You can configure it to limit access to only certain VDOMs. I guess you can accomplish what you are looking for. Also, you can create an admin profile to permit access to only certain areas.

[5q46n2te8jPWJY]

I tried to create a new admin account with a readonly access on his vdom but it don't work, user can't connect to GUI

But if I set the profile to "super_admin", user can connect (but he is global admin, and this is not what I want)

[5q46n2te8jPWJY]

I might have an explanation.

I am trying to connect my VDOM2 admin by accessing the Fortigate GUI with an IP linked to VDOM1.

How can I do this?

[Elmir]

It appears that the user is unable to access the system because VDOM2 is not set as the Admin VDOM. I tested this scenario in my lab by setting only the Traffic VDOM and was unable to gain access. Direct access to the traffic VDOM without going through the Admin VDOM is not possible, which I guess is expected behavior.

To resolve this issue, ensure that both VDOM2 and the Admin VDOM (root?) are permitted. This should allow the user to access the GUI. Additionally, create a new admin profile with the desired restrictions.

[5q46n2te8jPWJY]

Thanks, I'll test this

[Elmir]

OK. Here is the sample configuration:

--------

config system admin
 edit "test-admin"
  set accprofile "test"
  set vdom “VDOM-traffic" “VDOM-root"
  set password ENC SH24/2SXi
 next
end

config system accprofile
 edit "test"
  set secfabgrp read
  set ftviewgrp read
  set authgrp read
  set sysgrp read
  set netgrp read
  set loggrp read
  set fwgrp read
  set vpngrp read
  set utmgrp read
  set wifi read
 next
end

-----------

[palatisa1]

Correct. Changing config directly on the FGT will result in out of sync statuses in the FMG. This defeats the object of FMG. Rather create FMG user for client and assign their specific Adoms/policy packages to this user.

[5q46n2te8jPWJY]

Yes I know that. I just want to permit to my user to use CLI to debug.

[Toshi_Esumi · Accepted solution]

Debugging almost always has to be done at the managed device in CLI, like IKE debugging, flow debug, even sniffing. Not impossible to do it via FMG but it wouldn't be real-time. Even changing some config directly at the device for the part that is NOT managed/regulated by FMG wouldn't defeat the purpose of using the FMG. As long as you're aware what you're doing and what needs to be done at FMG after that. For example, adding a new RADIUS server to a FGT and test before deployment is much easier to do it at the FGT. If FMG, you have to use a script then run it against the device. That's nothing different from changing it at the FGT, which is much faster. We don't even manage/regulate any RADIUS config on managed FGTs while the main purpose of having FMG is to manage policy&objects for multiple devices to avoid similar config.

In you case, the key is those VDOM admin users need to access their vdoms on the interface, which is in their VDOMs. If they don't have direct reachability to the interface, you might need to set VIPs from a reachabile interface.

Toshi