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.

2561
Views
0
Helpful
13
Replies
arzillo
Beginner

ISE Authorization Condition to Match any Newly Created Endpoint

I am trying to create an authorization condition to match any newly created endpoint.  In other words, a condition to match a device the first time it is seen by ISE.

 

I thought using dictionary attribute ENDPOINTPURGE:ElapsedDays equals zero might be a good method but this attribute is not available to authorization conditions.  I then tried creating a custom dictionary using the same internal attribute name "ElasedDays".  This got around the restriction but the condition didn't work.

 

In any case, ElapsedDays = 0 really doesn't describe *only* the first time a device is seen by ISE.  It actually describes the entire first day after the endpoint is created.

 

Does anyone have any idea how this can be done?

 

Thanks!

 

13 REPLIES 13
Octavian Szolga
Participant

Hi,

Don't know why you'd want this :)
Still, if you need it for MAB (I assume this is the case) you could use (in an authorization policy) a rule saying "request = MAB + authentication failed (or not found - you have to check)

 

The 1st time you see a MAC it will match MAB 'continue' option for 'user not found'. (thus failed auth?)

 

The 2nd time you're seeing this device (not new anymore), it won't hit the 'continue' option from MAB authentication, because the endpoint already exists in ISE. 

 

Regards,

Octavian

Yes, this would be for Wired_MAB authentications using internal endpoints.

 

Authentication Policy Options:
If authentication failed: Reject (The Cisco doc isn't really clear how this applies to MAB)
If user not found: Continue
If process failed: Drop

 

Based on your suggestion, would the following compound authorization condition match a new endpoint?

 

NetworkAccess:AuthenticationMethod = Lookup

and

NetworkAccess:AuthenticationStatus = UnknownUser)

 

Thanks for your help!

 

RichardAtkin
Participant

Can you provide some context about why you want to do this?

We've found that some new devices do not get correctly profiled until they are granted some limited access to allow the profiling probes to gather all the data needed for an accurate profiler policy match.

 

We're looking for method to identify new Wired_MAB endpoints so we can apply a VLAN/DACL result that allows them to be correctly profiled.  The result has a 20-second RADIUS session expiration which will cause the device to re-auth and obtain the correct authorization policy the second time around.

 

We cannot use the default authorization policy since not all devices that reach this point are new devices.

What kind of limited access are you granting to these new devices to get the profiling data you need?

Well, so far we've identified that the following services are necessary for many devices to complete profiling and also to be in a state to accept a CoA on reauth.

 

DHCP, DNS, ICMP to GW, TFTP, AD

 

Not all are required for profiling but some devices will not successfully startup and recognize a CoA without some of them. The services are limited to specific servers. Everything else is denied. The session times out in 20 seconds.

 

Hi,

 

[qoute]

We cannot use the default authorization policy since not all devices that reach this point are new devices.

[/quote]

 

If the device is not new and it was already profile, it will not match this rule but a top rule.

I don't see any issue with having a default rule for MAB devices where you'd put a dACL with DNS/DHCP access.

 

Regards,

Octavian

If the device is not new and it was already profile, it will not match this rule but a top rule.

The assumption you're making is that all "not new" profiled MAB devices have an authorization rule. That isn't the case here, unfortunately. There will be unexpected MAB devices that have been successfully profiled that will reach the default authZ rule and will require a level of access different from a new device.

I don't see any issue with having a default rule for MAB devices where you'd put a dACL with DNS/DHCP access.

I've heard of this approach used elsewhere. For a variety of reasons we can't do that here. My original post asked for authZ condition attributes to match new MAB endpoints and the suggestion from your earlier post seemed like a good one. We'll do some testing to determine if the attributes I suggested above will work. If you're interested we'll post back our results.

 

Thanks again for your help Octavian!

Hi,

Now I understand your concern.

Please let me know if it worked.

 

Regards,

Octavian

Using Octavian's suggestion, we created a compound authorization condition with the following dictionary attributes:

 

NetworkAccess:AuthenticationMethod = Lookup
and
NetworkAccess:AuthenticationStatus = UnknownUser)

 

We tested this with a variety of devices that we often see as new endpoints. The condition correctly matched new MAB endpoints the first time they are seen.

 

Thank you very much for your help Octavian!

 

To be honest with you, I still don't get why you think your use case is different to anybody else who does profiling.  Why cant you create Authz rules for the various device types to grant them the access you want them to, then anything else (ie, new stuff not profiled yet) hits the default rule which grants enough access to allow profiling to take place.  Can you share a screenshot of your policies and some info about the devices you're connecting?

 

Also, the device its self doesn't need to know anything about CoA.  If it's having trouble with stuff like VLAN changes caused by CoA (which in its self is caused by the profiler deciding it now knows what something is), just bounce the switchport as part of the CoA action.


@RichardAtkin wrote:

To be honest with you, I still don't get why you think your use case is different to anybody else who does profiling.  Why cant you create Authz rules for the various device types to grant them the access you want them to, then anything else (ie, new stuff not profiled yet) hits the default rule which grants enough access to allow profiling to take place.  Can you share a screenshot of your policies and some info about the devices you're connecting?

I'm a bit of a newcomer to this community and this is my first thread. I realize that you are probably a subject matter expert here and I appreciate your input. However, the question I posed originally and as stated in the title is pretty straightforward: How to create an ISE authorization condition to match a newly created endpoint. I have supplied additional information in response to queries about why we need it and how we'll use it but at the end of the day it's still a straightforward question which could conceivably be found on a Cisco certification exam. I would be interested in your solution to the problem, if you have one.

 

I realize that my explanation of our particular profiling logic may have left you with questions. Our situation may not be unique but while there is always room for improvement our solution has worked well for us for several years. Perhaps a more complete explanation with screenshots would help but it was never my intention to get into a lengthy discussion about profiling logic designs.

 

Also, the device its self doesn't need to know anything about CoA.  If it's having trouble with stuff like VLAN changes caused by CoA (which in its self is caused by the profiler deciding it now knows what something is), just bounce the switchport as part of the CoA action.


You might want to think very carefully about using port bounce. Environments that use multi-auth, PoE or devices with built-in switches/hubs may present unexpected challenges with this approach.

Sorry - I seem to have up set you and I didn't mean to - I apologise.

 

There's clearly more going on than you have detailed (as there is with any ISE) and with such an unusual question I was (in fact, I am still) keen to understand more detail about the background to the question - why do you have the requirements you do - are they based on the needs of a policy, some technology, whatever...  You obviously don't want to share that information and that's fine.

 

Personally I'm not a massive fan of answering unusual questions without context.  It wouldn't have been the first time where somebody has asked a question without supplying a key bit of context, or worse still, asked the wrong question without even realising it.  I find that understanding the context of a question helps ensure the best answer is provided - that's all I was trying to do.

 

I'm glad you've got a solution that you're happy with.

 

Rich

Create
Recognize Your Peers
Content for Community-Ad

ISE Webinars



Did you miss a previous ISE webinar?

CiscoISE YouTube Channel