ISE 2.0 - Wildcard MAB?

[craig.cartlidge1]

Hi, 

Are we able to create wildcard entries in the MAB in ISE 2.0 for devices that do not support 802.1x

We have a large number of Mitel phones - (I am unsure if we can place certificates onto these) are we not able to just allow all mitel devices in the MAB via the OUI prefix of the MAC address??

Thanks 

[Rahul Govindan]

This is possible. I have used it in the past with Avaya phones and MAB, I don't recall the exact parameter I used but i created a custom condition similar to "username starts with <OUI>". This matched any of the Avaya phones. You might have to look at the authentication detail to find the exact parameter.

Also, I combined it with a profiling policy for Avaya phone so that the MAC OUI condition is used for the first time before profiling kicks in. Future sessions used the profiling info to authorize then user. If Mitel devices do not show up in the profiling profile, you can create a custom one using the MAC OUI for these phones.

[craig.cartlidge1]

Thanks so this sounds possible - Do I need the profiling licence as we only have the Base licence at the moment?

I am trying to find a condition for OUI or MAC and cant seem to find one, we are on ISE 2.0

[Rahul Govindan]

Profiling requires the plus license. Each session that uses an authorization policy containing a profiling condition counts as one license count.

For the condition: when mab is used, the Mac address is passed as username. You can use a simple condition saying username starts with Mac oui. To get the exact format that the username shows, try a test connection with a mitel phone and click on authentication details under the radius live logs. This will give you the attributes sent during a session.

[Rahul Govindan]

I went back and checked my notes. Here is the condition I used for a MAC of B4-B0-17-34-56-EF:

"Radius:User-Name" Starts with “b4b017" .

Looks like Radius access request sends the username in the format “b4b0173456ef” while radius accounting request sends it in the format “B4-B0-17-34-56-EF”. Using the first condition worked for me.

[craig.cartlidge1]

Hi,

I have created a condition as you said, but authentication still seems to be failing. The authentication report says because it cannot find the device in the 'internal-endpoints-identitystore'   - How do I get The Mitel Phones into the internal-endpoints store without manually adding them in?

[Rahul Govindan]

What you are seeing is in the authentication phase, while the Mitel OUI is validated in authorization phase.

The MAC address of any device that the ISE learns is put into the internal-endpoints store. But this happens only after the first connection. In order to complete authentication, you have to allow user not found to continue to authorization. The setting should be under the Default section of Authentication policies. I have attached a screenshot from my ISE on this setting.

[craig.cartlidge1]

Hi Please see my attached Configs,

Is something wrong with the auth policy?

[Rahul Govindan]

Ok looks like it is matching the default rule, and falling through to the Authorization policy since it is set to continue.

One problem is the format of the condition. You should have condition as username starts with "08000f" instead of "08:00:0F". If you look at the authentication attributes, you should see one for Radius username. Try changing the condition to the above format and test. If it still fails, collect the full failure report and attach it.

[craig.cartlidge1]

Hi Thanks for this,

However, the format of the condition does not have any colons : as the delimiter - I went and checked - but in the authorize policy it seems to show the condition with a colon delimiter ... Im not sure why this is? - However I tested again and still failing.

I have attached the full auth report

[Rahul Govindan · Accepted solution]

From my earlier testing, the "original username" is what was actually sent by the switch to ISE. One way to confirm is by running a "debug radius all" on the switch to see what the actual parameter looks like.

Regarding the condition, you should have the Authorization condition changed, not authentication one.

[craig.cartlidge1]

Thanks!!!!

This is now working, I had created 2 conditions in my testing and had forgotten to delete one - once for authenticate and one for authorize.

I was looking at the authenticate condition and removing the delimiters from that one as opposed to the authorize condition.

As soon as I remove the colons from the authorize condition it worked!

Thanks!

[Rahul Govindan]

Great !! Glad to hear its working.

[ChristianBur]

I use this for mac ec8e.b567.d0c0

Authentication Policy

TEST1: if  RADIUS:Calling-Station-ID STARTS WITH ec:8e:b5  (type MAC adress) use Internal Endpoints

Authorization Policy

TEST1: if RADIUS:Calling-Station-ID STARTS WITH ec:8e:b5  (type MAC adress) then Permit Access

[SaibDroubi]

Thanks a lot, it was helpful and solved our issue.