TACACS+ RBA on GAiA

[Udupi_krishna]

I have been researching about how TACACS+ works on GAiA for the past 4 to 5 hours and I have come to a conclusion that either I am confused or my understanding was wrong all these years.

I have a setup with few CP firewalls trying to authenticate using TACACS+ running on ACS 5.X. The configuration is fine on both devices, in fact I am able to authenticate to the boxes as well. If I need to escalate my privilege, i am supposed to be using tacacs_enable TACP-N (15 in my case). Then I have RBA roles configuration related to TACP-15 on the Checkpoint firewalls which allows me to perform certain actions.

Here comes my million dollar doubt, In a typical environment we might have read-only and read-write user on ACS/external authentication server. R77.X documentation about TACACS+ highlights the following statement "Gaia supports TACACS+ for authentication only. Challenge-response authentication, such as S/Key, is not supported."

So in a scenario where a read-only User according to my ACS authenticates to Checkpoint and uses TACP-15 with his enable password he/she gets complete privilege. Logically speaking just beats the purpose of access control, unless my understanding here is wrong.

In addition to this, R77.X guide also says the following - "When a non-local user logs in to Gaia, the TACACS server authenticates the user and assigns the permissions to the user. You must configure the TACACS server to correctly authenticate and authorize non-local Gaia users."

These statements are contradicting in its own way unless there are attributes which can used on ACS which can control the Authorization as well.

[Maarten_Sjouw]

For the authorization you use the TACP-N key you create a RBA role:

add rba role TACP-15 domain-type System all-features

now with the following command you can remove specific commands from the list of available commands, using the tab key you will see the full list of options:

delete rba role TACP-0 readwrite-features <features to be removed>

You can create multiple TACP-N RBA roles with different functionality, but I don't think you will be able to elevate yourself from one rba role to anther, there is no enable option.

[Udupi_krishna]

The R77.X documentation confirms that all TACACS users are by default in TACP-0. So if I am executing tacacs_enable TACP-15 the user is indeed jumping from 0 to 15.

Now my question is from the perspective of how read-write and read-only authorization can be controlled from TACACS server if it's only possible. For e.g., I have few Palo Alto firewalls where I use attribute values of auth profiles setup on the firewalls in TACACS to ensure read-only users in TACACS cannot have any additional privilege.

But in case of a Checkpoint firewall, if a read-only based user access firewall, he/she can just go into TACP-15 because there aren't any such attribute values which is setup on TACACS server.

[Maarten_Sjouw]

You will have to create a RBA role for TACP-15 as well and remove the features you don't want a user to have in that role.

[Udupi_krishna]

Sorry about the late reply, been away for a while. 

After going through couple of other posts and documentation, understand that I cannot use TACACS+ to run central authorization for non-local users which is what I was trying to acheive. It supports only authentication since there are no such VSAs supported by Checkpoint to map a RBA role.

In a way the above limitation beats the purpose of using TACACS.

On the other hand RADIUS does support central authorization for non-local users.

[Jean-Christoph1]

Hi,

Answer is a little bit late, but anyway, TACACS+ with Gaia support Authentication & Authorization.

Gaia uses shell/exec service and read for priv-lvl value to authorize user.

Basically, this configuration allow users to enable to level 15:

user = jcvaliere {
    login = mavis # LDAP
    pap = login # Clone login
    enable = login # Clone login
    default service = permit
    ###Service AdminAuthorizationSVC START###
###MANUAL CONFIGURATION START###
    service = shell {
        default command = permit
        default attribute = permit
        set priv-lvl = 15
        set shell:roles = "\"network-admin\""
    }
    service = ciscowlc {
        set role1 = ALL
    }
    service = ppp {
        protocol = ip { }
        set F5-LTM-User-Info-1 = NetworkAdmin
        set F5-LTM-User-Console = 1
        set F5-LTM-User-Role = 0
        set F5-LTM-User-Partition = all
    }
    service = fmg {
    }
    service = fortigate {
        set memberof = TacacsNetworkAdminGroup
        set admin_prof = super_admin
    }
    opap = login
###MANUAL CONFIGURATION END###
    ###Service AdminAuthorizationSVC END###
  } #END OF jcvaliere

 While, this configuration allow users to enable to leve 7:

  user = izanine {
    login = mavis # LDAP
    pap = login # Clone login
    enable = login # Clone login
    default service = permit
    ###Service OperatorAuthorizationSVC START###
###MANUAL CONFIGURATION START###
    enable = deny
    service = shell {
        default command = permit
        default attribute = permit
        set priv-lvl = 7
        set shell:roles = "\"network-operator\""
        cmd = show {
            permit .*
        }
        cmd = configure {
            deny .*
        }
    }
    service = ciscowlc {
        set role1 = WLAN
        set role2 = WIRELESS
    }
    service = ppp {
        protocol = ip { }
        set F5-LTM-User-Info-1 = NetworkOperator
        set F5-LTM-User-Console = 0
        set F5-LTM-User-Role = 400
        set F5-LTM-User-Partition = all
    }
    service = fmg {
    }
    service = fortigate {
        set memberof = TacacsNetworkOperatorGroup
        set admin_prof = read_only
    }
    opap = login
###MANUAL CONFIGURATION END###
    ###Service OperatorAuthorizationSVC END###
  } #END OF izanine

Below is the result:

Users with priv-lvl = 15:

login as: jcvaliere
This system is for authorized use only.
jcvaliere@172.16.68.4's password:
Last login: Thu Jun 6 16:51:43 2019 from valiere.bcp-bank.com
CLINFR0771 Config lock is owned by admin. Use the command 'lock database override' to acquire the lock.
FONCPFW02:TACP-0> tac
FONCPFW02:TACP-0> tacacs_enable

TACP-0 TACP-7 TACP-15
FONCPFW02:TACP-0> tacacs_enable TACP-15
CLINFR0519 Configuration lock present. Can not execute this command. To acquire the lock use the command 'lock database override'.
FONCPFW02:TACP-0> lock database override
FONCPFW02:TACP-0> tacacs_enable TACP-15
Enable password:
CLINFR0771 Config lock is owned by admin. Use the command 'lock database override' to acquire the lock.
FONCPFW02:TACP-15>

Users with priv-lvl = 7:

login as: izanine
This system is for authorized use only.
izanine@172.16.68.4's password:
Last login: Thu Jun 6 16:36:02 2019 from valiere.bcp-bank.com
FONCPFW02:TACP-0> tacacs
FONCPFW02:TACP-0> tacacs_enable

TACP-0 TACP-7 TACP-15
FONCPFW02:TACP-0> tacacs_enable TACP-15
Enable password:
Authentication failure: check your username and password
FONCPFW02:TACP-0> tacacs_enable TACP-7
Enable password:
CLINFR0771 Config lock is owned by admin. Use the command 'lock database override' to acquire the lock.
FONCPFW02:TACP-7>

Cheers,

Jean-Christophe

[Martin_Orlich]

Hi,

I am trying to implement TACACS for authentication and I configured TACACS+ group and authorization rule the same way as @Jean-Christoph1

group = 1_test_orlich {
#### LDAP Groups List #### DistinguishedName ###
### cn=tg_orlich_test,cn=groups,cn=compat,dc=tg,dc=cz,dc=net ###
default service = permit
###Service checkpoint_shell_ro START###
###MANUAL CONFIGURATION START###
enable = deny
service = shell {
default command = permit
default attribute = permit
set priv-lvl = 7
set shell:roles = "\"network-operator\""
cmd = show {
permit .*
}
cmd = configure {
deny .*
}
}
###MANUAL CONFIGURATION END###
###Service checkpoint_shell_ro END###
} #END OF 1_test_orlich

-----------------------------------------------------------------------
However, I am able to log into elevated level - TACP-15.

Using username "orlich".
Pre-authentication banner message from server:
| This system is for authorized use only!
End of banner message from server
Last login: Wed Apr 8 11:28:14 2020 from 193.86.28.225
Welcome and be careful.
CP-FW01:TACP-0> tacacs_enable TACP-15
Enable password:
Authentication failure: check your username and password
CP-FW01:TACP-0> tacacs_enable TACP-15
Enable password:
CLINFR0771 Config lock is owned by admin. Use the command 'lock database override' to acquire the lock.

CP-FW01:TACP-15> show rba role

NOC TACP-0 TACP-7 TACP-15 adminRole cloningAdminRole monitorRole
CP-FW01:TACP-15>

---------------
Sometime the 1st attempt is failing, but on next one I am authenticated to TACP-15. On TACACS+ server as enable password is configured login password globally.

I am not sure about: set shell:roles = "\"network-operator\""

Is this general Checkpoint configuration or is this related to the deployment ?

Thank you for reply.
BR Martin

[nohejlt]

Hi,

Jean-Christoph used tacacsgui which is using tac_plus distribution by http://www.pro-bono-publico.de/projects/tac_plus.html.

Using local users as described by Jean-Christoph is working.

But in case you will use MAVIS module to connect to LDAP user backend, the privilege level escalation will accidently work for all users with default settings.

The reason is, that in case of TACACS, checkpoint is not using the real authorization (sending the name of role for the user by AV pair). The authorization is working only with RADIUS. It is confusing, because TACACS was originally developed for that purpose. In oppose, RADIUS was originally developed for remote user dial-in authentication like RA VPN, WiFi etc.

Solution, in case of tacacsgui is to disable the option "enable password as login" in Mavis module ->  Mavis LDAP and for user who needs for example access escalation to enable 7 use manual settings on user-group in tacacsgui bellow:

enable 7 =login

enable 15=deny

For user, who need access escalation to enable 15, just use manual settings on user-group in tacacs gui like:

enable 15=login

I have setted up several technologies with tacacsgui like Aruba Instant, Aruba Airwave, ArubaOS, Cisco, FortiOS, OneAccess, Linksys... All of them supports the true TACACS autorization. Checkpoint NOT - WTF?!

The other thing which is not properly done in GAIA is the fact, that in case the user has no service in TACACS defined like:

service = shell {

  ....

}

The user is allowed to log in!

Regards

Tomas

[S_E_]

---

@nohejlt wrote:

The reason is, that in case of TACACS, checkpoint is not using the real authorization (sending the name of role for the user by AV pair). The authorization is working only with RADIUS.

....The other thing which is not properly done in GAIA is the fact, that in case the user has no service in TACACS defined like:

service = shell {

---

Hi,

Did you ever raise a RFC or talked to R&D team ? Any 'official feedback' from CheckPoint ?

Could not found anything interesting or relevant in R80.40/R81ea release notes.

Thanks,

Regards

[nohejlt]

Hi S_E_,

No, I didn't raise a RFC nor talked to R&D. I am not the checkpoint guy, I even don't have checkpoint account. I was involved in troubleshooting why the admin users are not properly authorized by our TACACS implementation after logging in checkpoint GUI/CLI.

My experience with speed of implementing new features by HW vendors is bad, mostly the effort given to describe the feature and give  arguments to justify the need of the new feature is too inacceptable for me. 

My opinion is, that the properly implemented TACACS authorization should be the basic and common feature especially for security product. 

The only purpose of my comment to this thread was to share the results of my troubleshooting.

Regards

Tomas