Friday, September 13, 2013

ACS 5.x: Using Identity Groups to Simplify Authorization Policies

One of the things that I rarely see implemented in ACS 5.x are Identity Groups.  This is an incredibly powerful tool that can be implemented in almost every ACS installation.  It's one of those things that is really useful when dealing with failover, multiple identity stores, etc.

I was reminded how powerful this is when I received a call from a customer who's entire wireless and VPN environment was down due to issues with their ACS box.  The root cause?  All of the domain controllers were having issues.  Sadly, LDAP was still functioning, but they had never tested the LDAP integration and it didn't work.

For those that do implement multiple identity stores, what I usually see is a HUGE list of Authorization rules for each combination of Group and Store.  This gets really nasty when trying to troubleshoot why you are getting a particular undesired result.

Here I will be showing how to authenticate against multiple identity stores in order to deal with the failure of AD, LDAP and finally roll to internal users.

Thursday, September 5, 2013

Using Fiddler2 to troubleshoot Captive Web Portals

I find in wireless a lot of people aren't familiar with Fiddler.  I was introduced to Fiddler when I was writing web services and needed to diagnose why my web services weren't working.  Fiddler is a web proxy for windows that runs under the .Net framework. (Sorry Mac users).  I think to think of Fiddler as Wireshark for Web Services.   While you can proxy for other devices, that's beyond the scope of this article.

One of the things I have the most difficult with is troubleshooting Captive Web Portals.  There are a lot of things that can go wrong.  Between DHCP, DNS and Web Intercept, external web servers, etc, it can be especially difficult to troubleshoot to narrow down where the issue is.

Layer on top of this things like on-boarding product or RADIUS Change of Authorization, Cloud services and content filtering, things can become very complicated in a hurry.  While Fiddler doesn't make it any simpler, it does give us the visibility to the web interactions between the client and server. 

I'll assume that you've gone over to www.fiddler2.com and downloaded/installed the software.  It's free.  I would suggest installing it on a windows laptop with a fresh install.  Why?  Just because you won't have a million apps trying to make calls to cloud services while you're troubleshooting.

So I launch fiddler on my broken Web Auth wireless network and try to go to www.google.com.  Care to guess why this isn't working?


Hmm,  DNS Lookup Failed.  Although, since I broke the DNS server for this example, I know this is why and after the DNS issue is resolved, this is what we get.



Looking at the response you can see there is a Web Auth Redirection and the the Virtual IP of the WLC.  Prettying this up we see:

<HTML>
     <HEAD>
          <TITLE> Web Authentication Redirect</TITLE>
          <META http-equiv="Cache-control" content="no-cache">
          <META http-equiv="Pragma" content="no-cache"><META http-equiv="Expires" content="-1">
          <META http-equiv="refresh" content="1; URL=https://192.0.2.1/login.html?redirect=www.google.com/">
     </HEAD>
</HTML>

If you click on the subsequent entries, you can look at both the client request and response.  If you are doing HTTPS, you can even enable HTTPS decryption so you can see what is going into the tunnel, which is something that's a lot harder to do with low level tools like Wireshark.

Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.

Secure Protocol: Tls
Cipher: Aes256 256bits
Hash Algorithm: Sha1 160bits
Key Exchange: RsaKeyX 1024bits

== Server Certificate ==========
[Subject]
  CN=192.0.2.1, OU=DeviceSSL (WebAuth), O=Cisco Systems Inc., C=US

[Issuer]
  CN=192.0.2.1, OU=DeviceSSL (WebAuth), O=Cisco Systems Inc., C=US

[Serial Number]
  00E51A9CE1

[Not Before]
  7/8/2013 6:00:01 PM

[Not After]
  7/8/2023 6:00:01 PM

[Thumbprint]
  F1064A5A9811A241F09A42C822CBDE6E2D59BEF8

With SSL Decryption in place, you can actually look and see that it didn't work this time because my username and password were not correct.  Now be aware that to do this, i have to accept the fiddler SSL cert and approve each tunnel to decrypt, so for a hacking/sniffing tool, it's not very useful.



Now while Fiddler is a good tool to have in your arsenal, it won't replace packet capture software for other troubleshooting.  You also might find uses for this outside of the wireless world.  My coworker uses this for testing with load-balancers and other higher layer services.  So happy Fiddling and hopefully you find this tool useful.

Monday, September 2, 2013

Begun, the Chipset Wars Have

As you might expect, 802.11ac was a hot topic at Wireless Field Day 5.  While there wasn't a lot of talk about it onscreen, there was a lot of talk about chipset vendors between the delegates and sponsors.  Surprisingly, Meru  and Xirrus were some of the most open about talking about their chipset vendors of choice.  Props to Xirrus for being the only vendor to admit they were using Qualcomm Atheros on-air for a yet-to-ship product.

The general consensus was that Broadcom surprised a lot of people with their focus on the enterprise and their speed to market.  At the time of writing this, all of the shipping enterprise 802.11ac access points are Broadcom chipsets in the enterprise space (Cisco, Aruba and Meru).

Atheros was the king of the enterprise AP market in 802.11n.  With the exception of Cisco who is known for their Marvel chipsets, almost every enterprise class AP vendor used Atheros for their 11n chipsets.  Now Broadcom is the first to market and a number of the enterprise manufacturers have made the jump to Broadcom due to a significant lead time of getting their gear to market.

But being early to market didn't come without a price.  There are some restrictions around the number of encrypted clients, number of beam-formed clients and whether they support promiscuous  packet capture.

I would expect to see vendors bringing their Atheros based chipsets to market soon. Xirrus passed around their 802.11ac module based on Qualcomm Atheros.  I would expect to see a number of product announcement in the coming months and for the vendors to promote how they are different from their competitors products.

The real question is whether vendors who have jumped on the Broadcom bandwagon will continue to stay there, or if they will make the jump back to Atheros when those products become available.  This will also help AP vendors help differentiate themselves from these early generation products.  One thing you can bet on, it will be an exciting ride.

My thoughts:

Competition in this space will be good for everyone.  It will cause chipset manufactures to innovate with features and functionality, drive down price and generate product differentiation for enterprise customers.