With Jeal Jimenez
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about about how to implement, configure, and troubleshoot WLAN security with expert Jeal Jimenez.
Our expert will also discuss how WLAN security works and the different security methods that are available and implemented on enterprise WLANs to validate clients and protect their traffic along with the network.
Jeal Jimenez is a customer support engineer for the Cisco High-Touch Technical Support department specializing in wireless LAN technology. Prior to joining the HTTS department, he worked as a customer support engineer focused on wireless LAN in the Technical Assistance Center before he was promoted to an escalation leader and trainer, working also as a Cisco lab admin during these years. Jeal's technical expertise in the area of wireless LAN technologies spans more than seven years, and he also contributed to Cisco documentation and to the CCIE Wireless written exam. He holds a bachelor's degree in systems engineering from Universidad Latina in Heredia, Costa Rica. Jeal also holds the certifications CCNA, CWNA, CWSP, CCNP, and CCIE wireless (# 31554).
Remember to use the rating system to let Jeal know if you've received an adequate response.
Because of the volume expected during this event, Jeal might not be able to answer every question. Remember that you can continue the conversation in the Wireless - Mobility community, subcommunity, Security and Network Management, shortly after the event. This event lasts through October 18, 2013. Visit this forum often to view responses to your questions and those of other Cisco Support Community members.
I am now in my preparation for CCIE security LAB v4. While going through the details i came through about Wireless seurity parts. So would you mind to please suggest some tips to corelate this for my preparation ?
I am not completely aware of the Wireless security topics covered by the Security CCIE, but checking the Lab blueprints and software/hardware list, I will say that you should know how to deploy secure authentications on a WLAN using a CUWN (Wireless LAN Controller and Lightweight APs), with an ACS or ISE as the Authentication Servers; this means:
- Learn about how to configure on the WLC some WLAN/SSIDs for 802.1X/EAP authentication methods with WPA or WPA2 (for key management, using TKIP or AES-CCMP for encryption), defining ACS or ISE as the RADIUS Server.
- Understand the differences between the multiple types of EAP authentication methods that you could deploy for a WLAN (such as LEAP, PEAP/EAP-MSCHAPv2, PEAP/EAP-GTC, EAP-TLS, and probably EAP-FAST with different inner method types). Some methods authenticate clients with username/password credentials, some with client certificates, some only use server side certificates to tunnel/encrypt the client credentials’ handshake, some could do machine authentication or multifactor authentication, etc. So depending on the requirements, you might need to deploy the appropriate EAP method, which might involve PKI.
- Learn how to configure the settings for those EAP authentication methods (including certificates installation) on the client side (wireless IP Phone or AnyConnect Client or perhaps Windows supplicant) and on the ACS/ISE side. The following is just one possible configuration example for you to start getting some hands-on on this topic:
- You might need to be familiar with most of the BYOD deployments possible on WLANs using the ISE, so you could start with the following guide to understand what I am talking about:
- I will say that you should be also familiar with Layer-3 Web Authentication for guest users using an ISE, such as in the following examples:
- In addition, it seems you should be familiar with wireless IPS (remember there are multiple attacks and threats to the network that can only happen over the air or with WLAN equipment, and only be detected/mitigated by wireless IDS/IPS). Therefore, I will recommend you to check the “Cisco Adaptive Wireless Intrusion Prevention System Configuration Guide” to get familiar with this topic:
- Regarding this topic, a WLC can also be integrated with wired IPS to mitigate some attacks coming from the WLAN that don't really need wIPS, so you might want to check if this wired IPS solution is valid for your exam version:
Hope this can help you with your studies! Wish you the best on your CCIE journey!
Many thanks for these many information. i can say you that definitely i was missing some good stuffs which i was not aware (like wireless IPS). I will go through all you mentioned URLs for docs and definitely will revert with my next concerns .
What recommendations do you have to troubleshoot a WLAN where the authentication is failing? Thanks for your help on this.
I think the best way to troubleshoot an authentication issue is by first understanding the process of the security method implemented, so let me summarize how 802.1X/EAP works, as this is basically the authentication framework implemented on WLANs:
*** Components ***
- Authentication Server: For WLANs this is a RADIUS Server where the authentication of the wireless clients actually takes place (ACS, ISE, Windows NPS, etc.). Here you define the specific EAP method that you want to allow and its settings (certificates, policies, etc.). Here you also have a local database with the client´s credentials to be checked, or it could be linked to an external database.
- Authenticator: This is the WLC/AP, and the role is basically to act as a "proxy" between the wireless client to be authenticated and the RADIUS Server that performs the authentication. Here you configure the SSID to force dot1X/EAP negotiation with the wireless clients trying to associate to this WLAN (using a specific key management and encryption method, like WPA/TKIP or WPA2/AES), and you define the RADIUS Server that will be used for this authentication.
- Supplicant: The wireless client trying to connect to the secure WLAN. Here you configure the SSID profile that will be used for the association to this WLAN. You define the specific EAP method, and the client security credentials (username/password, certificates, tokens, etc.).
*** Process ***
- The wireless client starts the association to the WLAN using the specific SSID and selecting an AP to connect.
- Once basic wireless association is successful, WLC/AP sends an EAP identity request to the client in order start doing 802.1X/EAP.
- The wireless client should answer back with an EAP identity response.
- This response is sent from the WLC/AP to the RADIUS Server on a RADIUS Access-Request packet.
- RADIUS Server processes the request and it replies back with a RADIUS Access-Challenge to start the EAP negotiation with the client (basically offering the client to start doing the EAP method that was configured for the wireless security policy).
- WLC/AP receives this Challenge, and forwards it to the client as an EAP request.
- Client answers back with an EAP response, which is forwarded by the WLC/AP to the RADIUS Server on another Access-Request. From here, the same exchange will happen multiple times between the server and the client (using the WLC/AP as intermediary) while the EAP method is negotiated and credentials are validated/authenticated. Depending on the EAP method we will see more/less exchanges, but in the end, the server should send to the WLC/AP a RADIUS Access-Accept if it passes or a RADIUS Access-Reject if it fails.
- The WLC/AP will inform the client about this result and deauthenticate it from the WLAN if it failed, or allowing it access to the network so it can start passing data traffic (client asking now for an IP address for example, as layer-2 is fully established now).
*** NOTES ***
- EAP is not a specific authentication method, it is just the name of the base protocol. Based on this, a specific EAP method is configured depending on our needs, requirements, and what the devices support (such as LEAP, PEAP/EAP-MSCHAPv2, PEAP/EAP-GTC, EAP-TLS, EAP-FAST/MSCHAPv2, EAP-FAST/TLS, EAP-FAST/GTC, etc.).
- This EAP method is only defined on the client (supplicant) and RADIUS Server (Authentication Server). Not on the WLC/AP (Authenticator).
*** Troubleshooting ***
Knowing that, without the need of understanding all the details about the specific EAP method deployed or about WiFi, you can easily Troubleshoot a WLAN authentication issue as follows:
1) First of all, check if the issue is happening to multiple clients/devices. If this is only happening to one, then more likely the issue is with the credentials of that client, or with the supplicant SSID setup on that client for the specific EAP method (or with the device itself, hardware or software).
2) If you confirm this is happening to multiple clients, then select one or two to troubleshoot. Check if the client is trying to connect to the SSID. If it is not even trying, the SSID is more likely not properly configured on the WLC/LAP.
3) Check the WLC/AP client association table so you can see the client status, if it is even trying to connect and what the status is. For example, on a Cisco WLC you will notice that the client is stuck on the authentication process because the client status will be 8021X_REQD.
4) If you noticed that the client is trying but failing or stuck on the authentication phase, then immediately check the failed attempts (failure authentication logs) on the RADIUS Server.
5) The server logs should normally tell you the reason of the authentication failure, but if you don´t see any attempts at all, then there could be an issue between the WLC/AP and the server. If there are failures on the server, the reasons are normally: EAP method not defined or not properly configured on the server or the client, wrong credentials, request is not matching the security policy defined, RADIUS Server has an issue with the external database (if used), RADIUS Server doesn´t know the WLC/AP trying to talk to it (it should be configured as AAA client -NAS- with a valid shared secret), the EAP method defined requires certificates from a CA (at least on the Server) and this is not properly setup... The server logs should normally be clear on the specific reason.
6) If you can´t find any logs at all on the server for attempts from this client and you know the WLC/AP is properly configured to communicate with this specific RADIUS Server, then there could be an issue between the WLC/AP and the server, so you might want to check network connectivity between them (proper routing, no ACLs/firewall blocking RADIUS traffic, no fragmentation issues, etc.). At this point, you could start this network troubleshooting between the Authenticator and the Authentication Server, but you could also start some debugging on the Authenticator, as this will clearly confirm if the problem is on the WLC/AP itself, in the client side, or in the server side, as you should see IF:
- The WLC/AP even started with the EAP identity request or not.
- If the client is responding or not.
- If the WLC/AP is sending the request to the proper server or not.
- If the server is responding (and how) or not.
- If this response is forwarded to the client and if the client is responding, and then forwarded back to the server... Until the point you notice a failure due to a lack of response from the client, from the server, or because the WLC/AP is not forwarding what it should where it should. You could even check if the failure is happening during the key management negotiation (which normally happens due to software issues if the client actually supports the one configured on the WLC/AP).
- On a Cisco WLC, you could use the following debugs:
debug aaa all enable
- On Autonomous IOS APs, you could use the following debugs:
debug radius authentication
debug dot11 aaa authenticator process
debug dot11 aaa authenticator state-machine
7) After this, you will definitely focus your troubleshooting on the WLC/AP, the client side, or the server side, checking deeper connectivity between them (packet captures if needed), the settings of the specific EAP method defined on the client and the server, or looking for software issues due to bad behaviors on any of the three components.
Apologies if this is too long, but I hope it is clear enough to deal with these type of issues.
I am glad to know it was helpful!
If further questions arise about that (the process or troubleshooting), please feel free to ask.
PS: If you want to get more details about the authentication process, checking wireless packet captures and WLC debugs, including details about the processes when roaming or when Fast-Secure roaming with any of the supported methods, I will recommend checking the document I posted recently about "802.11 WLAN Roaming and Fast-Secure Roaming on CUWN" (let me know if there are also questions about this):
I was wondering if the Web Auth Redirect URL configured in the WLC can point to an ISE Administration Node (PAN) instead of a Policy Service Node (PSN).
That is not possible, as the Policy Service Node (PSN) is the only node type (ISE Persona) that communicates with the Network Access Device (the AAA Client, in your case the WLC, using RADIUS protocol) to provide the network access, posture, guest access, client provisioning, and profiling services... Basically, this is the ISE Node/Persona that actually evaluates the policies for the requests coming and makes all decisions based on that.
The ISE Administration Node on the other hand, is the ISE persona that allows you to perform all administrative operations on the ISE itself, handling all ISE system-related configurations regarding the functionality of the services it provides. So this is basically the Node for the Administration of the ISE, not to validate the policies configured on the ISE (as this is handled by the PSN as mentioned above).
Just to clarify my question and based on your answer, the ISE Admin Node would not have the Web Portal feature activated (see picture below) therefore the following steps for Web Auth can not be completed using this Node as Web Auth Redirect URL Server configured in the WLC because it wont work as external web server and could not send the request back to the action_url including credentials, right?. (please assume Web Auth in the picture below instead of MAB).
As already briefly explained, the utilization of an external WebAuth server is just an external repository for the login page. The user credentials are still authenticated by the WLC. The external web server only allows you to use a special or different login page. Here are the steps performed for an external WebAuth:
The client (end user) opens a web browser and enters a URL.
If the client is not authenticated and external web authentication is used, the WLC redirects the user to the external web server URL. In other words, the WLC sends an HTTP redirect to the client with the website's spoofed IP address and points to the external server IP address. The external web authentication login URL is appended with parameters such as the AP_Mac_Address, the client_url (www.website.com), and the action_URL that the customer needs to contact the switch web server.
The external web server URL sends the user to a login page. Then the user can use a pre-authentication access control list (ACL) in order to access the server. The ACL is only needed for the Wireless LAN Controller 2000 series.
The login page takes the user credentials input and sends the request back to the action_URL, such as http://188.8.131.52/login.html, of the WLC web server. This is provided as an input parameter to the customer redirect URL, where 184.108.40.206 is the virtual interface address on the switch.
The WLC web server submits the username and password for authentication.
The WLC initiates the RADIUS server request or uses the local database on the WLC, and then authenticates the user.
If authentication is successful, the WLC web server either forwards the user to the configured redirect URL or to the URL the client entered.
If authentication fails, then the WLC web server redirects the user back to the customer login URL.
This may be a broad question but in general what type of securtiy measures and monitoring would you consider best practice? I have 5508 controllers and I did not pay for the enhanced WIPS capabilities but I am utilizing the built in WIPs functionality of the controllers and I am inundated with security alerts such as "broadcast probe flood" or "deauth flood" as examples. When I read the forums every security alerts leads down the path of contacting TAC and TAC indicating this is probably a false positive. I have my wireless networks firewalled. I have setup industry best practive encryption and authentication, so my question is does the WIPS provide much value? Does Cisco monitor and taking action or investigate these type of alerts internally? I posed this question to other Cisco contacts and I haven't been able to get much information.
Let’s talk a bit about wireless threats/attacks and wireless IDS/IPS, and if this doesn’t address your concerns, please let me know so we can expand the discussion…
- There are multiple threats/attacks that can happen over the air and your wired IDS/IPS/firewall can’t really do anything about them; not even firewall rules on the wireless devices. For example, a wireless device can attack your WLAN by sending deauthentication frames to all or some of the wireless clients ("deauth flood”) connecting to a specific AP, so this attack will easily keep disconnecting the clients (basically causing a DoS attack because your wireless clients will continue dropping the WLAN). How does the attacker do this? Wireless clients should accept/follow any “instruction” from the AP they are connected to, so if the AP asks them to disconnect the WLAN/SSID using a deauthentication frame, they should follow this request and disconnect. So the attacker’s trick is to impersonate the AP by sending all these deauthentication frames on behalf of the AP, which is easily done by finding the AP’s MAC address with some wireless packet captures. An attack like “broadcast probe flood” can be a device/attacker sending multiple probes to an AP, forcing it to send probe responses to those multiple requests (as the 802.11 standard defines that the APs should answer back with a probe response when a client is looking for an AP. There are actually multiple attacks that can be done based on the way WiFi works to establish initial associations, where AP should answer back to clients trying to connect/authenticate), consuming not only AP resources but also channel/RF resources (leading to another possible DoS attack).
- So basically, these attacks are happening only over the air without ever touching the wired infrastructure; these “attack” frames are not traveling through any of the infrastructure devices (not even over the AP, or WLC, or firewall), so they can’t be avoided or blocked. For example, on the "deauth flood” the attacker simply directs the frame from its machine to the wireless clients by sending a deauthentication frame over the air on the specific channel used by the impersonated AP. For such an attack, we could say that there is nothing that can be done from the infrastructure perspective, as we can’t stop a device that is not even connected to the WLAN to continue sending deauthentication packets over the air to the clients. However, there is a feature called Client MFP (Management Frame Protection) that could avoid this attack (by having the clients ignoring these frames that can’t be avoided) as the deauthentication frames from the “official” AP are secured and you don’t need a wIPS to implement this, but the limitation is that you need some specific requirements to enable this on a WLAN/SSID (specific security, and wireless clients Must support this as well). The following document explains this feature:
- Some other attacks where the attackers “flood” the AP/WLC with multiple authentication attempts (perhaps doing dictionary attacks to some credentials trying to connect to a secure network, or simply trying to cause a DoS attack to the WLAN) can also be mitigated with just the WLC (without the Adaptive wIPS) by enabling the client exclusion feature, where these devices will be excluded from trying to connect to the WLAN (WLC/AP will simply not respond to these excluded devices) after failing the authentication a certain amount of times. This applies to excessive 802.11 authentication and association failures, 802.1X authentication failures, Web-Authentication failures, or even IP theft or IP reuse.
So what do you get with the Adaptive Wireless IPS solution if your WLCs are already detecting attacks by just having the managed APs monitoring the air to find attacks with behaviors matching the signatures already implemented on the internal WLC IDS/IPS?
- First of all, there are a few signature updates that can only be deployed with the Adaptive wIPS, so some attacks might not be recognized by the WLC’s signatures.
- The Adaptive wIPS involves the Cisco MSE with the WCS/NCS/PI, where you might be able to track the attackers’ estimated locations using the maps configured here and Cisco’s location/wIPS technologies.
- In addition, you might be able to better monitor the attacks (with alarms and even email notifications).
- You could even avoid duplicate attack notifications by multiple WLCs, as they will be all working with the MSE to recognize that the attack reported by one WLC is the same that another reported. Now, even if you don’t have Adaptive wIPS and MSE, all your WLCs managing APs that can hear APs from other WLCs, should be configured within the same mobility/RF group and with the same wIPS policies; otherwise, your own WLCs might be reporting false alarms based on what is happening on your other APs/WLCs.
- The following "Cisco Adaptive wIPS Deployment Guide 7.4" should give you more details:
- As you could imagine, some wireless attacks can’t be avoided at all. Going back to the "deauth flood” example, you can’t stop an attacker to continue sending frames over the air affecting clients that can’t do MFP, as you can’t control the AIR (such as you will control your Internet link traffic with a Firewall for example).
- Adaptive wIPS can’t stop such attacks either, however, you might be able to find the attackers location so you can go and find him/her to take appropriate actions against the actual person (yes, not a networking/technology response, but a task for a human :-)).
- On very crowded environments and with multiple types of wireless clients, some attacks could be actually a false alarm due to multiple clients just trying to connect to a WLAN that they can’t join due to security, or even just because there are wireless clients with software/drivers issues (for example, sending probes like crazy, and not really actively trying an attack). Remember the attacks are “recognized” based on signatures, so the behaviors here might be reaching the signatures frequency within the specific intervals, triggering the alarms.
- There are also possibilities that your WLAN could be attacked by a neighbor’s infrastructure WLAN. For example, our WLCs support a feature called AP Containment, where we will “attack” a malicious Rogue AP (for example, an unofficial AP connected by someone to one of your switchports). The way this works is that the WLC’s LAPs around this Rogue AP will start sending deauthentication frames to the clients trying to connect to this Rogue AP (basically doing the attack explained above), so we can avoid having clients connecting to this malicious Rogue and avoid them access to your network. The problem is that a WLAN administrator might be mistakenly attacking another company’s APs thinking that they are malicious Rogue APs, so you might want to check that this is not the case on your network (here, wIPS can’t do anything for you either; you will need to go and talk to the WLAN admin of your neighbors… Another task for a human).
- In the end, how can you confirm that there are actually some of these attacks happening on your RF environment? Some wireless packet captures will definitely tell the truth (taken around the AP reporting them and sniffing the channel reported), showing all those possible attack frames and behaviors.
Hope this can help!
That does help to some degree because it backs up my assumptions that most of the security alerts are if anything DDOS attacks or mi-interpreted trafic, but do you have any feedback on the fact that a lot of the events tend to be false positives? I get events that turn out to be my own clients and they are not doing any sort of attack indicated in the security alert email I get. If you search the forums in most cases people report TAC told them its a false positive and to tune the signature which in some cases is not very configurable.
Also I do already have an MSE and I get email alerts from prime infrastructure 1.3 and I have context licenses to track location I just don't get the additional signatures that comes with the Adaptive WIPS licenses but either option (basica or adaptive) are their really any non RF DDOS type attacks? Without having the dictionary of signatures in front of me I don't remember them all, but are there any signatures I should be more concerned with? And regardless of adaptive WIPS or basic WIPS does either really help security other than from DDOS perspective? I see DDOS almost essentially like a performance concern or reliability concern where if I see an issue my troubleshooting would start with looking at the affected AP looking for continuous transmitters and then security events. I am less concerned with DDOS. I am more concerned some device getting unauthorized access.
I am being asked by my team can we shut off these annoying security alerts and I am finding it harder and harder to find a good reason not to at least from an email perspective. If I am having a performance issues then I would then look for continuous transmitters or DDOS attacks. I tried turning on MFP initially and had issues with that to where it didn't look like a road I wanted to go down ensuring client compatibility.
I am also already using the exclusion feature to block clients after multiple failed attempts. I am planning on integrating out wired infrastructure into prime 2.0 so that I can ensure that no authorized AP are broadcasting on our network. Am I missing anything do you have any other suggestions for security? On thing we currently don't have is wired IPS on the wireless infrastructure, but we do only allow corporate boxes with anti-virus on corporate wireless.
I will need to do some troubleshooting to confirm that they are actually false positives, confirming the specific "attack" type and if it is actually a valid client as clients can also be impersonated like APs (perhaps getting some packet captures and checking the client behavior during the period the attack is reported)... But I can definitely tell you that some crowded environments and bad client behaviors could generate these false positives (bad client software/drivers as mentioned before, or bad client setup with credentials that keep failing to connect, or that decide to send deauthentications/dessasociations to leave the WLAN, or that send multiple probes just because they have a lot of WLAN profiles configured/learned or a software installed for this, etc.).
The document I shared about the wIPS deployment guide has some tables with the specific features and signatures added with the Adaptive wIPS or even with CleanAir APs, so I will recommend checking that for a more detailed list. What I can tell you is that most are related to DoS attacks as you mentioned, but remember that some of them could be related with actual threats to the network (for example, dictionary attacks trying to guess the password for some of your users, so they can then get access to your network using valid credentials).
Those "dictionary attacks" can be avoided with the exclusion feature, so you don't really need Adaptive wIPS for this.
- If you are not really concerned about those type of "wireless/RF specific attacks" (most of them DoS, as they basically attack the RF and 802.11 behaviors), then it is up to your security policies if you want to configure your setup to continue reporting these alarms or not.
- Also, if you already have a very good security implemented for your WLAN (strong EAP authentication tunneling the credentials or using certificates for example, and with WPA2 for key management encrypting with AES-CCMP), then I would say that your WLAN is secure enough and real attacks (other than DoS or password guess) can't really happen to your network from the wireless infrastructure (yes, WLANs are this secure nowadays if using proper authentication/encryption), but I would need to analyze your entire deployment and security policies (penetration tests) to confirm that you are completely secure
- Firewalls or wired IPS, or even WLC's Applications Visibility should be able to analyze traffic for valid clients already connected to the network if this is a concern (excluding the client as well or dropping traffic if needed; this doesn't need Adaptive wIPS).
If you want to share more details of your WLAN to get more feedback or if I didn't address some of your concerns, please feel free to let me know.
Please help me with this scenerio:
- I have WiSM2 in 6509-E, I have configured 4 SSID
- I want that some users can login to WiFi network only with one device per-time. I know I can set it globaly on the WLC - Security > User Login Policies. change that value from 0(unlimited) to 1.
- But I need VIP users can login with more than one device per-time. In add, in one SSID we don´t need the restriction for number of devices.
Thanks in advance.
As you have noticed, the User Login Policies feature on the WLC is the one we have for this type of Max-Sessions restriction per user; however, this is a global setting and applies to all SSIDs, so there is really nothing that could be configured on the WLC to do exactly what you need.
What I can tell you is that you might be able to achieve this specific setup that you need (basically based on SSID, with Max sessions configured for some SSIDs and unlimited on the VIP SSID) but configuring the restrictions based on policies on the Authentication Server side. I remember this was possible on ACS 4.x and probably 5.x using SSID restrictions, but as far as I know, this is only possible on ISE for the guest users...
So if you have a Cisco RADIUS Server, I will recommend you to open a TAC case with the AAA team asking for assistance to setup this specific restriction based on your needs. If it were not supported on the specific server/version you have, you might be able to ask for the feature (in this case you could also get in touch with your Cisco account team to drive a Product Enhancement). If you are using a third-party RADIUS Server to perform the authentication on your WLANs, then I will recommend checking their documentation (or contacting their support) to check if this type of Max-sessions per user restriction is possible on their server.
Is there a way to deploy Radius authentication using Microsoft 2003 or 2008 server(Only IAS/NPS) without installing any certifiacte on Server side.
What type of security types does controller supports(eg EAP-TlS,EAP-TTLS, MsCHAPv1 etc)
Is it possible to use CHAP or MsCHAP without using PEAP(without using them as inner method.)
I will recommend you to read the second answer I provided on this event (Oct 7 answering to Evan), so you can better understand how secure authentication (802.1X/EAP) works on a WLAN.
To answer your specific question, no, you can't really deploy any authentication method for WLANs on the Windows 2003/IAS or Windows 2008/NPS servers without using certificates.
That is basically because those Windows servers only support EAP methods for WLANs (PEAP and EAP-TLS) that require certificates at least on the server side; hence the requirement of the PKI to have a CA issuing at least the server certificate (good news is that you normally use the same Windows server as the CA).
EAP-TLS requires the certificate on the server and on the clients since they will be authenticated based on this type of client credentials (a certificate).
PEAP can authenticate the clients using other type of credentials (such as AD username/password), but the certificate on the server is still required as this one is used to build a TLS tunnel between the client and the RADIUS Server in order to protect the client credentials during the authentication handshake (the P on PEAP actually stands for protected: Protected EAP; hence the server certificate, to protect the client credentials on a TLS tunnel).
You don't really need to worry about what type of authentication method is supported by the WLC, as this is not actually defined or limited by the Authenticator (we could say that the WLC/AP don't worry about the authentication method), but as I explained to Evan on my other answer, the specific authentication method to be used is defined on the wireless client and the RADIUS Server... So the question here is about what 802.1X/EAP authentication methods are used on WLANs, and mainly what methods are supported by your RADIUS Server and the supplicant of your wireless clients (the limitation about the EAP method to be used is actually found here).
can you please tell me if I need two AP licenses if I have two
AIR-CT2504-HA-K9 working in HA mode?
Do I need additional software for HA (Prime NCS) or is the included software enough?
Yes as 2504 only supports n+1 HA and does not support AP sso.
If you plan on making other controller as backup you need another licence.
Please check document given below for N+1 HA licensing.
Q. What behavior can I get with the -HA SKU on the Cisco 2504 Wireless Controller (CT2504)?
A. Starting 7.5, the HA SKU on the Cisco 2504 can operate only in N+1 mode. It does not support access point or client SSO.
And please post question in correct discussion, this is WLAN security discussion.
if I have one AIR-CT2504-15-K9and one AIR-CT2504-HA-K9which can work only as secondary/backup WLC
then I don't need an second license?
Standby Controller Licensing
Do I need to buy access point licenses on my standby controller?
A. No. When the active controller is unavailable, the standby controller will adopt the licenses from the primary controller. It is expected that the customer will be able to get the primary controller back online within 90 days. After 90 days, the customer will get a daily reminder to switch back to the primary controller."
Even when the 2500 WLC can't really do AP/client SSO HA, the 2500 HA SKU (AIR-CT2504-HA-K9) can be purchased to be used as the secondary/backup WLC on the N+1 HA setup mentioned on the document you referenced.
So regarding your specific question, no, you don't need any license on the 2500 HA SKU as the HA part is already licensed from factory to support the maximum amount of APs for the specific WLC model (as it is supposed to be used as a backup, so that's why you get the reminder about switching back the APs to the primary WLC, which is the only controller that should have a license for the specific amount of APs that you need).
Just a reminder because you shouldn't be using this HA WLC as the only primary WLC for your APs... But the WLC won't stop working after this period.
i've got a upcoming poc for a guest access solution and the scenario looks like this:
Guest Access with Captive Portal -> Internet only
Internal users with Captive Portal -> Internet only
Here is the deal:
How to avoid the reauthentication for internal users and stop them from using their private phones?
One idea was an MDM integration with Cisco ISE and check if the devices are registered in MDM, but i guess with an CWA "sleeping client" doesnt work ?!
The other idea is to make whitelist on Cisco ISE but how to keep it updated without alot of work?
5508 controller 7.5
Thanks in advance
Sent from Cisco Technical Support iPad App
Sent from Cisco Technical Support iPad App
When you say simple and your talking about NAC and MDM policies with personal devices I don't think you can use simple in that discussion. Especially not if your controlling a personal phone let alone a business provided phone. I actually use a third party radius (nac) but I am sure ISE can do the same thing where you use its profiling capabilities to determine if the device is corporate or personal. What are you planning to manage on personal devices are you going to tell them what they can and cannot install? Do you need to do that if it is internet only? We provide internet only and we do not manage personal devices.
I honestly don't have too much experience with all the features and possibilities available on the ISE, so I am actually struggling with this request, but I will share my thoughts about this...
First, I am not sure if the sleeping client feature will affect this setup when trying to do it with MDM integration; I don't see why this should be a problem, so you could try it.
Regarding a whitelist on Cisco ISE, this is definitely a possibility, but surely a lot of work that can't be avoided unless you can do something like this:
Configure the MAB_Auth policy for the wireless captive portal on the ISE to use also "Internal Endpoints". Once the policy is configured to match Internal Endpoints, then you just need to make sure that the Internal Endpoints for this policy are only the devices that you want to allow for the Internal users without permitting smartphones for example (based on Profilling).
Regarding your question about how to avoid reauthentication for Internal users, I am not sure if I understood this correctly, but you can't really avoid this since this would be a security issue; once the clients have left (after the sleeping client timeout for example), they are basically removed from the client's list, so they should reauthenticate to the Web-Auth portal if they later come back...
Thank you for your replies.
Only corporate devices will be managed. So with the integration of MDM in ISE i can filter the managed devices.
Private devices are not going to have any wifi.
We want to reduce the reauthentications. So sleeping client would be a nice feature to use. My concern is that when we use ISE and its captive portal that this feature is not going to work. Profiling could be a solution, but I'm not sure it will work a 100%.
Sent from Cisco Technical Support iPad App