cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

539
Views
3
Helpful
4
Replies
Highlighted
Cisco Employee

How do I make an authorization decision based on the NAD ?

How can I create an authorization policy that uses the requesting NAD as  one of its conditions?

Example I only want to apply certain authorization profile results to a subset of switches.

Thanks!

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Contributor
Contributor

You can use the NAD name, group or IP address in an authorisation policy.

See the following for configuration details:

Cisco Identity Services Engine Administrator Guide, Release 2.3 - Configure and Manage Policies [Cisco Identity Service…

View solution in original post

4 REPLIES 4
Highlighted
Enthusiast

Hi there.

This is my first time answering a technical question … I’m eager to get feedback from the TMEs here at Cisco and make sure this is the best approach ☺

Authorization rules are created as one of three parts of a network access policy set in the new Policy Set paradigm. Each unique policy set includes a top level that determines conditions for the resulting configured allowed protocol, and then within that set, the authentication and authorization rules. Therefore, in order to create an authorization rule (formerly an authorization policy), you must create a new relevant policy set or edit an existing, relevant set to include the authorization rules (conditions and resulting authorization profiles and security groups) that you need.

You can use device and switches as the conditions for the results of any of the three parts of a set (again: allowed protocols, authentication and authorization). In addition, from the Conditions Studio you’ll find pre-defined building blocks for a variety of switch/protocol types.

For the general example you describe below (apply an authorization rule for a subset of switches) I would guess it’s best to configure the parent NAD types on the top level of the set – for the allowed protocols rule. If the wrong parent NAD is the origin of the request then automatically the request will fail from the top level and move to the next policy set for checks without drilling down for the inner checks.

Once you create a set with the parent NAD types as the condition on the top level, you then also have full flexibility in creating multiple (authentication and) authorization rules for the different subsets of switches.

In this way, if a request is accepted from any of the parent NAD types in your conditions on the top level of the policy set, only then are the users are authenticated based on any rules you configured. Thereafter, the authorization rules you created for different switch types are evaluated.

1. From Policy=>Policy Sets, create a unique policy set for this use case or locate the existing set that you’d like to update.

2. On the top level, configure the condition for this set, including the parent NAD types from which requests are to be accepted and the resulting allowed protocols.

The configured allowed NAD types are allowed access to the network based on supported protocols.

3. Save the policy set and click View.

4. From the inner level of the policy set, create any relevant authentication rules, if any, or leave the default authentication rules, which allows access to all registered users.

5. Configure separate authorization rules for the different groups of switches based on your use case.

The new policy set paradigm has also been fully documented in the admin guide:

https://www.cisco.com/c/en/us/td/docs/security/ise/2-2/admin_guide/b_ise_admin_guide_23/b_ise_admin_guide_23_new_chapter_010010.html

Rachel Cheyfitz

WRITER.TECHNICAL

rcheyfit@cisco.com<mailto:rcheyfit@cisco.com>

Phone: +972 9 892 7012

Cisco.com<http://www.cisco.com/>

Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.

Rachel Cheyfitz
WRITER.TECHNICAL
rcheyfit@cisco.com
Tel: +972 9 892 7012
Highlighted

Thanks Rachel, what I am hoping for is an example of how to do this. What is the condition I would use to identify the NAD ?

Highlighted

dmh is correct. Network Device Groups are most commonly used as conditions for NADs as they group the devices nicely. For example, we may put NADs into device types of wired, wireless, and VPN or into vendors of Cisco and non-Cisco, then we may use either device types or vendor info as conditions.

Rachel is also correct that Network Device Groups are commonly used to separate policy sets so that the authentication and authorization polices are nicely grouped together. tiabbott has a nice video at What's New in ISE 2.3? to demonstrate that.

Highlighted
Contributor
Contributor

You can use the NAD name, group or IP address in an authorisation policy.

See the following for configuration details:

Cisco Identity Services Engine Administrator Guide, Release 2.3 - Configure and Manage Policies [Cisco Identity Service…

View solution in original post