Security

Hello,

 

I'm trying ot figure out if there's something I'm missing in trying to use 

%{Radius:IETF:NAS-IP-Address} and

%{Radius:IETF:NAS-Port}

as criteria for an enforcement policy.

 

Basically, I've defined two additional attributes for the local user database:

SwitchIP

SwitchPort

This is so that our wired IP phones (which do EAP auth) can have a username and password created in the local user database, and be assigned attributes for the NAS-IP the request is coming from, as well as the NAS-Port.

 

The basic rationale for this is that if the phone is plugged in where it should be (ie SwitchIP matches %{Radius:IETF:NAS-IP-Address} and SwitchPort matches %{Radius:IETF:NAS-Port}, then the phone is assumed to be in the correct location and is allowed on the network.

 

The actual condition I have set up currently is:

(Authorization:[Local User Repository]:Role_Name  EQUALS  IPPhone) 
 AND  (LocalUser:SwitchIP  EQUALS  %{Radius:IETF:NAS-IP-Address})  AND  (LocalUser:SwitchPort  EQUALS  %{Radius:IETF:NAS-Port})

and it seems to be failing consistently, but I can't sort out what it doesn't like about the parameters. 

 

I've tried defining SwitchIP as an IPv4 address, string, and text, and I've tried defining SwitchPort as an interger, string, and text, none of which seem to be getting a match.

 

Is there something I'm missing in trying to define these parameters, or am I using the %{Radius:IETF:NAS-IP-Address} and %{Radius:IETF:NAS-Port} incorrectly, or do you know a way that I could test the parameters to see where the evaluation is failing?

 

I've had a look at the debug log for the authentication, but it's not shedding a whole lot of light.

 

The enforcement policy works if I don't using the new parameters (ie if I'm just checking against the role, so it's definitely something with the way I'm defining the new conditions.

 

I appreciate any help or pointers you can provide.

 

Andrew

 

You'd need to do this in role mapping.

 

Essentially:

LocalUser: SwitchIP    EQUALS   %{Radius:IETF:NAS-IP-Address}

AND

LocalUser:SwitchPort EQUALS %{Radius:IETF:NAS-Port}

 

Assign TIPS role/tag of something like "USER_NAS-MATCH"

 

Then use the tag in your enforcement policy.

Hi cappalli,

Thanks very much for the quick reply!

I've created a role mapping as suggested, and added it to the service:

And added that role as a condition for 

Though the authentication is still failing.

 

Is there somewhere you can think of that I can see which part of the match is failing, or if the role is even being applied correctly, or have I misunderstood how to apply this?

 

Thanks very much for your help!

 

Andrew

In access tracker, do you see the role being mapped? Can you click “Export” on the access tracker request and post here?

Hi cappalli,

 

It looks like the password for the local user got mixed up when I set the attributes in the local user the most recent time, so that was my first problem!

 

Now I'm seeing that the role mappings are being applied when I look at the authentication request in access tracker, but for some reason the default vlan is still getting applied. 

Am I referencing the roles correctly with this enforcement policy or do I need to be checking somewhere other than Authorization:[Local User Repository]:Role_Name?

 

I've attached the export of that authentication from Access Tracker if that helps.

 

Thanks very much for your help, I really appreciate it.

 

Andrew 

Sorry, figured out that I was trying to reference the roles incorrectly.

I should've been using the condition "TIPS Role EQUALS" instead of "Authorization:[Local User Repository] Role Contains".

Thanks so much for your help, it looks like it's working now!

Andrew