09-03-2019 04:25 AM
Hi All,
Our customer requires tacacs users to have an expiry date & time and for different ISE admins to create different types of tacacs users.
For this I have created sponsored guests users using the guest type Contractor group.
Now, if I use the network access name as that of the sponsored guest created, the tacacs rule works as required.
However, If I use the Identity group name Contractor, authorisation fails and it hits the default deny access shell profile.
Any idea how to get it working using the Identity Group name
Attached authorisation SS of both conditions.
PASSED LOG
Overview
|
Authorization Details
|
Authorization Attributes
|
TACACS Protocol
|
Other Attributes
|
FAILED LOG
Overview
|
Authentication Details
|
TACACS Protocol
|
Other Attributes
|
Attached logs for reference.
12-02-2019 05:06 PM
Hi @melvillec
Did you get a resolution to this? It's an interesting use case for sure!
When you create a Guest Type (e..g Contractor) then you specify where to put the MAC address by specifying the Endpoint Identity Group. Do not confuse this with the User Identity Group (Group that is defined and can contain user accounts ... NOT Endpoints (MAC addresses))
This means, that guest accounts do not have a concept of a Guest Group. At best, you could check during Authentication, by looking up the Identity Source Sequence of "Guest Users", and then test whether the authenticating user is found during Authentication.
12-02-2019 09:07 PM
Hi Arnie,
Thanks for your reply.
I still haven't got any resolution to this.
You are absolutely right as mentioned below that the Guest user identity group will not contain guest endpoint mac addresses, but only users accounts which we manually need to create. I had figured that out after testing.
If there was some way that ISE could store the guest user accounts created by the sponsor in an internal group, my use case would have been resolved.
I did however create a rule matching the guest user name in the TACACS authorization policy and it worked, but this is not feasible as customer will be creating random users due to which we cant go and make changes in the policy every time he creates an user.
Regards,
Melville
12-03-2019 03:45 AM
Depending on how complex your Policy Sets are, have you considered building a Policy Set that performs Authentication against the "Guest Users", and then for good measure, you could make that an Authorization Rule as well (just for extra assurance that you're authorizing for that specific reason).
12-03-2019 06:15 AM
Hi Arnie,
Thanks for your reply.
I was already using the Guest Users in the ISS.
Calling the Guest Users in the authorization policy will apply to all guest users and I will not be able to distinguish them as I need to create different policies for different tacacs users based on shell profiles and command sets.
Regards,
Melville
12-03-2019 09:33 AM
@melvillec wrote:
Hi Arnie,
Thanks for your reply.
I was already using the Guest Users in the ISS.
Calling the Guest Users in the authorization policy will apply to all guest users and I will not be able to distinguish them as I need to create different policies for different tacacs users based on shell profiles and command sets.
Regards,
Melville
Althought not a supported store to TACACS, perhaps this will help looking at the way we did it with Guest?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide