You can't disable this.
It should not impact the functionality because the cache gets flushed if it become invalid (because the user is assigned to a different team, or removed from one), so it will not be out of date. This is on every front-end server, of course. So it is a performance consideration (and quite a big one).
Some things that the web server evaluates and then caches:
- all the Security Roles a user has are evaluated and the resultant set of deepest privileges are cached (so the Security Role list itself is not cached). This is flushed if any Security Roles are (un-)assigned or modified.
- likewise for Teams the privileges are cached.
- user's Team memberships, flushed if they change
- the above will also get flushed if any property of the user or team changes. Eg if you change a user's phone number that can be enough to cause their cache to be rebuilt.
- caches are also flushed after periods of inactivity by a user - this makes sense if you consider that a change to a Team or Security Role will rebuild all the current caches for related users. If a user's cache has been flushed, it is one fewer for this rebuilding process to recreate
The fact that the cache gets flushed and has to be rebuilt by querying SQL is a performance hit. If users are added in and out of teams very frequently, this can be quite a significant impact, as the web server cannot evaluate privileges efficiently and has to request this from SQL before it can respond, which also means there is impact on the DB server.
For a retrieve multiple request (such as every time you click to see a View), if the web server can determine that you have Global (=Organization) read access to the entity, it can simply request the records to match the filters defined in the view. If you have anything less than Global read in your roles, or any of your team's roles (a combination of the cached teams list and their cached privileges), then the system has to do two queries, one for the record set for the view, and another for all the records you are allowed to see (including all records from all BUs your teams grant access to, plus all shared with the user or any teams they are in - if you have less than Global access depth, you will hit the POA every time, even for entities that have never been shared).
This is one of the key reasons for using Access Teams - they cannot have security roles, therefore they are not included in the list of cached Teams, and so changing memberships of Access Teams do not flush the cache (and do not need to). Since they have no roles, there is no need to cache them and their privileges either, since they have none. Using lots of Teams in 2011, even if they have no roles, will still impact caching because it has to assume that they might have.
The Business Unit an Access team is in irrelevant, since they can only be used for sharing and the perspective / point of view of the location of the Team is irrelevant. So when the security model has to evaluate all the possible BUs a user has access to, to combine with the privileges they get from those team memberships with the records in a retrieve multiple, it can again ignore Access Teams and only consider the Owner Teams, which is a much smaller set of Teams, BUs and privileges to consider.
I believe there are some (registry?) settings you can use to try and improve the performance of the caching, including pre-caching after a restart of the web server, and changing the inactivity timeout before flushing (typically to increase it so that a user connecting several times during the day gets better performance, but arguably decreasing it if you have large numbers of users who connect very infrequently for only short periods of time).
You need to refer to the Scalability Security Modelling whitepapers for CRM 2011 and 2013 for more details:
http://bit.ly/CRM2011ScalableSecurity
http://bit.ly/CRM2013ScalableSecurity
I will also be discussing this topic in a deep dive session at the CRM User Group Summit in St. Louis in October http://crmugsummit.com
