topic central web authentication in Network Access Control

central web authentication

bert.lefevre — Mon, 11 Mar 2019 01:12:06 GMT

I have downloaded the new Cisco ISE, I've managed to configure 802.1x and MAB succesfully but I want to configure wired centralized web authentication, but I cannot find any documentation how to configure ISE and Cisco Catalyst (IOS) switches to use this feature (I only find (limited) documentation about local web auth on the switch).

I want to achieve the following authentication order on a switchport:

802.1x
MAB
central web authentication

So if a guest user comes with his laptop, 802.1x is not configured on his laptop and he's not in the Mac Bypass DB, he should "failover" to web auth and get the ISE guest portal webpage with his web browser. There he enters a guest username and password (which is of course already in the ISE DB) and he should get web access.

I've configured the switchport with the following commands

switchport access vlan 99

switchport mode access

switchport voice vlan 50

authentication event no-response action authorize vlan 32

authentication host-mode multi-domain

authentication order dot1x mab webauth

authentication port-control auto

authentication violation protect

authentication fallback webprofile

mab

dot1x pae authenticator

dot1x timeout quiet-period 2

dot1x timeout tx-period 2

spanning-tree portfast

spanning-tree bpduguard enable

the web-profile with access-list to permit DHCP traffic between the attached device and any DHCP server in the vlan 99, and communications with ISE (also in vlan 99) at the moment "fallback webprofile" is triggered (I don't know if this should be configured with central webauth?)

SW01T#sh fallback profile webprofile

Profile Name: webprofile

------------------------------------

Description : webauth profile

IP Admission Rule : NONE

IP Access-Group IN: 133

FYI, the access list:

Extended IP access list 133

10 permit ip any host 10.175.0.29

30 permit udp any any eq bootps

40 permit udp any eq bootpc any

In the ISE, I configured DOT1x and MAB. In the MAB profile, I configured "continue" if user is unknown, and then an authorization profile for the web authentication:

(attributes of the profile):

Access Type = ACCESS_ACCEPT

cisco-av-pair = url-redirect-acl=webauth

cisco-av-pair = url-redirect=https://ip:8443/guestportal/gateway?sessionId=SessionIdValue&portal=https://10.175.0.29:8443/guestportal/gateway?sessionId=SessionIdValue&portal=http&action=cwa&action=cwa

But it doesn't work. If I attach a device, it tries 802.1x, it tries MAB, then it fails over to "web authentication" but immediately fails with "no-response" message:

001420: Jul 1 12:09:19: %AUTHMGR-5-START: Starting 'webauth' for client (0011.2

5d7.6c6c) on Interface Fa1/0/3 AuditSessionID 0AAF003E000000582E866B69

from 'webauth' for client (0011.25d7.6c6c) on Interface Fa1/0/3 AuditSessionID 0

AAF003E000000582E866B69

001422: Jul 1 12:09:19: %AUTHMGR-7-FAILOVER: Failing over from 'webauth' for cl

ient (0011.25d7.6c6c) on Interface Fa1/0/3 AuditSessionID 0AAF003E000000582E866B

001423: Jul 1 12:09:19: %AUTHMGR-7-NOMOREMETHODS: Exhausted all authentication

methods for client (0011.25d7.6c6c) on Interface Fa1/0/3 AuditSessionID 0AAF003 001420:

Is there some configuration guide or steps available in order to make this work please?

kind regards

central web authentication

Tarik Admani — Fri, 01 Jul 2011 15:06:55 GMT

Hi,

Here is the configuration task list, based on the output you provided there doesnt seem to be ip admission rule configured.

I also wanted to know if you had ip device tracking configured globally also. You will point your fallback profile to your ip admission rule that you created.

Here is an example of what I have in my lab:

ip device tracking

ip admission name Webauth proxy http inactivity-time 60

fallback profile Webauth

ip access-group Webauth in

ip admission Webauth

Seems as if the ip admission Webauth is missing from your fallback configuration, please update and let me know how this works.

Also you can troubleshoot but issue a show ip admission cache to see if the process has started.

Thanks,

Tarik

Re: central web authentication

bert.lefevre — Tue, 05 Jul 2011 09:53:19 GMT

Hi Tarik,

thank you for the fast reply.
I've configuried the extra settings you told me (although I thought the ip admission configuration was only for local web authentication (where the switch acts as a http server).

But it still doesn't work. The pc is getting the ip address from the dhcp server but if I open a browser session, I do not get redirected to the ISE portal in order to log me in with a Guest account.

If I look at the authentication session of the port, it looks like the ISE has correctly sent the redirect acl and redirect url to the switchport:

Switch# show auth sessions int fa 1/0/3

Interface: FastEthernet1/0/3

MAC Address: 0011.25d7.6c6c

IP Address: 10.175.0.229

User-Name: 001125d76c6c

Status: Authz Success

Domain: DATA

Security Policy: Should Secure

Security Status: Unsecure

Oper host mode: multi-domain

Oper control dir: both

Authorized By: Authentication Server

Vlan Group: N/A

URL Redirect ACL: webauth

URL Redirect: https://ISE.onemrva.priv:8443/guestportal/gateway?session

Id=0AAF003E0000175A43004FE3&action=cwa

Session timeout: N/A

Idle timeout: N/A

Common Session ID: 0AAF003E0000175A43004FE3

Acct Session ID: 0x000018CF

Handle: 0xEF00075B

Runnable methods list:

Method State

dot1x Failed over

mab Authc Success

webauth Not run

As you can see, the "web authentication" is the result of a "succesful MAB". This is because I had to configure ISE to continue on MAB if the user was not found (I found that somewhere in documentation). Then I have configured a default authorization profile where the "web authentication" is triggered. This is where I've configured the redirect-url and so on and this is of course sent to the switch as a succesfull MAB:

authorization profile "webauthentication" with the "centralized web authentication" settings configured (see attributes output):

Access Type = ACCESS_ACCEPT

cisco-av-pair = url-redirect-acl=webauth

cisco-av-pair = url-redirect=https://ip:8443/guestportal/gateway?sessionId=SessionIdValue&action=cwa

Actually, I really have no idea if I have correctly configured ISE to handle central web authentication...

If I check the "show ip admission cache", nothing is seen in there.

central web authentication

Tarik Admani — Wed, 06 Jul 2011 05:26:07 GMT

Bert,

Sorry for the delay I was away for the long weekend and just saw ther results or your testing, please remove the profiling rules, or the profiled endpoint if one exists for this mac address. The webauth is not being triggered because you are performing mab and succeeding. Also if you are not using profiling on the ISE appliance, then you can either remove mab from the port config, or if you want to keep mab then remove the clients mac address from the ISE database.

Also one thing to mention is that the page that is going to be displayed is not on the ISE portal (unless something changed but we are coming up to speed) its a page stored on the switch itself that is used for webauth.

Let me know after you make these changes and how things go.

Tarik

central web authentication

bert.lefevre — Wed, 06 Jul 2011 09:38:25 GMT

Hi Tarik,

the user guide from ISE 1.0 mentions 2 possibilities for web authentication:

1) Wired NAD Interaction for Central WebAuth (where ISE does have a web portal where guests can login with credentials) --> this is what we want to use (page 675)

2) Wired NAD Interaction with Local WebAuth (where the switch has a stored html webpage and forwards the credentials as a RADIUS request to ISE) (page 677)

We prefer the first option to avoid uploading/updating a webpage to every switch (we have more than 40 switch stacks). We want a central (ISE) handling of every Guest request.

I'm quite sure that the ISE offers the portal (web page to login) possibility as he does send the url-redirect RADIUS attribute. If I go manually to that page (https://ip:8443/guestportal/gateway?sessionId=SessionIdValue&action=cwa) I receive a ISE guest login page.

I also want to mention that the "MAB succeed" on the switch is not because the mac-adres was found in the ISE database (as the address isn't in the database), but because I've configured the "continue" option in case the user is not found in the database (which results in a MAB succceed on the switch).

But as I cannot find any documentation about configuring all steps on both ISE and switch, I'm really not sure if what I'm trying (with the MAB continue option and so on) is right... So it is also difficult to explain every step I've configured in ISE to try to make it work.

Do you know if Cisco is planning some kind of configuration guide or configuration example for centralized web authentication in the (near) future?

Re: central web authentication

mogli — Thu, 07 Jul 2011 16:49:30 GMT

Hi Bert,

i've got the same issue like you - my client opens a browser and nothing happens. although, the log output on the cli seems to be correct:

4503-E(config-if)#no shutdown

4503-E(config-if)#

*Jul 7 07:42:00: %DOT1X-5-FAIL: Authentication failed for client (Unknown MAC) on Interface Fa2/1 AuditSessionID 000000000000000800BAECB4

*Jul 7 07:42:00: %AUTHMGR-7-RESULT: Authentication result 'no-response' from 'dot1x' for client (Unknown MAC) on Interface Fa2/1 AuditSessionID 000000000000000800BAECB4

*Jul 7 07:42:00: %AUTHMGR-7-FAILOVER: Failing over from 'dot1x' for client (Unknown MAC) on Interface Fa2/1 AuditSessionID 000000000000000800BAECB4

*Jul 7 07:42:00: %AUTHMGR-5-START: Starting 'mab' for client (00c0.9f43.4ab3) on Interface Fa2/1 AuditSessionID 000000000000000800BAECB4

*Jul 7 07:42:00: %MAB-5-SUCCESS: Authentication successful for client (00c0.9f43.4ab3) on Interface Fa2/1 AuditSessionID 000000000000000800BAECB4

*Jul 7 07:42:00: %AUTHMGR-7-RESULT: Authentication result 'success' from 'mab' for client (00c0.9f43.4ab3) on Interface Fa2/1 AuditSessionID 000000000000000800BAECB4

*Jul 7 07:42:00: %AUTHMGR-5-VLANASSIGN: VLAN 10 assigned to Interface Fa2/1 AuditSessionID 000000000000000800BAECB4

*Jul 7 07:42:00: %EPM-6-POLICY_REQ: IP 0.0.0.0| MAC 00c0.9f43.4ab3| AuditSessionID 000000000000000800BAECB4| AUTHTYPE DOT1X| EVENT APPLY

*Jul 7 07:42:00: %EPM-6-IPEVENT: IP 0.0.0.0| MAC 00c0.9f43.4ab3| AuditSessionID 000000000000000800BAECB4| AUTHTYPE DOT1X| EVENT IP-WAIT

*Jul 7 07:42:01: %EPM-6-IPEVENT: IP 1.1.1.50| MAC 00c0.9f43.4ab3| AuditSessionID 000000000000000800BAECB4| AUTHTYPE DOT1X| EVENT IP-ASSIGNMENT

*Jul 7 07:42:01: %AUTHMGR-5-SUCCESS: Authorization succeeded for client (00c0.9f43.4ab3) on Interface Fa2/1 AuditSessionID 000000000000000800BAECB4

4503-E(config-if)#

By accident, i found out how to get the url-redirect "working".

4503-E(config-if)#

4503-E(config-if)#exit

4503-E(config)#ip access-list extended ACL_CWA

4503-E(config-ext-nacl)#exit

4503-E(config)#

4503-E(config)#

*Jul 7 07:49:56: %MAB-5-SUCCESS: Authentication successful for client (00c0.9f43.4ab3) on Interface Fa2/1 AuditSessionID 000000000000000900C10B1E

*Jul 7 07:49:56: %AUTHMGR-7-RESULT: Authentication result 'success' from 'mab' for client (00c0.9f43.4ab3) on Interface Fa2/1 AuditSessionID 000000000000000900C10B1E

*Jul 7 07:49:56: %EPM-6-POLICY_REQ: IP 1.1.1.50| MAC 00c0.9f43.4ab3| AuditSessionID 000000000000000900C10B1E| AUTHTYPE DOT1X| EVENT APPLY

*Jul 7 07:49:57: %AUTHMGR-5-SUCCESS: Authorization succeeded for client (00c0.9f43.4ab3) on Interface Fa2/1 AuditSessionID 000000000000000900C10B1E

4503-E(config)#

Hmm, the only thing i do is to enter the ACL which i use for the CWA and leave it imediately again.... without changing anything... strange right? it looks like that the switch doesn't recongize the first EPM Event where the URL Redirect is assigned from the ISE. and for what reason ever, the switch "reapplies" these Attributes when i enter the corresponding ACL context.....

and immediately after that, my client get's the correct url redirection..... as expected.

for sure, that's nothing for production 😉

i'm not really sure, but for me this looks like an switch issue. the ISE returns the correct attributes with the radius-access.

i'm running a Cat45k with 15.0(2)SG

mayby one of the cisco guys can light up this issue...... 🙂

Re: central web authentication

Eduardo Aliaga — Sat, 09 Jul 2011 07:12:16 GMT

The ACL must exist on the switch. The source IP should be any. The destination should match the traffic you want to redirect. For example if "url-redirect-ACL= MY-ACL" then the switch config should be:

(config)# ip access-list extended MY-ACL

(config-ext-nacl)# permit tcp any 10.0.0.0 0.0.0.255 eq www

Please rate if it's helpful.

Re: central web authentication

bert.lefevre — Mon, 11 Jul 2011 10:50:48 GMT

Actually, I already had an access-list "webauth" locally on the switch. But I had used a deny ACE instead of permit for http traffic, because I read somewhere that the redirect only triggers if the ACL denies the http traffic.

Anyway, as that (denying the www traffic) doesn't work, I tried permitting the traffic in the ACL but it's still the same (no redirect unfortunately)... I'll keep searching for a solution.

Re: central web authentication

Eduardo Aliaga — Tue, 12 Jul 2011 04:08:17 GMT

I got it working today. Here is my switch config

aaa new-model
!
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius

ip device tracking

interface GigabitEthernet x/x
authentication host-mode multi-domain
authentication order mab
authentication port-control auto
mab
dot1x pae authenticator

ip access-list extended GUEST-ACL
deny ip any host
permit tcp any any eq www
deny ip any any

And I get the Guest Portal login only for HTTP traffic. Pings and other traffic are not redirected.

Re: central web authentication

Nicolas Darchis — Tue, 12 Jul 2011 06:36:27 GMT

Bert opened a tac case with me 🙂

One important thing to differentiate is the default port ACL applied on the port. That ACL is for pre-auth traffic.

And the ACL that ISE sends back (and that should also be on the switch). That one is for regulating traffic after user authentication.

Ideally they should be different 🙂