If you're going to separate users with VLANs and ACLs, a given user can be in only one VLAN, so how to put that critical order-entry person into the Oracle implementation project and keep his affiliation with the operations team?

Another approach IT to limiting access to resources for an ad hoc group is to build a folder system on a file server and dump resources there. However, these kinds of groups increasingly need controlled access not just to specific files but also to relevant applications and sometimes devices.

For instance, the partner-based project might benefit highly from Google applications for collaboration, but the organization may not want other people in the company to run these applications. Or perhaps the operations person on the RFID implementation team must access a bar code scanner to test that serial numbers are recording in the appropriate database field but the operations team as a whole should not be allowed to run those scanners.

In addition, these ad hoc groups will eventually dissipate, and people's access rights should be revoked at that point. The mechanism for deprovisioning a user must be as efficient as that for turning on the access in the first place.

To handle these ad hoc groups effectively, IT needs a way to cluster users, applications and devices into roles quickly and easily. Within that, IT must be able to support multiple roles per user and enable access policy that keys off the role information. Depending on Layer 2/3/4 LAN constructs, such as VLANs and ACLs or on server-based controls, is too complex and too rigid to support this quick pace of change.