ISE Inbuilt Authz Profile PermitAccess not working on WS-C3750V IBNSv1

[clive.fulton]

I had an interesting case, where when applying the inbuilt ISE AuthZ profile PermitAccess on a

WS-C3750V2-24PS and WS-C3560C-12PC-S both running 15.0(2)SE11 and IBNSv1

Although ISE authenticated and authorised the endpoints, as a result using the in built PermitAccess AuthZ policy - and the endpoints showed authorised on the switch

mps-30-sw1#sho authentication sessions int f1/0/1
Interface: FastEthernet1/0/1
MAC Address: 0090.e821.7123
IP Address: 10.43.95.240
User-Name: 00-90-E8-21-71-23
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-auth
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
Session timeout: 5400s (local), Remaining: 5392s
Timeout action: Reauthenticate
Idle timeout: 180s (local), Remaining: 172s
Common Session ID: 0A2BF02E00000670B43ABA30
Acct Session ID: 0x0000081D
Handle: 0xFE000671

Runnable methods list:
Method State
dot1x Failed over
mab Authc Success

mps-30-sw1#ping 10.43.95.240
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.43.95.240, timeout is 2 seconds:
.....

The endpoints that were connected to the switch lost access to the network

On another 3850 switch running 16.9.12, but was running IBNSv2 - and using the same policy in ISE with the authz profile PermitAccess resulted in the the endpoint having access.

When troubleshooting this, I noticed that by putting a permit icmp in the DEFAULT-ACL, I was able to ping the device.

I then create a authz profile that pushed a DACL called DEFAULT-PERMIT to permit any, 

When I forced CoA, a DACL was pushed to the switch on this endpoint, and it then received network access.

My Question is, is this expected behaviour on switches running IBNSv1, or perhaps an issue with the image 15.0(2)SE11

[Arne Bier]

I don't believe this is an IBNS 1.0 thing. 

What does the show running interface of the IBNS 1.0 look like? Maybe you had a pre-auth ACL in the config?

[clive.fulton]

I have a DEFAULT-ACL on each interface that permits access to DHCP and DNS

Extended IP access list DEFAULT-ACL
10 permit udp any any eq domain
20 permit tcp any any eq domain
30 permit udp any eq bootps any
40 permit udp any any eq bootpc
50 permit udp any eq bootpc any (17 matches)
70 deny ip any any (3 matches)

interface FastEthernet1/0/1
description Moxa Serial Server
switchport access vlan 240
switchport mode access
switchport voice vlan 651
ip access-group DEFAULT-ACL in
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
authentication event fail action next-method
authentication event server dead action authorize vlan 240
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer restart 3600
authentication timer reauthenticate 5400
authentication timer inactivity 180
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast
spanning-tree bpduguard enable
service-policy input PM-SET-DSCP
end

I have the same configuration on a 3850 switch running 16.12.09 and configured to used IBNSv2

This also has the same device type connected to one of the ports, and uses the same Authorisation Profile

The only difference is that the end points did not lose access to the network on this switch, but they did on the 3750 running 15.0(2)SE11 and IBNSv1

On the attached JPG, 2 switches MPS-29-SW1, and MPS-30-SW1 that had the incident were both 3560C and 3750C, both running IBNSv1 on 15.0(2)SE11.    MPS08PPESW01 is a 3850 running 16.12.09 and configured to used IBNSv2

After I created a DACL on the Authz Profile, it downloaded on the 3560 & 3750, and both endpoints started to work

[Arne Bier]

authentication open + pre-auth ACL is "Low Impact Mode" as far as I am concerned. This means that for successful Authorization, you MUST return a dACL that provides wider permissions than the pre-auth ACL, or else the pre-auth ACL will just stay in effect. I have not seen this operate in any other way, when there is a pre-auth ACL on the interface.

[clive.fulton]

Thanks Arne - I must confess that I am a little bit confused of the purpose to the PermitAccess authorisation profile.  I understand what you are saying, but the bahaviour was not the same on the switch that was running IBNSv1 compared to a switch that was running IBNSv2

I mentioned the 3850 that was running IBNSv2, and hit the the same policy and got the same Authorisation Profile - i.e. PermitAccess, and it did not lose network access and no dACL was pushed at this stage

On that switch, the interface configuration was:-

MPS08PPESW01#sho derived-config int g1/0/14
Building configuration...

Derived configuration : 837 bytes
!
interface GigabitEthernet1/0/14
description Moxa Serial Server
subscriber aging probe
switchport access vlan 240
switchport mode access
switchport voice vlan 651
device-tracking attach-policy IP-TRACKING
ip access-group DEFAULT-ACL in
no logging event link-status
load-interval 30
speed auto 10 100
authentication periodic
authentication timer reauthenticate 5400
access-session port-control auto
mab
no snmp trap link-status
dot1x pae authenticator
dot1x timeout tx-period 7
dot1x max-reauth-req 3
dot1x timeout held-period 300
storm-control broadcast level pps 100 80
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard root
service-policy type control subscriber DOT1X_MAB_POLICY
service-policy input MARKING
service-policy output 2P6Q3T
ip dhcp snooping limit rate 100

Preauth ACL

Extended IP access list DEFAULT-ACL
10 permit udp any any eq domain
20 permit tcp any any eq domain
30 permit udp any eq bootps any
40 permit udp any any eq bootpc
50 permit udp any eq bootpc any
70 deny ip any any

The service Policy DOT1X_MAB_POLICY is :-

policy-map type control subscriber DOT1X_MAB_POLICY
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x priority 10
20 authenticate using mab priority 20
event authentication-failure match-first
5 class DOT1X_FAILED do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
10 clear-authenticated-data-hosts-on-port
20 activate service-template CRITICAL_DATA_ACCESS
30 activate service-template CRITICAL_VOICE_ACCESS
40 authorize
50 pause reauthentication
20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
10 pause reauthentication
20 authorize
30 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
40 class MAB_FAILED do-until-failure
10 terminate mab
20 authentication-restart 60
50 class always do-until-failure
10 terminate dot1x
20 terminate mab
30 authentication-restart 60
event agent-found match-all
10 class always do-until-failure
10 terminate mab
20 authenticate using dot1x priority 10
event aaa-available match-all
10 class IN_CRITICAL_AUTH do-until-failure
10 clear-session
20 class NOT_IN_CRITICAL_AUTH do-until-failure
10 resume reauthentication
event inactivity-timeout match-all
10 class always do-until-failure
10 clear-session
event authentication-success match-all
10 class always do-until-failure
10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE
event violation match-all
10 class always do-until-failure
10 restrict
event authorization-failure match-all
10 class AUTHC_SUCCESS_AUTHZ_FAIL do-until-failure
10 authentication-restart 60

If there was consistent behaviour between the switches that were running IBNSv1 and IBNSv2 I would find this easier to understand, but the inconsistency of behaviour confuses me.

[Arne Bier · Accepted solution]

I agree with your assessment and I share your confusion. i don't understand how the 3850 with IBNS 2.0 "removes/bypasses" the pre auth ACL when ISE doesn't include the dACL as part of the Access-Accept.

Not sure if this helps - but I never use the ISE built-in Access-Accept. I just don't like it, because it's a default, I can't edit it and its name is not helpful in my use cases. I create separate Authorization Profiles for use cases that I need and want to filter on (e.g. in Live Logs or Context Visibility) - e.g. using a naming convention such as

MAB MON Cameras

MAB MON Printers

and for Low Impact

MAB LOWIMPACT Cameras ... etc.

This also allows me to customise the attributes for each type of device (session timeouts, etc.).

And as a rule, I always attach a dACL to every Authorization Profile (monitor mode or low impact mode) because it's more helpful in the long run. You can then also confirm on the switch (via show access-session int xyz detail) whether the correct ACL has been applied.  Using the built-in Permit access is quick and dirty for lab - but not for production.

[clive.fulton]

Out of curiosity, has anybody else encountered this issue with PermitAccess

Is it a feature on IBNS 2.0 where it bypasses the pre auth ACL, 

Or just quirky behaviour

Could it be a bug ?