VSNext and TACACS+ authentication - defining TACP-15 for non-local Gaia admin user

[m1l0514v]

Hello wizards,

• environment: 2x 19200 with R82  ElasticXL and VSNext, 10+ Virtual Systems
• mission: authenticate non-local Gaia users with TACACS+
• state to resolve: how to configure TACP-15 role with intended assigned privileges equal to adminRole. 

Following the information in R82 Gaia Administration Guide and recommendations from https://support.checkpoint.com/results/sk/sk98733, we configured TACACS+ Server, we prepared the TACP-0 role on VSNext gateway. We created role TACP-15 with all-features. Trying to allow TACP-15 to all virtual systems we've received following error: 

[Global]:0> add rba tole TACP-15 domain-type System all-features
[Global]:0> add rba role TACP-15 virtual-system-access all
NMSRBA0429  The following features: CloningGroup, aaa-servers, backup, command, configuration, cron, expert, expert-authentication-method, expert-password, expert-password-hash, ftw, group, grub2-password, grub2-password-hash, rba, scheduled_backup, snapshot, user, are restricted to global users only, and therefore cannot be added to roles with specific VS access.

Is there any document, guide with examples related to configuration TACACS+ authentication in VSNext environment? All documents I've found till now looks like related to Legacy VSX. Is there any known difference between VSNext and Legacy VSX related to TACACS+ authentication? Any hints what features should be assigned to admin role ?

I know a lot of questions, not ultimate solutions are expected, but any tips, hints and opinions to topic are welcome. 

milo

[PhoneBoy]

In Legacy VSX, much of the OS-level VS configuration comes from Security Management and cannot be done through Gaia OS directly.
This concept is reinforced by the fact there are VSX Gateway specific objects with Legacy VSX installations.
That also means that common settings (like interfaces/routes) apply to all VSes. 

In VSNext, the OS-level VS is defined on the gateway itself and VSes are defined as regular gateway objects.
Unlike Legacy VSX, you can have VSes managed by completely different Security Managements in unrelated SIC domains (either standalone or multi-domain management).
Also, you can use standard mechanisms (WebUI/clish) to affect OS-level VS changes (e.g. add interfaces/routes).

All of which suggests that the relevant configurations for VS access need to be applied at the VS level.
This means you need to apply the relevant configuration in the context of each VS (e.g. by using 
set virtual-system X in clish or via the WebUI). 
The steps should otherwise be identical.

[genisis__]

I did have a TAC case related to this, and legacy VSX running R82.  However the issue we had related to being in expert mode and switching into VS's, which could not be done (been a while since I looked at this though).

[PhoneBoy]

Expert mode is a different beast for sure.

Legacy VSX was created before Linux had Namespaces support.
Not entirely clear to what extent it is being used, however.

Meanwhile, VSNext was designed with Linux Namespaces in mind.
Perhaps this applies in the Expert shell, but haven't seen myself.

[m1l0514v]

Dear friends, 

just very short update. 

The need for authenticated access to Gaia management we resolved by using RADIUS authentication.

[genisis__]

Are you able to share the solution as I suspect configuration on GAIA and ISE are needed.