TACACS+ Authentication not working with external group restriction

[lmsistemas]

I've set up TACACS+ on ISE and it's working fine, for both authentication and authorization, except that I can't get external group restriction to work.

I've tried this with LDAP authentication, by setting up an LDAP-based External Identity Source, with specific groups on the "Groups" tab. However, regardless of which groups were on this tab, any domain user could authenticate to the client device.

I've also tried it using Active Directory as External Identity Source, but then again, I can't try and restrict its group list, since it's a production environment and there are several AD groups which must be on this list (containing groups who must authenticate against our wireless controlers, for instance), not only the ones used for TACACS+.

So, what's the recommended way of setting up external groups restriction with TACACS+ ?

[kthiruve]

Hi Genesys,

You need to use the external group restriction in authorization policy by adding inline conditions to authorization attributes with external groups.

Authentication is a way of verifying user credentials and it does not matter what group you are in.

When you add groups in LDAP/AD to ISE, use these groups in the authorization condition in the authorization policy, it should work.

Thanks

Krishnan

[lmsistemas]

I do understand that I can restrict groups in the authorization policy, as I'm already doing so. The problem is: I don't wanna enable every user in my domain to log in to the routers/switches (even though they wouldn't be able to issue a single command due to authorization policies), simply because that could exhaust the 16 available VTY lines on a switch.

Isn't there any way to restrict external groups during authentication?

[paul]

There should be no VTYs eaten up with an unauthorized user logs in.  If you are seeing unwanted users getting to the CLI prompt then you either have AAA setup wrong on the device, authorization rules setup wrong in ISE or are running the version of ISE where the default rule at the bottom didn't quite work right (I think 2.0).

[lmsistemas]

Maybe I am misunderstanding the terms, but how can authorization prevent a user from getting to the CLI prompt, since this is controlled by authentication?

I just wanna clarify that I have no problem regarding group restriction at the commands authorization level. The only thing I'm having trouble with is restricting who is able to be authenticated (log in to the switch), according to a specific group list.

Do you have any idea of what exactly might be wrong with the AAA configuration? This is my configuration script:

conf t

aaa new-model

aaa authentication login default group tacacs+ local

aaa authentication enable default group tacacs+ enable

aaa authorization commands 1 default group tacacs+ local

aaa authorization commands 15 default group tacacs+ local

aaa accounting commands 1 default start-stop group tacacs+

aaa accounting commands 15 default start-stop group tacacs+

line vty 0 15

transport input ssh

exec-timeout 30 0

privilege level 15

logging synchronous

login authentication default

authorization commands 1 default

authorization commands 15 default

tacacs server ise01

address ipv4 1.1.1.1

key password

My ISE version is 2.0.1.130.

[paul · Accepted solution]

Authentication is there to answer the question "Did the user provide correct credentials?" That is the extent of authentication on most systems. Authorization determines what the user can do. The network device should be asking two questions upon initial connection. "Are these credentials correct?" (Authentication) "Can this user access the exec shell?" (Authorization). You are missing the config for the second question:

aaa athorization exec default group tacacs+ local

Sent from my iPhone

[lmsistemas]

Ah! Now I see it. I thought user access to the shell should be controlled at the authentication step, but it is bound to (exec) authorization instead.

The command "aaa authorization exec default group tacacs+ local" did the trick. Now the unauthorized user gets "authorization failed" and is disconnected right after being successfuly authenticated.

Thank you all for your time.

[hslai]

If this is for Cisco IOS network devices, it appears you are missing something like below:

aaa authorization exec CON none

aaa authorization console

aaa authorization exec VTY group tacacs+ local if-authenticated

line con 0

authorization exec CON

line vty 0 4

authorization exec VTY

We have some design guides @ Device Administration (TACACS+)

In case the network devices not honoring exec authorization, ISE 2.1 Patch 3+ and 2.2+ evaluates T+ authorization policy during T+ authentications. Since you have 2.0.1, please ask TAC to request the hot patch for CSCvf31398.

[paul]

If you can't apply hotfix for a whole you can autocomnand logout is work around.

Sent from my iPhone