Central Web Authentication

Information About Central Web Authentication

Central web authentication offers the possibility to have a central device that acts as a web portal (in this example, the ISE). The major difference compared to the usual local web authentication is that it is shifted to Layer 2 along with MAC filtering or dot1x authentication. The concept also differs in that the radius server (ISE in this example) returns special attributes that indicate to the switch that a web redirection must occur. This solution eliminates any delay to start the web authentication.

The following are the different types of web authentication methods:

  • Local Web Authentication (LWA): Configured as Layer 3 security on the controller, the web authentication page and the pre-authentication ACL are locally configured on the controller. The controller intercepts htttp(s) traffic and redirects the client to the internal web page for authentication. The credentials entered by the client on the login page is authenticated by the controller locally or through a RADIUS or LDAP server.

  • External Web Authentication (EWA): Configured as Layer 3 security on the controller, the controller intercepts htttp(s) traffic and redirects the client to the login page hosted on the external web server. The credentials entered by the client on the login page is authenticated by the controller locally or through a RADIUS or LDAP server. The pre-authentication ACL is configured statically on the controller.

  • Central Web Authentication (CWA): Configured mostly as Layer 2 security on the controller, the redirection URL and the pre-authentication ACL reside on ISE and are pushed during layer 2 authentication to the controller. The controller redirects all web traffic from the client to the ISE login page. ISE validates the credentials entered by the client through HTTPS and authenticates the user.

Globally, if the MAC address of the client station is not known by the radius server (but other criteria can also be used), the server returns the redirection attributes, and the controller authorizes the station (using the MAC filtering) but places an access list to redirect the web traffic to the portal.

Once the user logs into the guest portal, it is possible to re-authenticate the client so that a new Layer 2 MAC filtering occurs using the Change of Authorization (CoA). This way, the ISE remembers that it was a webauth user and pushes the necessary authorization attributes to the controller for accessing the network.


Note

  • In Central Web Authentication (CWA) with dual VLAN posture scenario, Cisco AireOS and IOS-XE controller performs 2 and 3 EAPOL handshakes respectively. If a client is stuck in a quarantine VLAN because of any break in EAPOL handshake due to client or network issue, you need to analyze the client or network issue.

  • However, you can manually disconnect or reconnect the client to come out of the quarantine loop (or) click the Scan Again on AnyConnect (Or) enable posture lease (Or) use the ISE posture sync feature.

  • If the controller has no switch virtual interface (SVI) in the client subnet or VLAN, the controller has to use any of the other SVIs and send traffic as defined in the routing table. This means that the traffic is sent to another gateway in the core of the network; this traffic then reaches the client subnet. Firewalls typically block traffic from and to the same switch, as seen in this scenario, so redirection might not work properly. Workarounds are to allow this behavior on the firewall.

Prerequisites for Central Web Authentication

  • Cisco Identity Services Engine (ISE)

How to Configure ISE

To configure ISE, proceed as follows:

  1. Create an authorization profile.

  2. Create an authentication rule.

  3. Create an authorization rule.

Creating an Authorization Profile

Procedure

Step 1

Click Policy, and click Policy Elements.

Step 2

Click Results.

Step 3

Expand Authorization, and click Authorization Profiles.

Step 4

Click Add to create a new authorization profile for central webauth.

Step 5

In the Name field, enter a name for the profile. For example, CentralWebauth.

Step 6

Choose ACCESS_ACCEPT from the Access Type drop-down list.

Step 7

Check the Web Redirection (CWA, MDM, NSP, CPP) check box, and choose Centralized Web Auth from the drop-down list.

Step 8

In the ACL field, enter the name of the ACL that defines the traffic to be redirected. For example, redirect.

Step 9

In the Value field, choose the default or customized values.

The Value attribute defines whether the ISE sees the default or a custom web portal that the ISE admin created.

Step 10

Click Save.

Creating an Authentication Rule

Follow the procedure given below to use the authentication profile and create the authentication rule:

Procedure

Step 1

In the Policy > Authentication page, click Authentication.

Step 2

Enter a name for your authentication rule. For example, MAB.

Step 3

In the If condition field, select the plus (+) icon.

Step 4

Choose Compound condition, and choose Wireless_MAB.

Step 5

Click the arrow located next to and ... in order to expand the rule further.

Step 6

Click the + icon in the Identity Source field, and choose Internal endpoints.

Step 7

Choose Continue from the 'If user not found' drop-down list.

This option allows a device to be authenticated even if its MAC address is not known.

Step 8

Click Save.

Creating an Authorization Rule

You can configure many rules in the authorization policy. The MAC not known rule is configured in this section:

Procedure

Step 1

Click Policy > Authorization.

Step 2

In the Rule Name field, enter a name. For example: Mac not known.

Step 3

In the Conditions field, click the plus (+) icon.

Step 4

Choose Compound Conditions, and choose Wireless_MAB.

Step 5

From the settings icon, select Add Attribute/Value from the options.

Step 6

In the Description field, choose Network Access > AuthenticationStatus as the attribute from the drop-down list.

Step 7

Choose the Equals operator.

Step 8

From the right-hand field, choose UnknownUser.

Step 9

In the Permissions field, choose the authorization profile name that you had created earlier.

The ISE continues even though the user (or MAC) is not known.

Unknown users are now presented with the Login page. However, once they enter their credentials, they are presented again with an authentication request on the ISE; therefore, another rule must be configured with a condition that is met if the user is a guest user. For example, if UseridentityGroup Equals Guest is used then it is assumed that all guests belong to this group.

Step 10

In the Conditions field, click the plus (+) icon.

Step 11

Choose Compound Conditions, and choose to create a new condition.

The new rule must come before the MAC not known rule.

Step 12

From the settings icon, select Add Attribute/Value from the options.

Step 13

In the Description field, choose Network Access > UseCase as the attribute from the drop-down list.

Step 14

Choose the Equals operator.

Step 15

From the right-hand field, choose GuestFlow.

Step 16

In the Permissions field, click the plus (+) icon to select a result for your rule.

You can choose Standard > PermitAccess option or create a custom profile to return the attributes that you like.

When the user is authorized on the login page, the ISE triggers a COA that results in the restart of Layer 2 authentication. When the user is identified as a guest user, the user is authorized.

How to Configure Central Web Authentication on the Controller

To configure central web authentication on the controller, proceed as follows:

  1. Configure WLAN.

  2. Configure policy profile.

  3. Configure redirect ACL.

  4. Configure AAA for central web authentication.

  5. Configure redirect ACL in Flex profile.

Configure WLAN (GUI)

Set up a new WLAN on your wireless controller using the GUI.

Before you begin

You need to enable MAC filtering for Layer 2 authentication to download the redirect URL and ACL.

Procedure

Step 1

Choose Configuration > Tags & Profiles > WLANs.

Step 2

In the WLANs window, click the name of the WLAN or click Add to create a new one.

The Add/Edit WLAN window is displayed.

Step 3

In the Add/Edit WLAN window, click the General tab to configure the following parameters.

  • In the Profile Name field, enter or edit the name of the profile.

  • In the SSID field, enter or edit the SSID name.

    The SSID name is alphanumeric, and up to 32 characters in length.

  • In the WLAN ID field, enter or edit the ID number. The valid range is between one and 512.

  • Select the 802.11 radio band from the Radio Policy drop-down list.

  • Using the Broadcast SSID toggle button, change the status to either Enabled or Disabled.

  • Using the Status toggle button, change the status to either Enabled or Disabled.

Step 4

Click the Security tab, and then select the Layer 2 tab to configure the following parameters:

  • Select None from the Layer 2 Security Mode drop-down list. This setting disables Layer 2 security.

  • Enter the Reassociation Timeout value, in seconds. This is the time a fast transition reassociation times out.

  • Check the Over the DS check box to enable Fast Transition over a distributed system.

  • Choose OWE. Opportunistic Wireless Encryption (OWE) provides data confidentiality with encryption over the air between an AP radio and a wireless client. OWE Transition Mode ensures backwards compatibility.

  • Choose Fast Transition (802.11r), the IEEE standard for fast roaming. This standard allows the initial handshake with a new AP to occur before the client roams to the target AP. This method is called Fast Transition.

  • Check the check box to enable MAC filtering in the WLAN.

  • Check the Lobby Admin Access check box to enable Lobby Admin access.

Step 5

Click Save & Apply to Device.

Configuring WLAN (CLI)

Configure WLAN using commands.

Note

You need to enable MAC filtering for Layer 2 authentication to download the redirect URL and ACL.

After completing the WLAN configuration, if the changes are not pushed to all the APs, the following syslog message appears:

2021/01/06 16:20:00.597927186 {wncd_x_R0-4}{1}: [wlanmgr-db] [20583]: UUID: 0, ra: 0, TID: 0 (note): Unable to push WLAN config changes to all APs, cleanup required for WlanId: 2, profile: wlan1 state: Delete pending

If the above mentioned syslog message appears for more than six minutes, reload the controller.

If the controller does not reload and still the syslog message appears, then collect the archive logs, wncd core file, and raise a case by clicking the following link: Support Case Manager.

Procedure

  Command or Action Purpose

Step 1

wlan wlan-name wlan-id SSID-name

Example:

Device(config)# wlan wlanProfileName 1 ngwcSSID

Enters the WLAN configuration sub-mode.

wlan-name is the name of the configured WLAN.

wlan-id is the wireless LAN identifier. The range is 1 to 512.

SSID-name is the SSID name which can contain 32 alphanumeric characters.

Note

 

If you have already configured this command, enter wlan wlan-name command.

Step 2

mac-filtering [name]

Example:

Device(config-wlan)# mac-filtering name

Enables MAC filtering on a WLAN.

Note

 

While configuring mac-filtering the default authentication list is considered, if the authentication list is not configured earlier.

Step 3

no security wpa

Example:

Device(config-wlan)# no security wpa

Disable WPA security.

Step 4

no shutdown

Example:

Device(config-wlan)# no shutdown

Enables the WLAN.

Step 5

end

Example:

Device(config-wlan)# end

Returns to privileged EXEC mode.

Example

Device# config terminal
Device(config)# wlan wlanProfileName 1 ngwcSSID
Device(config-wlan)# mac-filtering default
Device(config-wlan)# no security wpa
Device(config-wlan)# no shutdown
Device(config-wlan)# end

Configuring Policy Profile (CLI)

Configure Policy Profile using commands.

Note

You need a AAA override to apply policies coming from the AAA or ISE servers. When a redirect URL and redirect ACL is received from the ISE server, NAC is used to trigger the Central Web Authentication (CWA).

Both NAC and AAA override must be available in the policy profile to which the client is being associated.

The default policy profile is associated to an AP, if the AP is not associated to any other policy profiles.

CWA clients may experience issues with VLAN assignment during the final RADIUS access-accept following successful authentication.

Procedure

  Command or Action Purpose

Step 1

wireless profile policy default-policy-profile

Example:

Device(config)# wireless profile policy default-policy-profile

Sets the policy profile.

Step 2

vlan vlan-id

Example:

Device(config-wireless-policy)# vlan 41

Maps the VLAN to a policy profile. If vlan-id is not specified, the default native vlan 1 is applied. The valid range for vlan-id is 1 to 4096.

Management VLAN is applied if no VLAN is configured on the policy profile.

Step 3

aaa-override

Example:

Device(config-wireless-policy)# aaa-override

Configures AAA override to apply policies coming from the AAA or ISE servers.

Step 4

nac

Example:

Device(config-wireless-policy)# nac

Configures Network Access Control in the policy profile. NAC is used to trigger the Central Web Authentication (CWA).

Step 5

no shutdown

Example:

Device(config-wireless-policy)# no shutdown

Enables the WLAN.

Step 6

end

Example:

Device(config-wireless-policy)# end

Returns to privileged EXEC mode.

Example

Device# configure terminal
Device(config)# wireless profile policy default-policy-profile
Device(config-wireless-policy)# vlan 41
Device(config-wireless-policy)# aaa-override
Device(config-wireless-policy)# nac
Device(config-wireless-policy)# no shutdown
Device(config-wireless-policy)# end

Configuring a Policy Profile (GUI)

Procedure

Step 1

Choose Configuration > Tags & Profiles > Policy.

Step 2

On the Policy Profile page, click Add.

Step 3

In the Add Policy Profile window, in General Tab, enter a name and description for the policy profile.

Step 4

To enable the policy profile, set Status as Enabled.

Step 5

Use the slider to enable or disable Passive Client and Encrypted Traffic Analytics.

Step 6

(Optional) In the CTS Policy section, choose the appropriate status for the following:

  • Inline Tagging—a transport mechanism using which a controller embedded wireless controller or access point understands the source SGT.

  • SGACL Enforcement

Step 7

Specify a default SGT. The valid range is from 2 to 65519.

Step 8

In the WLAN Switching Policy section, choose the following, as required:

  • Central Switching

  • Central Authentication

  • Central DHCP

  • Central Association Enable

  • Flex NAT/PAT

Step 9

Click Save & Apply to Device.

Creating Redirect ACL

The redirect ACL is a punt ACL that needs to be predefined on the controller (or the AP in case of FlexConnect local switching): the AAA server returns the name of the ACL and not its definition. The redirect ACL defines traffic (matching “deny”statements, as it denies redirection for it) that will be allowed through on the data plane and traffic (matching “permit” statements) that will be sent to the control plane towards the CPU for further processing (that is, the web interception and redirection in this case). The ACL has implicit (that is, the invisible) statements allowing DHCP and DNS traffic towards all IPs, just like it is the case with LWA. It also ends with a statement that a security ACL implicit deny.

Procedure

  Command or Action Purpose

Step 1

ip access-list extended redirect

Example:

Device(config)# ip access-list extended redirect

The HTTP and HTTPS browsing does not work without authentication (per the other ACL) as ISE is configured to use a redirect ACL (named redirect).

Step 2

deny ip any host ISE-IP-add

Example:

Device(config)# deny ip any host 123.123.134.112

Allows traffic to ISE and all other traffic is blocked.

Step 3

deny ip host ISE-IP-add any

Example:

Device(config)# deny ip host 123.123.134.112 any

Allows traffic to ISE and all other traffic is blocked.

Note

 

This ACL is applicable for both local and flex mode.

Step 4

permit TCP any any eq web address/port-number

Example:

In case of HTTP:
Device(config)# permit TCP any any eq www

Device(config)# permit TCP any any eq 80

Example:

In case of HTTPS:
Device(config)# permit TCP any any eq 443

Redirects all HTTP or HTTPS access to the ISE login page. port-number 80 is used for HTTP and port-number 443 is used for HTTPS.

For the ACE to allow traffic to ISE, ISE should be configured above the HTTP/HTTPS ACE.

Step 5

end

Example:

Device(config)# end

Returns to privileged EXEC mode.

Configuring AAA for Central Web Authentication

Procedure

  Command or Action Purpose

Step 1

aaa server radius dynamic-author

Example:

Device(config)# aaa server radius dynamic-author

Configures the Change of Authorization (CoA) on the controller.

Step 2

client ISE-IP-add server-key radius-shared-secret

Example:

Device(config-locsvr-da-radius)# client 123.123.134.112 server-key 
0 SECRET

Specifies a RADIUS client and the RADIUS key to be shared between a device and a RADIUS client.

ISE-IP-add is the IP address of the RADIUS client.

server-key is the radius client server-key.

radius-shared-secret covers the following:

  • 0—Specifies unencrypted key.

  • 6—Specifies encrypted key.

  • 7—Specifies HIDDEN key.

  • Word—Unencrypted (cleartext) server key.

The RADIUS shared secret should not exceed 240 characters while configuring WSMA data in GUI.

Note

 

All these steps work only if the AAA configuration is in place. See the Configuring AAA Authentication for details.

Example

Device# config terminal
Device(config)# aaa server radius dynamic-author
Device(config-locsvr-da-radius)# client 123.123.134.112 server-key 0 SECRET
Device(config-locsvr-da-radius)# end

Configuring Redirect ACL in Flex Profile (GUI)

The redirect ACL definition must be sent to the access point in the FlexConnect profile. For this, the redirect ACL associated with an AP must be configured in the FlexConnect profile where the client is hosted. If an access point is not configured with any of the FlexConnect profiles, the default FlexConnect profile is associated with it.

Procedure

Step 1

Choose Configuration > Tags & Profiles > Flex.

Step 2

On the Flex Profile page, click the name of the FlexConnect profile or click Add to create a new FlexConnect profile.

Step 3

In the Add/Edit Flex Profile window that is displayed, click the Policy ACL tab.

Step 4

Click Add to map an ACL to the FlexConnect profile.

Step 5

Choose the ACL name, enable central web authentication, and specify the preauthentication URL filter.

Step 6

Click Save.

Step 7

Click Update & Apply to Device.

Configuring Redirect ACL in Flex Profile (CLI)

The redirect ACL definition must be sent to the access point in the Flex profile. For this, the redirect ACL associated to an AP must be configured in the Flex profile where the client is being hosted. If an access point is not configured with any of the Flex profiles, the default Flex profile is associated with it.


Note

When the ACL is pushed down to the APs, the permission must change from deny to permit or vice-versa. This change does not occur if the ACL contains an object group, causing the ACL not to be fully translated, which may cause the redirection to fail.

Procedure

  Command or Action Purpose

Step 1

wireless profile flex default-flex-profile

Example:

Device(config)# wireless profile flex default-flex-profile

Creates a new flex policy. The default flex profile name is default-flex-profile.

Step 2

acl-policy acl policy name

Example:

Device(config-wireless-flex-profile)# acl-policy acl1

Configures ACL policy.

Step 3

central-webauth

Example:

Device(config-wireless-flex-profile-acl)# central-webauth

Configures central web authentication.

Step 4

end

Example:

Device(config-wireless-flex-profile-acl)# end

Returns to privileged EXEC mode.

Troubleshooting Central Web Authentication

Init-State timer running out

Problem Issue: The client devices are deauthenticated by the controller if users fail to enter their credentials in a limited time interval. The clients are deauthenticated after three times the time configured for the init-state timeout in the controller.

Problem Explanation: This is the expected functionality as the init-state timeout is not directly applicable for central web authentication; instead, it is the reap timer’s value which is three times the init-state time plus five seconds (3*init-state timeout + 5) that determines the time interval in seconds for client deauthentication. For example, if you have configured the init-state timeout as 10 seconds, then the client devices are deuathenticated if users fail to enter their credentials after 35 seconds; that is (3*10 + 5) = 35 seconds.

Authentication for Sleeping Clients

Authenticating sleeping clients

A sleeping client is a wireless device that

  • has completed web authentication and been granted guest access

  • is allowed to enter sleep mode and wake up without reauthenticating through the login page, and

  • the controller stores sleeping client information for a configurable duration before requiring reauthentication.

The valid range is 10 minutes to 43200 minutes, with the default being 720 minutes. You can also configure this duration on WebAuth parameter map that is mapped to a WLAN. The sleeping client timer is activated when conditions such as idle timeout, session timeout, WLAN disabling, or AP nonoperational status occur.


Caution

If the MAC address of a client in sleep mode is spoofed, a fake device, such as a laptop, can be mistakenly authenticated.

Feature History

Feature Name

Release

Description

Webauth Sleeping Client Support

Cisco IOS XE 17.1.1s

The web authentication sleeping clients feature supports multiple combinations of authenticationsfor a given client, which are configured on the WLAN profile.

Scenarios where sleeping clients do not need reauthentication

  • Suppose there are two controller s in a mobility group. A client that is associated with one controller goes to sleep and then wakes up and gets associated with the other controller .

  • Suppose there are three controller s in a mobility group. A client that is associated with the second controller that is anchored to the first controller goes to sleep, wakes up, and gets associated with the third controller .

  • A client sleeps, wakes up and gets associated with the same or different export foreign controller that is anchored to the export anchor.

Restrictions on authenticating sleeping clients

  • If the MAC address of a client in sleep mode is spoofed, a fake device, such as a laptop, can be mistakenly authenticated.

  • The sleep client feature works only for WLAN configured with WebAuth security.

  • You can configure the sleeping clients only on a per WebAuth parameter-map basis.

  • The authentication of sleeping clients feature is supported only on WLANs that have Layer 3 security enabled.

  • When Layer 3 security is enabled, the Authentication, Passthrough, and On MAC Filter failure web policies are supported. The Splash Page Web Redirect web policy is not supported.

  • The central web authentication of sleeping clients is not supported.

  • The authentication of sleeping clients feature is not supported on guest LANs and remote LANs.

  • A guest access sleeping client that has a local user policy is not supported. In this case, the WLAN-specific timer is applied.

Configure authentication for sleeping clients (GUI)

Enable authentication for sleeping clients to ensure devices can maintain secure network access even after entering sleep mode.

Sleeping clients, such as laptops or mobile devices, periodically enter low-power states. You configure authentication to ensure they reconnect securely and seamlessly when they wake.

Procedure

Step 1

Choose Configuration > Security > Web Auth.

Step 2

In the Webauth Parameter Map tab, click the parameter map name. The Edit WebAuth Parameter window is displayed.

Step 3

Check Sleeping Client Status check box.

Step 4

Click Update & Apply to Device.

Authentication for sleeping clients is now enabled. Devices entering sleep mode will reconnect securely without manual intervention.

Configure authentication for sleeping clients (CLI)

Configure authentication parameters to manage sleeping wireless clients and control their session persistence on the device.

Sleeping clients are wireless devices that temporarily disconnect due to power-saving or roaming behaviors. Configuring authentication for sleeping clients ensures they are recognized and handled appropriately during these periods.

Procedure

Step 1

Create a parameter map and enters parameter-map webauth configuration mode.

Example:

Device(config)# parameter-map type webauth global

Step 2

Configure the sleeping client timeout to 100 minutes.

Example:

Device(config-params-parameter-map)# sleeping-client timeout 100

Valid range is between 10 minutes and 43200 minutes.

Note

 

If you do not use the timeout keyword, the sleeping client is configured with the default timeout value of 720 minutes.

Step 3

Exit parameter-map webauth configuration mode and returns to privileged EXEC mode.

Example:

Device# end

Step 4

(Optional) Show the MAC address of the clients and the time remaining in their respective sessions.

Example:

Device# show wireless client sleeping-client

Step 5

(Optional) Delete sleeping client entries from the sleeping client cache.

  • clear wireless client sleeping-client —Deletes all sleeping client entries from the sleeping client cache.

  • clear wireless client sleeping-client mac-address mac-addr —Deletes the specific MAC entry from the sleeping client cache.

Example:

Device# clear wireless client sleeping-client 
mac-address 00e1.e1e1.0001

The device displays the global configuration prompt, allowing you to make configuration changes.

Sleeping Clients with Multiple Authentications

Mobility support for sleeping clients

Feature Name

Release

Description

Mobility support for guest and nonguest sleeping clients.

Cisco IOS XE 17.1.1s

Mobility support for guest and nonguest sleeping clients.

Supported combinations of multiple authentications

Multiple authentication feature supports sleeping clients configured in the WLAN profile.

The table outlines the supported combination of multiple authentications.

Table 1. Supported combinations of multiple authentications

Layer 2

Layer 3

Supported

MAB

LWA

Yes

MAB Failure

LWA

Yes

Dot1x

LWA

Yes

PSK

LWA

Yes

Configuring Sleeping Clients with Multiple Authentications

Configure WLAN for dot1x and local web authentication

Configure a WLAN with both 802.1X (dot1x) authentication and local web authentication on a controller using CLI.

Use this procedure when you need to secure a WLAN such that users can authenticate with their credentials (dot1x) or are redirected to a local web authentication portal. This scenario is common in enterprise or campus environments where both secure and user-friendly authentication methods are required.

Before you begin

Enter the global configuration mode.

Procedure

Step 1

Enter WLAN configuration submode.

Example:

Device(config)# wlan wlan-test 3 ssid-test

  • profile-name: Profile name of the configured WLAN.

  • wlan-id: Wireless LAN identifier. Range is from one to 512.

  • SSID_Name: SSID, which can contain up to 32 alphanumeric characters.

Step 2

Enable security authentication list for dot1x security. The configuration is similar for all dot1x security WLANs.

Example:

Device(config-wlan)#  security dot1x authentication-list default

Step 3

Configure web authentication.

Example:

Device(config-wlan)#  security web-auth

Step 4

Enable authentication list for dot1x security.

Example:

Device(config-wlan)#  security web-auth authentication-list default

Step 5

Map the parameter map.

Example:

Device(config-wlan)# security web-auth parameter-map global

Note

 
If the parameter map is not associated with a WLAN, the configuration is considered from the global parameter map.

Step 6

Enable WLAN.

Example:

Device(config-wlan)# no shutdown

The new WLAN is configured with both dot1x and local web authentication enabled. Users connecting to this SSID can authenticate using their credentials or via the local web portal, according to controller policies.

Configure a WLAN for MAC authentication bypass and LWA

Set up a WLAN so that client devices are authenticated using MAC authentication bypass and provided local web authentication.

Use this task to configure a secure SSID that allows MAC-based device authentication followed by a web portal login, ensuring flexible and layered network access control.

Before you begin

Prepare the list name for MAC filtering and ensure the web authentication parameter map is defined (or note that the global map will be used).

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Enter WLAN configuration submode.

Example:

Device(config)# wlan wlan-test 3 ssid-test

  • profile-name: Profile name of the configured WLAN.

  • wlan-id: Wireless LAN identifier. Range is from 1 to 512.

  • SSID_Name: SSID, which can contain up to 32 alphanumeric characters.

Step 3

Set the MAC filtering parameters using the mac-filtering list-name

Example:

Device(config-wlan)#  mac-filtering cat-radius

Step 4

Disable security AKM for dot1x.

Example:

Device(config-wlan)#  no security wpa akm dot1x

Step 5

Disable the WPA2 cipher.

Example:

Device(config-wlan)# no security wpa wpa2 ciphers aes

aes—Excryption type that specifies WPA/AES support.

Step 6

Map the parameter map.

Example:

Device(config-wlan)# security web-auth parameter-map global

Note

 

If parameter map is not associated with a WLAN, the configuration is considered from the global parameter map.

Step 7

Enable WLAN.

Example:

Device(config-wlan)# no shutdown

The WLAN is configured to use MAC Authentication Bypass with Local Web Authentication.

Configure a WLAN for local web authentication and MAC filtering

Establish a WLAN profile with local web authentication, including MAC address filtering for enhanced security.

Use this task to set up a WLAN on your Cisco device that requires users to authenticate via a local web portal and applies MAC address filtering as an additional security measure.

Before you begin

  • Know the desired SSID name, WLAN ID, and profile name.

  • Prepare the MAC filter list name.

  • Confirm availability of an authentication parameter map (if needed).

Procedure

Step 1

Enters WLAN configuration submode using the wlan profile-name wlan-id SSID_name command.

Example:

Device(config)# wlan wlan-test 3 ssid-test

  • profile-name: Profile name of the configured WLAN.

  • wlan-id: Wireless LAN identifier. Range is from one to 512.

  • SSID_Name: SSID, which can contain up to 32 alphanumeric characters.

Step 2

Set the MAC filtering parameters.

Example:

Device(config-wlan)#  mac-filtering cat-radius

Step 3

Disable security Authenticated Key Management (AKM) for dot1x.

Example:

Device(config-wlan)#  no security wpa akm dot1x

Step 4

Disable the WPA2 cipher.

Example:

Device(config-wlan)# no security wpa wpa2 ciphers aes

aes: Excryption type that specifies WPA/AES support.

Step 5

Configure the fallback policy with MAC filtering and web authentication.

Example:

Device(config-wlan)# security web-auth on-macfilter-failure wlan-id

Step 6

Map the parameter map.

Example:

Device(config-wlan)# security web-auth parameter-map global

Note

 
If the parameter map is not associated with a WLAN, the configuration is considered from the global parameter map

Step 7

Enable WLAN.

Example:

Device(config-wlan)# no shutdown

The WLAN is now configured for local web authentication with MAC filtering, ready for users to connect and authenticate through the portal.

Configure a PSK + LWA in a WLAN

Set up a WLAN with both a preshared key (PSK) and local web authentication (LWA) using CLI commands.

Use this task to enable secure access for clients on a WLAN using both a PSK and web authentication mechanisms.

Before you begin

  • Decide the profile name, WLAN ID, and SSID for the new WLAN.

  • Create required authentication lists and parameter maps if not already present.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Enter WLAN configuration submode using the wlanprofile-namewlan-idSSID_name command.

Example:

Device(config)# wlan wlan-test 3 ssid-test

  • profile-name: Profile name of the configured WLAN.

  • wlan-id: Wireless LAN identifier. Range is from 1 to 512.

  • SSID_Name: SSID, which can contain up to 32 alphanumeric characters.

Step 3

Disables security AKM for dot1x.

Example:

Device(config-wlan)#  no security wpa akm dot1x

Step 4

Enables web authentication for a WLAN.

Example:

Device(config-wlan)#  security web-auth

Step 5

Disable the WPA2 cipher.

Example:

Device(config-wlan)# no security wpa wpa2 ciphers aes

aes: Excryption type that specifies WPA/AES support.

Step 6

Configure the preshared key on a WLAN.

Example:

Device(config-wlan)# security wpa psk set-key ascii 0 1234567

Step 7

Configure PSK support.

Example:

Device(config-wlan)#security wpa akm psk

Step 8

Enable the authentication list for dot1x security.

Example:

Device(config-wlan)#  security web-auth authentication-list default

Step 9

Map the parameter map.

Example:

Device(config-wlan)# security web-auth parameter-map global

Note

 
If the parameter map is not associated with a WLAN, the configuration is considered from the global parameter map.

The WLAN is configured to use both a preshared key and local web authentication for client access.

Configure a sleeping client

Configure parameters that determine how long a client device remains in "sleeping" state before timing out, using CLI.

Sleeping clients are devices that temporarily disconnect from the network but retain their association for a defined period, allowing smooth reconnection. You may wish to adjust the sleeping client timeout to optimize performance or manage resource use.

Before you begin

Identify the parameter map (by name or use the global map) you wish to modify.

Procedure

Step 1

Enter global configuration mode.

Example:

Device# configure terminal

Step 2

Create a parameter map and enters parameter-map-name configuration mode using the parameter-map type webauth {parameter-map-name | global} command.

Example:

Device(config)# parameter-map type webauth MAP-2

The specific configuration commands supported for a global parameter map defined with the global keyword differ from the commands supported for a named parameter map defined with the parameter-map-name argument.

Step 3

Configure the sleeping client timeout, in minutes using the sleeping client [timeout time] command.

Example:

Device(config-params-parameter-map)#  sleeping-client timeout 60

The available range for the time argument is from 10 to 43200.

Note

 
If you do not use the timeout keyword, the sleeping client is configured with the default timeout value of 720 minutes.

The sleeping client timeout is configured for the specified parameter map.

Verify a sleeping client configuration

To verify a sleeping client configuration, use the command:

Device# show wireless client sleeping-client
Total number of sleeping-client entries: 1

MAC Address                    Remaining time (mm:ss)    
--------------------------------------------------------
2477.031b.aa18                 59:56