WLC Authentication by ISE Server

In this post we will see how to configure a Wireless LAN Controller (WLC) and Cisco ISE Server (Cisco Identity Service Engine) so that the AAA server can authenticate management users on the controller. We will also see that how different management users can receive different privileges using Vendor-specific Attributes (VSAs) returned from the Cisco ISE RADIUS server.

Parameters:

ISE Server: 172.99.xx.1
WLC: 172.99.80.1 (TestWLC1)
Shared Secret: CISCO123456789
Read/Write User: sandeeprw, Password: Testwlc1rw
Read/Only User: sandeepro, Password: Testwlc1ro

Now we need to configure WLC and ISE so that:

• Any user who login to the WLC with the username as sandeeprw is given full administrative access to the WLC.
• Any user who login to the WLC with the username as sandeepro is given read-only access to the WLC.

Step1:  Cisco WLC Configuration

1. Login to WLC GUI, click Security > AAA > RADIUS > Authentication > New. The RADIUS Authentication server page appears. Click on New to add a server and then enter all the detail.
2. Check the Management radio button in order to allow the RADIUS Server to authenticate users who login to the WLC.

 

Note: Make sure that the shared secret configured on this WLC will also be the same shared secret on the RADIUS server. Only then the WLC can communicate with the RADIUS server.

3. Verify whether the WLC is configured to be managed by Cisco ISE. In order to do this, click Security > AAA > RADIUS>Authentication from the WLC GUI.

 

4. We can see that the Management check box is enabled for RADIUS server 172.99.xx.1. This illustrates that ISE is allowed to authenticate the management users on the WLC.

Step2: Cisco ISE configuration

1)      Add the WLC as an AAA client to the RADIUS server.
2)      Create User Identity Groups for users.
3)      Configure a user with read-write access and assign to specific User Identity Group.
4)      Configure a user with read-only access and assign to specific User Identity Group.
5)      Create Authorization profile and assign Diff. RADIUS IETF attributes for these users.
6)      Create Authentication / Authorization policy for these internal users.

 

Add the WLC as an AAA Client to the RADIUS Server

Login to ISE the click on Administration > Network Devices > Add then enter the details of WLC and don’t forget to enter same shared secret as we did in WLC.

And clicks save.

Create User Identity Groups for users.

To create user identity groups, click on Administration > Identity Management > Groups > User identity Groups > Add then enter the Name and description.

Configure a user with read-write access and assign to specific User Identity Group.

RW: username-sandeeprw, password: Testwlc1rw

Click on Administration > Identity Management > Identities > User > Add then enter the details and assign this user to WLC-AdminRW group, save it.

Configure a user with read-only access and assign to specific User Identity Group.

RO: username- sandeepro, password: Testwlc123ro

Click on Administration > Identity Management > Identities > User > Add then enter the details and assign this user to WLC-AdminRO group, save it.

Create Authorization Profile and assign diff. Radius attributes for these users.

To authenticate a user via RADIUS server, for controller login and management, we must add the user to the RADIUS database with the IETF RADIUS attribute Service-Type set to the appropriate value according to the user’s privileges.

• In order to set read-write privileges for the user, set the Service-Type Attribute to Administrative.
• In order to set read-only privileges for the user, set the Service-Type Attribute to NAS-Prompt.

Login to ISE GUI then go to Policy > Policy Elements > Results

Create Authentication / Authorization policy for these internal users

To create Authentication policy: Login to ISE, click on Policy > Authentication.

Here is the full policy name:

AuthWLCAdmin: If {DEVICE:Device Type equals All Device Types#Wireless LAN Controller}
 {Allows Protocol: Default Network Access}
 Default: use Internal user

Authorization Policy:

Save to apply changes.

Step3: Verification

Now it’s time for testing
First with username: sandeeprw (read write access)

username: sandeepro (read only access)

Then I tried to create a WLAN with read-only access, the output was “Authorization Failed No sufficient privileges”

Hence Proved 🙂

Advertisement

WLC WebAuth configuration

In this post we will see how to implement and configure WLC to support internal Webauth.
Web authentication is a Layer 3 security feature that causes the controller to not allow IP traffic (except DHCP and DNS -related packets) from a particular client until that client has correctly supplied a valid username and password.
Web authentication is mostly used to deploy a guest-access network. We must remember that web authentication does not provide data encryption. Webauth is an authentication method without encryption.

Web authentication can be performed using:

• Default login window on the WLC
• Modification of the default login window on the WLC
• A customized login window that we download to the controller
• A customized login window that we configure on an external web server (External web authentication)

In this post we will only see the starting 3 ways because I don’t have any external webserver.

Let’s start with Configuration of WLC. We will follow these steps:

1. Create a dynamic interface and fill all the required details.
2. Create a WLAN and apply the settings.
3. Configure WLC for Webauth (Internal).
4. Create local user for testing.
5. Verification

1. Create a dynamic interface and fill all the required details.

From WLC GUI, Choose Controller > Interface > New and fill the details:
IP Address—10.99.81.1
Netmask—255.255.255.0 (24 bits)
Gateway—10.99.81.254
Port Number—1
Primary DHCP Server—172.99.80.1(WLC Management IP for internal DHCP server)

Click Apply to save the changes.

2. Create a WLAN and apply the settings:

From the WLC GUI, click WLAN in the menu at the top, and click New on the upper right side. This page will appear. Fill Profile name and SSID.

Click Apply.

A new WLANs > Edit window appears.
Check the status box to enable the WLAN.
From the Interface menu, select the name of the VLAN interface (webauth) that we created above.
Check the Broadcast SSID box.

Click on Security Tab
Click Layer 2 security and set to None.

Click the Layer 3 tab
Check the Web Policy box and choose the Authentication option.

Then click Apply from upper right side to save changes.

3. Configure WLC for Webauth(Internal).

Internal web authentication is the by default web authentication type on WLCs. NO need to change the configuration.

4. Create local user for testing:

We can use 3 ways:
Local authentication, RADIUS server, LDAP server
In this post we will tests with Local authentication.

WLC GUI, choose Security > AAA > Local Net Users > New
Enter the username, password and WLAN profile from drop down box.

Click Apply
Here we created 2 users:
Username: Sandeep, Password: webauth123
Username: Sandeep1, Password: webauth12345

5. Verification

Default login window on the WLC
1. Connect with Webauth WLAN.

2. Then a new browser will automatically open or we have to manually enter virtual interface IP from WLC : https://1.1.1.1/login.html. A Login window will appears
***In my WLC I have Virtual interface IP as 2.2.2.2

3. Enter the username and password of the Local Net User that we created:
Username: sandeep, Password: webauth123

Modification of the default login window on the WLC

1. Login to WLC and modify the default login window by choosing Security > Web Auth > Web Login Page and click on Apply to save it. I changed the headline and message content.

2. Now connect to webauth WLAN. Login page will appear like this.

3. Enter the username and password.

A customized login window that we download to the controller

1. To download a customized login page, first start a TFTP/FTP server and put the login page in their root directory then login to WLC GUI, click on Commands and the details.

2. Change the WLAN setting.
WLAN > click on WLAN ID then Security > Layer3,
Select the Over-ride Global Config box
Choose Customized (Downloaded) webauth type from drop down box and select the login and login failure page then click apply.

3. Connect to WLAN “webauth” then this login page will appear.

4. Enter the username/Password and click on I agree with Policy Above.

Here is the complete Web Authentication Process(How it works: )

• We open a web browser and enter a URL, http://www.google.com. The client sends out a DNS request for this URL to get the IP for the destination. The WLC bypasses the DNS request to the DNS server and the DNS server responds back with a DNS reply, which contains the IP address of the destination http://www.google.com. This, in turn, is forwarded to the wireless clients.
*** In my above post I used DNS server as 8.8.8.8

• The client then tries to open a TCP connection with the destination IP address. It sends out a TCP SYN packet destined to the IP address of http://www.google.com.

• The WLC has rules configured for the client and hence can act as a proxy for http://www.google.com. It sends back a TCP SYN-ACK packet to the client with source as the IP address of www. google.com. The client sends back a TCP ACK packet in order to complete the three way TCP handshake and the TCP connection is fully established.

• The client sends an HTTP GET packet destined to www. google.com. The WLC intercepts this packet and sends it for redirection handling. The HTTP application gateway prepares a HTML body and sends it back as the reply to the HTTP GET requested by the client. This HTML makes the client go to the default webpage URL of the WLC, for example, http://<Virtual-Server-IP>/login.html.

• The client closes the TCP connection with the IP address, for example, www. google.com.

• Now the client wants to go to http://2.2.2.2/login.html. Therefore, the client tries to open a TCP connection with the virtual IP address of the WLC. It sends a TCP SYN packet for 2.2.2.2 to the WLC.

• The WLC responds back with a TCP SYN-ACK and the client sends back a TCP ACK to the WLC in order to complete the handshake.

• The client sends a HTTP GET for /login.html destined to 2.2.2.2 in order to request for the login page.

• This request is allowed up to the Web Server of the WLC, and the server responds back with the default login page. The client receives the login page on the browser window where the user can go ahead and log in.

WLC CLI Commands with GUI Part2

Part1: WLC CLI Commands with GUI Part1

Here is the 2nd part: This is not compeletely cover the all commands but soon(After my CCIE Written paper)  will prepare all commands with WLC GUI.

Wireless > 802.11a 

Wireless>Timers

Wireless>QoS Profiles

Wireless> Security

Wireless>Management

WLC CLI Commands with GUI Part1

In this post we will see the the CLI commands for Wireless Lan controller with WLC GUI.

This is not done by me, I just added few commands, rest i copied or downloaded the excel file from Rasika Post.

I am sharing this, may be it will fruitful for the aspirants of CCIEs or Wireless Engineers to troubleshoot or use.

So lets have a look 🙂

Controller > General

Controller > Multicast

Controller > Mobility Anchor

Controller > CDP

Controller > Advanced

WLAN > Advanced

Wireless > Access Point > General

Wireless > Access Point > Advanced

Wireless > Radios> 802.11a/n

Wireless > AP Configuration

Continue part 2………

Lightweight Access Point joining issues to WLC Part 1

In this post I will try to cover as many as possible problems due to AP can not join to WLC.

First of all we should know that there are two types of Access Points (I am only talking about Cisco products):

1. Autonomous AP or Standalone AP
2. Lightweight AP

Autonomous AP doesn’t need WLC to connect and it can be used in small office / Home office scenarios. (I will not go into detail, may in later post we will see that, how it works and configuration).

Lightweight AP: This type of AP can only be used with Wireless LAN Controllers. These can be used in medium to large deployments.

How to verify if it’s an autonomous AP or Lightweight?

Here are the two ways:

• Connect to the AP using a console cable, and login to the AP (if you need to enter credentials, default username pass are Cisco, default enable password is Cisco). As a side note, the autonomous AP code prompts by default ap> and only requires you to enter an enable passowrd. The lightweight code asks you for username and password by default, and display by default the AP MAC address as a prompt. So this might be a first indication, but all this can be changed through configuration, so this is just a note, not an exact way yet.
• On the AP console, type show version. If the AP runs an autonomous code, the version will show the string k9w7. If the AP runs a lightweight code, the version will show k9w8.
• Want to know more about AP versions, Go here:  Understand AP IOS Images

Now we know that only LAP have to join WLC, without WLC this these kinds of AP will not work.

Before starting to find out the cause why AP not joining, first we must understand the behind the scene.

In order for the WLC to be able to manage the LAP, the LAP should discover the controller and register with the WLC. There are different methods that an LAP uses in order to discover the WLC.

There are for main events occurs:

1. Discovery Requests
2. Discovery Response
3. Join Request
4. Join Response

Refer to: LAP Registration to WLC

So now we assume that AP got the IP address, either statically or via DHCP.

Without IP AP will not do anything, so first we need to assign a IP to AP then only it can send discovery request.

Basic things to check:

1. Is AP got IP via DHCP?
2. Can you ping AP from WLC or vice versa.
3. Is this specific VLAN (in which AP got the IP) blocked by anything on switch like STP?
4. Check the logs on AP: it must start the discovery request for WLCs.

Till now if everything is ok then we can start with some command issues due to which LAP not join to WLC.

Scenario 1: Mismatch in Regulatory Domain

I have seen this errors many times:

We must enable debug capwap <events/error> enable or debug lwapp <events/error> enable

Sample Error Logs:

802.a or 80211bg Regulatory Domain (-E) does not match with country(AU )
AP RegDomain check for the country AU failed
Regulatory Domain check Completely FAILED The AP will not be allowed to join

These errors clearly show that there is a mismatch in the regulatory domain of the LAP and the WLC. To resolve this issue, add the country for which the AP was built to the list of countries supported on the controller from Wireless > Country. We have to disable all 802.11b/g and 802.11a radios to change the controller country codes list.

In my example, I only configured DE, this Country supports -E-   regulatory domain on AP:

The WLC can supports multiple regulatory domains but each regulatory domain must be selected before an LAP can join from that domain. When you purchase APs and WLCs, ensure that they share the same regulatory domain. Only then can the LAPs register with the WLC.

Here you can check the Wireless Compliance Status, specific country with specific Regulatory domain for Access Points.

Scenario 2: Certificate and Time

AP and controller needs to exchange certificate to create a secure tunnel for communication. These Certificates have creation and expiry date. If the time and date on WLC are wrong, the AP certificate will be refused because if it is not valid yet or not valid anymore.

We must run these debug commands to find out the exact error:

debug capwap errors enable and debug pm pki enable

Sample Error logs:

Does not include valid certificate in CERTIFICATE_PAYLOAD from AP MACADDRESS. Unable to free public key.
Current time outside AP cert validity interval: make sure the controller time is set.

To resolve this kind of issue, set the controller time and date to a present value from GUI: Command > Set Time or config time command from CLI

We can also receive this kind of message if AP certificate is not valid anymore or corrupted: In this case we must return this AP to our supplier and take a new one.

We can check the AP certificate validity by this command: show crypto ca certificates

 Scenario 3: Firewall Blocking Necessary Ports

When APs and controllers are in different subnets, make sure that routing and firewall filters allow traffic both ways.

Enable these UDP ports for LWAPP traffic:

UDP ports 12222 and 12223 must be open in both directions.

Enable these UDP ports for CAPWAP traffic:

UDP ports 5246 and 5247 must be open in both directions.

If the AP cannot access the controller on UDP port 5246 (CAPWAP Control), the discovery and join requests never reach the controller. The result is that the AP is not seen on the controller, and the debug capwap event enable command on the controller does not display any message about the AP.

If the controller cannot access the AP UDP port 5246 (CAPWAP Control), the discovery and join requests never reach the AP. The result is that the controller receives discovery requests, answers with discovery responses, but the AP does not get these responses and never moves to the join phase.

Scenario 4: Brand New Access Points

With new Access Points or even with the old AP, we can get some compatibility issues with WLC version.

Example: The 1600 and 3600 APs are new models, and require new controller codes. The 1600 AP requires controller code release 7.4.100.0 or later, and the 3600 AP requires controller code 7.2 or later. The same issue affects 802.11n APs and older controller codes. If the controller code is too old, the AP model is not recognized.

We must run these debug commands to find out the exact error:

debug capwap errors enable

Sample Error Logs

AP Associated. Base Radio MAC: MAC ADDRESS
AP Disassociated. Base Radio MAC: MAC ADDRESS
AP with MAC MAC ADDRESS is unknown.

To resolve this issue, we have to upgrade the controller code or have the AP discover a controller running the appropriate code version.

Check here the Cisco Software Compatibility Matrix

Find out the version on WLC here by GUI: Go to Monitor and check the Controller Summary

 

Via CLI:

(WLAN1) >show sysinfo
Manufacturer's Name.............................. Cisco Systems Inc.
Product Name..................................... Cisco Controller
Product Version.................................. 7.0.240.0
RTOS Version..................................... 7.0.240.0
Bootloader Version............................... 4.0.191.0
Emergency Image Version.......................... N/A
Build Type....................................... DATA + WPS
System Name...................................... WLAN1
System Location.................................. Test Lab
System Contact................................... Sandeep
System ObjectID.................................. 1.3.6.1.4.1.9.1.828
IP Address....................................... 10.99.80.1
System Up Time................................... 3 days 23 hrs 12 mins 31 secs
System Timezone Location......................... (GMT +1:00) Amsterdam, Berlin, Rome, Vienna
Configured Country............................... DE  - Germany
Operating Environment............................ Commercial (0 to 40 C)
Internal Temp Alarm Limits....................... 0 to 65 C
Internal Temperature............................. +42 C

 

Part 2 coming soon……. 🙂

Login Banner on WLC

Here is the way to create a login banner on WLC by GUI or CLI. Normally its supported from software release 6.0 or later releases. The login banner is the text that appears on the page before user authentication when we access the controller GUI or CLI using Telnet, SSH, or a console port connection.

***We save the login banner information as a text (*.txt) file. The text file cannot be larger than 1500 bytes and cannot have more than 18 lines of text.

*** We can only have one login banner on WLC. If we download the 2^nd Loogin banner on WLC then it will remove the first means overwrite the 1^st one.

Here is the example of my banner:

 Hey Sandeep, Please study hard and read as much cisco technote to crack CCIE wireless.

Only few days Left!

First we will use the GUI and CLI method to download login Banner on WLC.

Via GUI:

Step1: We must have a TFTP/FTP server running.(Note down the IP address of the server).
Step2: Put the login banner text file in TFTP/FTP server default directory.
Step3: Login to WLC.
Step4: Go to Commands > Download file
Step5: Enter these details:
File Type:  Login Banner
Transfer Mode: TFTP / FTP
IP Address of Server (TFTP/FTP): 10.xx.xx.7
Maximum Retries: 10 (Default is 10)
Timeout (Seconds): 6 (Default is 6)
File Path: (we can enter the file path here from TFTP/FTP directory or leave empty)
File Name: Loginbanner.txt

***If we use FTP then we must enter username and password.

Service Port Number: Enter the port number on the FTP server through which the download occurs. The default value is 21.

Here is the screenshot:

Step 6 Click Download

We must reboot the WLC with save and reboot button.

Here is the output:

 

 

Via CLI:
Here is the command line way to configure login banner on WLC.
Log into the controller via CLI.

Specify the transfer mode

transfer download mode {tftp | ftp}

Download the controller login banner by entering this command:

transfer download datatype login-banner

Specify the IP address of the TFTP or FTP server

transfer download serverip server-ip-address

Specify the name of the config file to be downloaded command:

transfer download path server-path-to-file

Specify the directory path of the config file

transfer download filename filename.txt

If we are using a TFTP server

transfer download tftpMaxRetries retries
transfer download tftpPktTimeout timeout

If you are using an FTP server, enter these commands:

transfer download username username
transfer download password password
transfer download port port

To start this download:

transfer download start

Here is the live action from WLC:

(WLAN1) >transfer download mode ?
tftp           Enter mode: tftp.
ftp            Enter mode: ftp.
(WLAN1) >transfer download mode ftp
(WLAN1) >transfer download datatype ?
code           Download an executable image to the system.
config         Download Configuration File.
eapcacert      Download a eap ca certificate to the system.
eapdevcert     Download a eap dev certificate to the system.
icon           Download an executable image to the system.
image          Download a web page logo to the system.
login-banner   Download controller login banner. (Only Text file supported: Max 1500 bytes & 18 lines, Non printable characters not supported)
signature      Download a signature file to the system.
webadmincert   Download a certificate for web administration to the system.
webauthbundle  Download a custom webauth bundle to the system.
webauthcert    Download a web certificate for web portal to the system.
(WLAN1) >transfer download datatype login-banner
(WLAN1) >transfer download serverip 10.xx.xx.7
(WLAN1) >transfer download filename Loginbanner.txt
(WLAN1) >transfer download tftpMaxRetries 10
(WLAN1) >transfer download tftpPktTimeout 6
(WLAN1) >transfer download username anonymous
(WLAN1) >transfer download password anonymous
(WLAN1) >transfer download port 21
(WLAN1) >transfer download start
Mode............................................. FTP
Data Type........................................ Login Banner
FTP Server IP.................................... 10.xx.xx.7
FTP Server Port.................................. 21
FTP Path.........................................
FTP Filename..................................... Loginbanner.txt
FTP Username..................................... anonymous
FTP Password..................................... *********
This may take some time.
Are you sure you want to start? (y/N) y
FTP Login Banner transfer starting.
FTP receive complete... checking login banner.
Successfully installed new login banner file.
(WLAN1) >

To clear this login banner we have two ways GUI and CLI.

Via GUI:

Go to Commands > Login banner

Then click on Clear, when prompted then click ok.

Via CLI:

To clear the login banner via CLI just use this command:

(WLAN1) >clear login-banner

That’s it for today. Wait for next post.

Roaming / Mobility Basics

Mobility, or roaming, is a wireless LAN client’s ability to maintain its association seamlessly from one access point to another securely and with as little latency as possible. In This post I will try to elaborate how mobility works when controllers are included in a wireless network.

Or

In wireless networiking , roaming means to the ability to move from one AP coverage area to another without interruption in service or loss in connectivity. This is the key component in wireless network deployment.

Mobility Groups:

A mobility group is a set of Wireless LAN Controllers, by the same mobility group name, that defines of seamless roaming for wireless clients. By creating a mobility group, we can enable multiple WLCs in a network to dynamically share information and forward data traffic when inter-controller or inter-subnet roaming occurs. Controllers in the same mobility group can share the context and state of client devices as well as their list of access points so that they do not consider each other’s access points as rogue devices. With this information, the network can support inter-controller wireless LAN roaming and controller redundancy.

Roaming is the action for a Wireless client to move from one AP to another AP while actively transmitting data without any interruption.

For Voice WLAN: It very common to have roaming.

For Data WLAN: For data deployment, it can be nomadic; user can get slight interruption while moving from one coverage area to another without impacting the user experience.

When a wireless client connects and authenticates to an AP, the AP´s controller (where AP is connected) put an entry for that client in its database, which contains the information of client like: Mac address, IP address, WLAN associate with and the AP where client is connected…etc.

If we have the controller based deployments then Roaming can be of three types.

1. Intra(All AP on same controller)
2. Inter or layer 2(Different controller with same network means same subnet)
3. Layer 3 (Different controller with totally different subnets)

 

 Intra Controller Roaming:

• Intra controller roaming is the roaming between LAP’s managed by the same WLC, obviously in the same IP subnet.
• It is necessarily about the subnets that the clients are using that are serviced by the APs.  So, let’s say we have 2 APs, both of which are servicing a specific IP subnet.  When client roam from one AP to the other, which is layer 2 roaming.  The client still maintains its IP address.
• Wireless Clients move from one AP to another AP in same controller.
• When client moves its association from one access point to another, the controller simply updates the client database with the newly associated access point.
• This entry includes the client’s MAC and IP addresses, security context and associations, quality of service (QoS) contexts, the WLAN, and the associated AP.
• Sometimes it does also establish the new security context means if during roaming a clients session timeout or key change occurs then this information should pass to WLC. If we have open authentication then WLC don’t need to establish or update security Context.

AP: Encryption and Decryption

WLC: Mobility, QoS and Security Management

• This Roaming process take less then 10ms (It almost seamless).

Lab result and logs will follow soon……………………………………………..

Layer 2 – Inter Controller Roaming:

 

Now when we do a layer to roam and multiple controllers are involved, then both controllers need to service the same subnet.  This would mean that we have a dynamic interface in subnet x configured on WLC1 and another interface that is also configured on subnet x on WLC2.  This would be Inter controller roaming (Layer 2).

•  The wireless user moves from one AP to another AP connected to another controller in the same subnet (as the first controller).
• It means that the client is roaming between two different controllers, but, these controllers can be part of the same Mobility Group and the same subnet.
• When the client tries to join the new AP, both controllers exchange the client details (database entry and credentials).
• The new WLC exchange mobility message with the original WLC and the client entry is moved to new WLC.  This entry includes the client’s MAC and IP addresses, security context and associations, quality of service (QoS) contexts, the WLAN, and the associated AP.
• Client database entry is updated for the new access point. This process takes less then 20ms and remains transparent to the user.

Lab result and logs will follow soon……………………………………………

Layer 3 – Inter Controller Roaming:

 

The wireless user moves from one AP to another AP connected to another controller in a different subnet or if the clients roam between APs registered to different controllers and the client WLAN on the two controllers is on different subnet, then it is called inter-controller L3 roam.

• It’s similar to inter subnet roaming.
• Controllers exchange mobility messages on the client roam. However, instead of moving the client database entry to the new controller, the original controller marks the client with an “Anchor” entry in its own client database.
• The database entry is copied to the new controller client database and marked with a “Foreign” entry in the new controller.
• The main advantage is clients maintain its original IP address even after changing the controller.
• The process takes less than 30 ms.
• The roam remains transparent to the wireless client. 

Lab result and logs will follow soon……………………………………………