Security

A few meanderings on AirGroup & its new Auto-associate feature...

Auto-association allows AirGroup users to discover nearby AirGroup servers. Auto-association ensures that all the AirGroup users associated to an AP-group, AP-FQLN, or AP and its neighbors discover the AirGroup servers. An administrator can enable auto-association for each AirGroup server separately and configure AP-name, AP-group, or AP-FQLN for auto-association. 

I understand that I can setup individual policies per individual airgroup servers based on MAC Address.

Auto-association can be enabled for a complete service, which allows all the AirGroup servers who advertise that service to be auto-associated with the configured parameter. 

Or, I can specify auto-association based on airgroup service, i.e. all AirPlay servers or GoogleCast servers.

Auto-association ensures that all the AirGroup users associated to an AP-group, AP-FQLN, or AP and its neighbors discover the AirGroup servers. Administrator can also configure location-based policies for AirGroup devices. For example, administrator can configure if an AirGroup server is visible over a broader area than auto-association configuration. In location-based configuration, administrator can configure AP names, AP groups, and AP FQLNs. Location-based policy configuration limits the AirGroup server’s visibility to AirGroup users who are associated to configured APs, its neighbors, AP-groups, or AP-FQLNs. ... Administrator can choose whether to consider the neighborhood of the configured AP names. 

How does one determine which APs would be considered neighbors? Specifically, how does the airgroup sub-system define an APs "neighbors"? There doesn't appear to be any configurable method to define which APs are one hop away (via PL or SNR).

 

I realize that I can use the command "show ap arm neighbors" to view a list of neighbors that a given AP sees; however, that provides a numbers for one hop & two hop APs based on which additional options are passed to the command (active | direct | relevant | valid).

 

Which of these does the airgroup subsystem use to determine what AP neighbors would be allowed to see AirGroup servers?

 

It would be really nice to be allowed to configure a threshold to determine / force which APs would be considered neighbors. Perhaps something along the lines of a PL threshold?

 

Ultimately, I guess, this harks back to the creation of coverage circles or areas which take into account Tx power settings and what not - going back to the Indoor 802.11n VRD.

 

Ah...

 

Could I define the same AP-FQLN for an arbitrary group of APs as a way to limit AirGroup services available in a given classroom or area? So say a classroom contains 3 APs, can I place those APs in the same AP-FQLN & define an "airgroupservice auto-associate ap-fqln classroom_x" to essentially limit airgroup services to that location?

We're looking to enable AirGroup features to provide our student population services that they'd expect would just work, "like @ home". For residence halls, it could be a simple matter of enabling certain AirGroup Services and limiting them via AP-Group. However, for administrative buildings in which a department may only wish to allow specific users or services to specific areas a little more though and planning needs to be exhorted.  

 

At the moment, we want to avoid implementing a registration system via CPPM; however, if the need ever arrises to allow specific groups of people access to AirGroup Services then we may take a look at that or the shared user, group, or role list feature.

 

I'm curious to know what others are doing to provide AirGroup services?

 

Thanks, 

 

So you're not worried about users overtaking other users devices?

@cappalli wrote:
So you're not worried about users overtaking other users devices?

Yes & No...  

 

I guess you can say that the Higher Ed environment can be considered the wild west of wifi.  Even more so when its in a densely packed urban environment.  

 

My guess is that you're saying CPPM Registration is the way to go, thereby allowing individual AirGroup Server owners to register their AppleTV, ChromeCast, or AirPrint envable device(s) to allow access to whomever they want.  That would add an additional layer of security on top of the methods Apple already provides.  

 

Our concern is that not many users, especially students, will want to take the time to register their device.  We already have a few non-802.1x capable devices (namely game consoles) going through a registration system for access to a separate wifi nework & that can be a chore to walk them through even that process.  

We will eventually plan on implementing AirGroup registration via CPPM, but we're going to separate it from our CPPM environment in use for 802.1x authentication.  We'll probably use this to also run our Guest Portal as well.  

 

Alternatively, if we wanted to maintain access controll for a few departmental devcies, we can either use CPPM or take advantage of airgroup policies (via the cli) for individual devices.  

 

I've found that the studenylts are so happy that their home devices work that they're willing to register them once.

Thanks,
Tim