Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Oisin Mac Alasdair about the deployment of a global enterprise WLAN. Oisin is the IT program manager responsible for Cisco's enterprise wireless strategy & architecture. A member of the Intelligent Network Solutions group in Cisco IT Infrastructure, he has been leading the wireless networking team for over six years. A co-author of the upcoming Cisco Press book "The Business Case for Enterprise Class WLANs", Mr. Mac Alasdair is based in Perth, Western Australia but leads a global team of wireless engineers & experts across Europe, North America and Pacific regions.
Remember to use the rating system to let Oisin know if you have received an adequate response.
Oisin might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through June 30, 2006. Visit this forum often to view responses to your questions and the questions of other community members.
I am trying to setup location manager in the WLSE. I would like to edit AP antenna placement on the foor view, but I do not know how to inform the WLSE that I am using wall-mounted AP1132? Antenna placement windows does not let me use other antenna than omnidirectional and WLSE device inventory will not allow me to pretend I am using a different AP type?
To our knowledge current version of ACS 4.0(1) does not support CRLs for
intermediate CAs. Is this true? When will this support be implemented?
(It is crucial to have support for CRLs in an environment where certificates
are used for authentication.)
Also, can you give any information, when WCS will support Rogue Ap e-mail alerts. We don't have Location Server, but it is crucial to have email alerts from Rogue AP in an enviroment as above.
Certificate Revocation Lists are supported on ACS 4.0(1). Go to 'System Config' and select 'ACS Certificate Setup'. Then choose 'Edit Certificate Trust List' and select an Intermediate CA and hit submit.
With regards to WCS, it does support email alerts for Rogue AP detection. Go to 'Monitor' and then select 'Alarms'. A new screen will appear. On the right hand side there is a drop down list with "select a command" on it. Select 'Email Notification' and press the Go button. A screen will appear listing the various alarms you can configure for email notification. "Rogue detection" should be the first one.
You can configure the From and To address, as well as the SMTP server.
Oisin Mac Alasdair
IT Program Manager
Intelligent Network Solutions
Thanks for answering. We will try the Certificate Revocation List as soon as possible.
The problem with WCS and email alerts for Rogue Ap without Location Server is, that Rogue Ap will appear as 'minor' alert, and only 'critical' alert will be forwarded as elami alert. I have understood that there are no way to change the alert from 'minor' to 'critical' by myself. Am I right. So is there anything to do ?
The 1132 access point has an embedded omni-directional antenna, and has no connectors for external antennas. As such, it is not possible to select anything except than the embedded omni-directional.
Using anything else would result in incorrect antenna settings and erroneous data in your location manager.
I am afraid we do not understand each other well. I have an installation, I had to use wall mounted AP1131AG's. This means, their RF radiation is not omnidirectional in the horizontal direction. So I understand that the WLSE knows only ceiling mounted AP1131AG's. Thank you for reply.
Right. So the current version of WLSE does not have any capability of showing the 1131AG as being wall mounted. I beleieve the BU has been asked for this feature in the past.
I recommend you contact your Account Manager and formally request this feature. If several customers request it, the BU may provide it in a later release.
I have a question about PEAP fast reconnect. We are using windows XP SP2 clients, Cisco WLC2006 controller version 3.2.150 and ACS version 4.0. When client moves from one AP to another AP (same controller), client can associate to second AP without entering password again. But it worked by windows cached credentials, not fast reconnect. From ACS logs and sniffer packets, ACS still tried to authentication the user without using ACS cached credentials, and the user group mapping still occured. What did I miss for fast reconnect?
To enable fast roaming, and thereby reduce the number of AAA authentication requests, you need to enable either PKC (Proactive Key Caching) or CCKM (Cisco Centralized Key Management).
Both of these features keep copies of the session key locally, obviating the need for the client device to reauthenticate every time it roams from AP to AP.
CCKM support was recently introduced in Version 4,0 of the Unified Wireless software.
Thank you for your reply! From the following cisco documentation(http://www.ciscoexpo.gr/2006/downloads/0802/vip/billot.pdf), CCKM Fast Roaming is only supported with LEAP and EAP-FAST. So we can not enable fast roaming with PEAP? But on ACS PEAP configuration and part, there is a "fast reconnect" option, this "fast reconnect" option is also available on windows xp PEAP client. Is this "fast reconnect" same idea as "fast roaming"? How can we use PEAP "fast reconnect"? I tried some tests and it did not work. Thanks.
Sorry, I think I misunderstood your first question.
Fast reconnect is *not* the same as CCKM or PKC. Fast reconnect is also known as "silent resume" and is a method to expedite authentication by caching TLS session keys. Please see http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/ns386/netqa0900aecd801764fa.html and Microsoft's technote at http://technet2.microsoft.com/WindowsServer/en/Library/3e94a25d-8922-4935-b248-540aa6b8c5101033.mspx?mfr=true
More details on how to configure PEAP fast reconnect (or PEAP silent resume) can be found at http://www.cisco.com/application/pdf/en/us/guest/products/ps430/c2001/ccmigration_09186a008025d6ba.pdf
It includes instructions on configuring ACS and the Microsoft PEAP (EAP-MSCHAP v2) supplicant (available in Windows XP SP1 and later and in Windows 2000 SP4).
Finally, please note that Cisco IT do not currently use PEAP on our internal WLAN and, as such, we do not implement fast reconnect.
We have installed a Verisign class 3 certificate on ACS 3.3 in order to provide Peap authentication on Wireless client. If we view the certificate when the Wireless client authenticate to ACS, it show the Verisign Intermediate certificate has expired (07/01/2004) (see attached file).
What strange is the following :
That intermediate certificate was installed on the ACS server as well with the site certificate and if we establish a SSL session with the ACS, we can view it Ok (the intermediate one that was installed on the ACS).
With peap the ACS is not sending the intermediate certificate as it do in SSL, so we got the error that the certificate is expired because in Windows Verign Class 3 Intermediate certificate is expired in 2004.
I was thinking that Peap will permit us to only install a certificate on the server without doing any change on the client side !?
Is that normal behavior or it is a bug in ACS Peap implementaion ?
is not sending all the certificates which was installed on the server.
Accessing the ACS server with SSL (HTTPS), all the certificate information are good. Intermediate certificate installed on ACS is send as well with the issued certificate.
Bug in ACS or normal behavior in Peap ?
Can you provide a bit more information please?
- does the cert show as expired in Windows using mmc + cert manager (i.e. ACS aside)?
- does the cert show as expired in ACS using system config -> cert setup etc (i.e. without attempting any connections)?
- are you using client certs as well as server ones?
Thanks for answering for my questions above. We will try the Certificate Revocation List as soon as possible.
The problem with WCS and email alerts for Rogue Ap without Location Server is, that Rogue Ap will appear as 'minor' alert, and only 'critical' alert will be forwarded as email alert. I have understood that there are no way to change the alert from 'minor' to 'critical' by myself. Am I right. So is there anything to do ?
In our own enterprise deployment we have configured the WCS to send email alerts only on "critical" rogues (ie, those the system believes are connected to the wire network and therefore of a high security concern).
I don't believe it is possible to opt for email notification on lower priority alerts. You would probably be inundated with mails in anycase.
You can always use a Location Server to dictate monitoring of a specific area.
You can see the print screen attached to that message. As you can see, the Verisign certificate class 3 is valid on the ACS until 24/10/2011. That date is the one we see when we established a SSL session with the server.
If we use Peap authentication with the same ACS server on the same PC client we see that it expired with a date of 07/01/2004 which is the date of that certificate on the client cert store.
Question are really: is that normal ? Why the Peap method is not sending the same certificate informations to the client PC that does SSL ?
Does lwapp controller support SSID restriction enforced by ACS server ? If no what the trick to enforced that ?
Yep, the LWAPP controllers support SSID restriction. Cisco IT do not implement this feature.
We have defined four SSIDs on our enterprise WLAN.
2 SSIDs for production data
(1 with WPA2 enabled, and 1 with CKIP for legacy devices. This second SSID will be retired soon)
1 SSID for wireless voice services (WPA and QoS enabled)
1 SSID for guest wireless networking (no EAP or encryption enabled)
User identity is not used to restrict access to any of them. We have plans for Identity Based Networking in the future, but our current primary focus is a global upgrade of our enterprise WLAN and further adoption of it as a primary access medium.
We ran into the following bug when attempting to override AAA with SSID (i.e. WLAN-ID).
It doesn't seem to be a high priority for Cisco (Sev3).
Can you comment?
I am unable to comment directly on bugs that are currently logged with the TAC. However, let me investigate this and see if I can get you some further information.
Are you sure it is really SSID restriction: specifying a SSID list in the ACS which users will be able to associate. I have checked all over the CTLR version 4.x config guide, and no place that feature is explain. Aeronet AP is supporting that in IOS mode. Don't be confuse with the Vlan dynamic assignment which is support on both platform.
I checked the documentation and you are right, SSID restriction is only available on the IOS access points. I reached out to the BU asking for information on this feature and they mentioned that a couple of customers have already requested it; a formal PER (Product Enhancement Request) has been logged.
I recommend you contact your Account Manager and also request this feature support, as the liklihood it will be provided in the next release increases the more customers ask.
Can you please describe the support structure for your WLAN? How do you handle multiple client types and operating systems etc?
Thanks for the question.
As you may imagine, Cisco System's internal WLAN is a very robust and widely used network. We have provided wireless LAN coverage in every single office across the globe and all Cisco employees are provided with wireless enabled laptops by default. We describe this as the "ubiquitous coverage, comprehensive entitlement" model. As such, the adoption is very high. It may surprise you to know that 42% of Cisco employees use the WLAN as their primary or only access medium!
We are currently in the implementation phase of a very wide ranging, global redesign and upgrade of our entire WLAN, with a view to increasing our internal SLA and pushing adoption even higher (our target is 50% of "wireless only" users). We have already accrued significant cost, time and productivity benefits from the WLAN and higher adoption will only increase the business value.
The current support framework is as follows:
We have a four tier support system.
Tier 1 - Global Technical Resource Centre (GTRC)
Tier 2 - Network Operations
Tier 3 - Network Design
Tier 4 - Technical Assistance Centre (TAC)
TIER 1 - GTRC
The GTRC is Cisco's internal frontline help desk. Cases can be generated by phone (a common phone extension across the globe), via a Web tool or via email. On average the GTRC handles approximately 1,000 WLAN related cases a month, dealing with 95% of them. Only 5% of cases are escalated to Tier 2.
TIER 2 - NETWORK OPERATIONS
A team equivalent to 3.5 FTE (Full Time Equivalent) network engineers provides day to day operational support for the WLAN and handle escalated cases. These cases can be due to RF interference, complex client configuration problems or coverage holes created by environmental factors for example.
TIER 3 - NETWORK DESIGN
The wireless network design team is made up of senior network engineers and architects who were directly involved in the design and deployment of the global WLAN solution. Cases are only rarely escalated to this tier, and usually only when a design factor is involved or required. This team does handle advanced trouble-shooting and
TIER 4 - TAC
Like all Cisco customers, Cisco IT can escalate serious cases or potential bugs to the TAC. This is our last resort and rarely occurs, but is a method for us to report and track issues when required.
As an FYI, based on the cost structure of our support framework and the total number of daily users of the WLAN, Cisco IT has calculated an average 'Annual Support Charge per User' of approximately US$19.
I have a question about PEAP reauthentication. We are using windows XP SP2 client, Cisco WLC2006 ver 4.0 and ACS 4.0. In the ACS "passed authenticatios" reports, I can see after PEAP clients were authenticated and connected, they reauthenticate at arbitary intervals. In my understanding, the reauthentication should happen at the "session timeout" period. I have disabled the "session timeout" at controller WLAN configuration, and leave the PEAP session out value at ACS to be 120 minutes. But the reauthentication does not happen at every 120 minutes. It could happen at any intervals from 5 minutes to 1 hour. Is this normal behavior or something wrong in my setup?
Are you sure you're not simply seeing normal authentications caused by users roaming from AP to AP? If you do not have any key management features enabled, the WLC will forward the auth requests to the ACS server upon each roam.
I am sure those reauthentications records were not caused by roaming. That is my laptop used for test and it never roamed during the test period. I am using WPA2 for key management. It looks like the reauthentication interval is random?
OK, well this doesn't sound like normal behaviour. Can you let me know what client adaptor (wireless card) and software utility you are using?
Cisco IT experienced something somewhat similar during our LWAPP pilot and we were able to resolve the issue with an upgraded driver and client. This may not be the same problem though, as we were not using PEAP in our environment.
Please let me know and we'll see if we can get to the bottom of this.
The wireless card is Intel Pro 2100 3A with driver version 184.108.40.206. It is configured by windows zero config utility. Also I found the "PEAP Session Timeout" value at ACS "Global Authentication Setup" page has no effect. I set the "PEAP Session Timeout" to be 3 minutes. But from the ACS authentication activity logs, the client reauthentcations do not happen every 3 minutes.