05-13-2009 08:18 AM
The problem with this scenario is that the if the user's have administrative control to change WLAN profiles on clients, they will quickly learn that they can surf the undesirable sites via the "Guest WLAN", with the associated impact to productivity, etc.
So we want a way to ensure that we can detect and stop this behavior.
Since domain member machines will always attempt to send udp-netbios name service requests to the domain controllers for the domain to which their joined, we define a network-dest of the DC, and a policy which will blacklist clients sourcing traffic to the DC on dest port udp-137.
We add that to the Role assigned to guests, such as our aptly named Guest-Services-Policy, and then we have a method to kick a user off of the Guest network if their client is a domain-member. The first few times you show up at the blacklisted client to find out why they attempted to use the Guest network, it's amazing how quickly word spreads....
Leverage social engineering to solve user behavioral problems.
05-13-2009 01:13 PM
05-15-2009 08:07 PM
You can also re-use similar policies effectively if you have user derivation rules for devices such as PDAs (iPhone, Blackberry, Nokia, HTC for instance) to give those users http access. I have several sites doing this to 'skip' the captive portal on the small keyboards and just let guest internet straight out on PDAs.
The challenge being to verify if it is _really_ a PDA.
Enter the rules discussed in this thread! Once the "PDA"s start talking to the domain controller you can pretty much conclude you have a crafty user spoofing on the network to blend in with the PDAs and can blacklist his laptop turned PDA. :)
05-28-2009 08:33 AM
05-20-2010 10:37 AM
A few complicatations/limitations.
1 You can only deny the SSID by group policy on Vista and newer domain clients. Nothing is availble for XP ie: netsh wlan
2 You need to be proactive in trapping this type of activity realime, addressing clients by corporate policy never gets the job done and its easily forgotten. No IT person wants to be the policy police.
3 Locking down the SSID list so users can't add thier own is not practical to support, so you do need to keep that flexible.
A You can user Group policy on Domain member Vista clients and up, to DENY the SSID
B Bill's suggestion above is a good one, I think it is close, but no cigar. I've tested it and used a packet sniffer to watch for the patterns. A domain computer does a broadcast looking for "MYDOMAIN" or "MYWORKGROUP" NOT by IP. If there is no internal DNS available on the VLAN, the public DNS will not resolve it and there will be no local IP's to trap. The VLAN is supposed to be isolated from the internal DNS servers etc.
You can trap events like: printer configuration (tcp/ip printers) phones home, or some drive mapping by IP is done from the client you might catch the IP in use.
1 Can the controller do packet sniffing for the UPD 137/138 MYDOMAIN/MYWORKGROUP request values?
2 Its not practical to use resources for a keep alive ping script or other. What other tricks are out there to do an occassional phone home?
Meanwhile, any feedback welcome :cool:
06-02-2010 05:31 AM
After deep review of many packet sniffs, I've found my easter egg.
All my domain clients have microsoft firewall client. It always looks for the proxy server on tcp port 1745. I added this to the blacklist, and it works like a charm.
So my policy has a combination of any connections to the internal network of 172.x.x.x and the tcp port 1745 is a sure set to catch and blacklist the domain computers.
09-14-2010 09:38 AM
Is there a way I can blacklist them on only the guest SSID? As it is now the client gets blacklisted and then they are not able to connect to any SSID on the AP. I would like to just kick them off the guest and then let them back on to the employee SSID
09-14-2010 11:25 AM
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base