Cisco VSA for dACL

[Matthew Martin]

Hello All,

We've recently just moved to Windows NPS (*from ISE... sad face...) and I'm trying to include a Vendor Specific Attribute to push an ACL name using "Cisco-AV-Pair" attribute.

I was able to successfully push "Cisco-AV-Pair" to desk phone clients for the attribute "device-traffic-class=voice" to get the phones on the Voice Vlan.

So now I'm trying to push a ACL/dACL to certain clients matching a policy. I believe I know the format of how to push the attribute value from the link I found below and by looking at the attributes pushed from ISE to clients... All except for the portion that says it's for the version number (*see screenshot below)...?
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_8021x/configuration/15-mt/sec-user-8021x-15-mt-book/sec-ieee-802x-acl-assign.pdf

So if my ACL name that I have configured on the Switch is called "INTERNET_ONLY", I believe I would format it like so:
CiscoSecure-Defined-ACL=#ACSACL#-IP-INTERNET_ONLY-<?number?>

Looking through the authentication results section under ISE's Context Visibility for one of the endpoints. I can see in the ACL that is pushed had the number "56161e32". But how is this version number determined?

Any help would be greatly appreciated!

Thanks in Advance,
Matt

[Arne Bier]

Great question - I have never thought about how this works. I don't have access to my lab at the moment ... I'll take a look later.

I have a suspicion that this is an encoded representation of the endpoint's MAC address, since this is all we can be sure about. Do any of the hex octets from your examples contain part of the endpoint's MAC address?  Or a combination it (similar to the EUI-64 encoding used in IPv6 link local addressing with EUI-64)

[ahollifield]

Ouch... talk about a step backwards.  Do you still have ISE in play here?  (if not use one of the dCloud labs) I would do a packet capture on the ISE node when the dACL is sent and see exactly what is being sent via RADIUS and replicate that on NPS (not sure if versioning has any significance or not.  Aruba ClearPass supports dACLs so its nothing proprietary.  

[Matthew Martin]

Hey Guys, thanks for the reply.

Yea, wasn't too happy about them deciding to move away from ISE... Unfortunately, I don't make those decisions.

Yes, ISE is still in play, but all the licenses have expired. But, can still access the GUI and check on most things.

In regards to it being something related to encoded Mac Address. I was thinking the same, it being something unique for each auth sess. But, I just checked on the switch and I'm seeing the same number in the dACL field from the "show auth sess" command, i.e. 56161e32, for every device that is connecting via mab.

What I did get to work was pushing a per-user ACL (*I think that's what they're called) by pushing this from the RADIUS NPS server:

Feb  7 15:40:11.869 EST: RADIUS:  Vendor, Cisco       [26]  34
Feb  7 15:40:11.869 EST: RADIUS:   Cisco AVpair       [1]   28  "device-traffic-class=voice"
Feb  7 15:40:11.869 EST: RADIUS:  Vendor, Cisco       [26]  54
Feb  7 15:40:11.869 EST: RADIUS:   Cisco AVpair       [1]   48  "ip:inacl#1=deny ip any 192.168.0.0 0.0.255.255"
Feb  7 15:40:11.877 EST: RADIUS:  Vendor, Cisco       [26]  53
Feb  7 15:40:11.877 EST: RADIUS:   Cisco AVpair       [1]   47  "ip:inacl#1=deny ip any 10.0.0.0 0.255.255.255"
Feb  7 15:40:11.877 EST: RADIUS:  Vendor, Cisco       [26]  54
Feb  7 15:40:11.877 EST: RADIUS:   Cisco AVpair       [1]   48  "ip:inacl#1=deny ip any 172.0.0.0 0.255.255.255"
Feb  7 15:40:11.877 EST: RADIUS:  Vendor, Cisco       [26]  36
Feb  7 15:40:11.877 EST: RADIUS:   Cisco AVpair       [1]   30  "ip:inacl#1=permit ip any any"

 I have some more info to share but running out of time here in the office. So I'll post that tomorrow

Thanks again for the replies. Much appreciated.

-Matt

[Arne Bier]

ok one thing is certain - the hex strings have no relationship to the endpoint's MAC address.  If there are multiple endpoints on that switch that get the same dACL, then the dACL that is applied to all of the endpoints is always the same. So it appears that this suffix has to do with the dACL itself, and not with the endpoint(s) on which it is applied.

I think this is just an arbitrary number that the RADIUS server generates. The RADIUS server can't possibly know about the internals of the NAD to relate this to anything specific in the NAD. It's possible that the resultant dACL name that RADIUS sends to the NAD will be unique, since the combination of name and "random" version number should create uniqueness.  Perhaps the RADIUS server can reject that in the event of a collision.

Since you're doing this in NPS, I don't suppose you can construct a dynamic RADIUS attribute that has the format 
CiscoSecure-Defined-ACL=#ACSACL#-IP-INTERNET_ONLY-{6 random hex digits}  ?

[Matthew Martin]

Looks like I was wrong about the ACL I was pushing. It's not working... Just noticed the ACL that's actually being applied here is the "Auth-Defaul-ACL". According to the output from "show ip interface" command.

FastEthernet0/7 is up, line protocol is up
Inbound access list is Auth-Default-ACL

Looking at the debugs on the switch. For the auth occurring when ISE is RADIUS server. The flow appears like the following:

       SEND --> Access-Request
RECEIVED --> Access-Accept
*Receives in Cisco-AV-Pair VSA attribute the device-traffic-class, the profile-name ISE put the device in, and the ACL name.

*Jan 25 17:14:38.489 EST: RADIUS:  Vendor, Cisco       [26]  34
*Jan 25 17:14:38.489 EST: RADIUS:   Cisco AVpair       [1]   28  "device-traffic-class=voice"
*Jan 25 17:14:38.489 EST: RADIUS:  Vendor, Cisco       [26]  75
*Jan 25 17:14:38.489 EST: RADIUS:   Cisco AVpair       [1]   69  "ACS:CiscoSecure-Defined-ACL=#ACSACL#-IP-PERMIT_ALL_TRAFFIC-56161e32"
*Jan 25 17:14:38.489 EST: RADIUS:  Vendor, Cisco       [26]  33
*Jan 25 17:14:38.489 EST: RADIUS:   Cisco AVpair       [1]   27  "profile-name=Teams_Phones"
*Jan 25 17:14:38.489 EST: RADIUS(00000000): Received from id 1645/194
*Jan 25 17:14:38.489 EST: RADIUS/DECODE: parse unknown cisco vsa "profile-name" - IGNORE
*Jan 25 17:14:38.497 EST: %EPM-6-POLICY_REQ: IP 0.0.0.0| MAC <endpoint-mac>| AuditSessionID 0A0A0A010000007A7B38114D| EVENT APPLY
*Jan 25 17:14:38.497 EST: %EPM-6-AAA: POLICY xACSACLx-IP-PERMIT_ALL_TRAFFIC-56161e32| EVENT DOWNLOAD_REQUEST

        SEND --> Access-Request
             *sends another access-request, inserting the dACL name as the Username

*Jan 25 17:14:38.506 EST: RADIUS(00000000): Send Access-Request to <ise-ip-addr>:1812 onvrf(0) id 1645/195, len 147
*Jan 25 17:14:38.506 EST: RADIUS:  authenticator **************************
*Jan 25 17:14:38.506 EST: RADIUS:  NAS-IP-Address      [4]   6   192.168.*.**
*Jan 25 17:14:38.506 EST: RADIUS:  User-Name           [1]   41  "#ACSACL#-IP-PERMIT_ALL_TRAFFIC-56161e32"
*Jan 25 17:14:38.506 EST: RADIUS:  Vendor, Cisco       [26]  32
*Jan 25 17:14:38.506 EST: RADIUS:   Cisco AVpair       [1]   26  "aaa:service=ip_admission"
*Jan 25 17:14:38.506 EST: RADIUS:  Vendor, Cisco       [26]  30
*Jan 25 17:14:38.506 EST: RADIUS:   Cisco AVpair       [1]   24  "aaa:event=acl-download"
*Jan 25 17:14:38.506 EST: RADIUS:  Message-Authenticato[80]  18

RECEIVED --> Access-Accept
*The device then receives another access-accept with the ACL as Username, a couple of other attributes I'm not sure about, and then the actual line(s) of the dACL named "PERMIT_ALL_TRAFFIC" that's defined in ISE.

*Jan 25 17:14:38.506 EST: %EPM-6-POLICY_REQ: IP 0.0.0.0| MAC <endpoint-mac>| AuditSessionID 0A0A0A010000007A7B38114D| EVENT APPLY
*Jan 25 17:14:38.506 EST: %EPM-6-AUTH_ACL: POLICY Auth-Default-ACL| EVENT ATTACH-SUCCESS
*Jan 25 17:14:38.522 EST: RADIUS: Received from id 1645/195 <ise-ip-addr>:1812, Access-Accept, len 203
*Jan 25 17:14:38.522 EST: RADIUS:  authenticator *****************************
*Jan 25 17:14:38.522 EST: RADIUS:  User-Name           [1]   41  "#ACSACL#-IP-PERMIT_ALL_TRAFFIC-56161e32"
*Jan 25 17:14:38.522 EST: RADIUS:  Class               [25]  88
*Jan 25 17:14:38.522 EST: RADIUS:   43 41 43 53 3A 63 30 61 38 30 32 33 31 5F 55 42  [CACS:c0a80231_UB]
*Jan 25 17:14:38.522 EST: RADIUS:   7A 41 6E 79 4E 30 4F 5F 4B 72 6B 48 64 7A 4F 50  [zAnyN0O_KrkHdzOP]
*Jan 25 17:14:38.522 EST: RADIUS:   5F 31 5F 6F 62 33 7A 69 54 53 7A 33 4D 33 4A 47  [_1_ob3ziTSz3M3JG]
*Jan 25 17:14:38.522 EST: RADIUS:   77 37 62 32 59 5F 4F 6F 3A 49 53 45 2D 45 78 74  [w7b2Y_Oo:ISE-HQ]
*Jan 25 17:14:38.522 EST: RADIUS:   6F 6E 32 2F 34 37 38 35 30 33 33 35 35 2F 32 39  [-2/478503355/29]
*Jan 25 17:14:38.522 EST: RADIUS:   35 37 35 30 30 35            [ 575005]
*Jan 25 17:14:38.522 EST: RADIUS:  Message-Authenticato[80]  18
*Jan 25 17:14:38.522 EST: RADIUS:   F1 31 F5 57 03 47 3F 25 A0 14 31 90 60 7F 6D DD          [ 1WG??1`m]
*Jan 25 17:14:38.522 EST: RADIUS:  Vendor, Cisco       [26]  36
*Jan 25 17:14:38.522 EST: RADIUS:   Cisco AVpair       [1]   30  "ip:inacl#1=permit ip any any"
*Jan 25 17:14:38.522 EST: RADIUS(00000000): Received from id 1645/195
*Jan 25 17:14:38.522 EST: %EPM-6-AAA: POLICY xACSACLx-IP-PERMIT_ALL_TRAFFIC-56161e32| EVENT DOWNLOAD-SUCCESS
*Jan 25 17:14:38.548 EST: %EPM-6-IPEVENT: IP 0.0.0.0| MAC <endpoint-mac>| AuditSessionID 0A0A0A010000007A7B38114D| EVENT IP-WAIT

From this, not sure if it matters. But, RADIUS replies with the dACL name for the client first. The Client then sends another Access-Request using the dACL name as it's username and RADIUS replies with the lines/contents on the dACL.

Still trying out a couple of different configurations on NPS too. Will comment back once I've tried some more tests...

-Matt

[Matthew Martin · Accepted solution]

I think I've got this working.

To get this to work I had to use 2 separate "Connection Request Policies".

The first one (*Phase 1) matches the connection request using the following and sets the following Settings:

---- CONDITIONS ----
NAS Port Type = "Ethernet"
Calling Station ID = <List of MacAddresses,REGEX,etc>
---- SETTINGS ----
Authentication = Accept users without validating credentials
Vendor Specific (Cisco-AV-Pair)
     device-traffic-class=voice
     ACS:CiscoSecure-Defined-ACL=#ACSACL#-IP-INTERNET_ONLY

I believe by sending the dACL name in the initial connection request's response, when the endpoint responds back it'll send the attribute below, which tells the RADIUS to send the dACL to the client to download it:

Cisco AVpair       [1]   24  "aaa:event=acl-download"

The second one (*Phase 2), the NPS Server receives back from the endpoint device the name of the dACL sent in the initial response. So we now need to match on that using "User Name":

---- CONDITIONS ----
User Name = ".*INTERNET_ONLY.*"
*I will be adding more conditions to make more secure after done testing...
---- SETTINGS ----
Authentication = Accept users without validating credentials
Vendor Specific (Cisco-AV-Pair)
     ip:inacl#1=permit udp any eq bootpc any eq bootps
     ip:inacl#2=permit udp any any eq domain
     ip:inacl#3=deny ip any 10.0.0.0 0.255.255.255
     ip:inacl#4=deny ip any 192.168.0.0 0.0.255.255
     ip:inacl#5=deny ip any 172.0.0.0 0.255.255.255
     ip:inacl#6=permit ip any any

I discovered that the numerical value that ISE was putting at the end of the ACL doesn't appear to matter. I just left that portion off.
It must be something to do with accounting/logging on the RADIUS server side. I'm guessing ISE uses that number for some purpose...

Thanks for the replies. Much appreciated!

-Matt

[ahollifield]

Clear text protocols FTW!

[Matthew Martin]

That's for sure...

On the switch side the debug radius logs were extremely helpful:

#sh debugg
Radius protocol debugging is on
Radius protocol verbose debugging is on
Radius packet protocol debugging is on