A scope is a virtual subdivision within an application that separates some resources from other resources that are used by that application. You can use scopes to prevent unintended resource sharing and to support auditing and delegation. You do not have to use scopes.
A scope can represent a folder, a container in Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AD LDS), a file-masked collection of files (for example, *.doc), a URL, or any item that can be accessed by the application and its underlying authorization store. However, a scope is an abstraction; it is a definition created in Authorization Manager, but it is not a physical folder in the file system or an actual container in AD DS, for example.
If you have Authorization Manager groups, role assignments, role definitions, or task definitions that you do not want to apply to an entire application, you can create them at the scope level. The application that contains the scope must be able to recognize the scope name. For example, file-based applications might have scope names that include file names or paths. Web-based applications might have URL-based scope names. Registry applications might have scope names based on registry hives, and Active Directory scope names could specify organizational units. You cannot define operations at the scope level.
You cannot control Authorization Manager run-time auditing at the scope level. You can control Authorization Manager authorization store-change auditing on scopes contained in authorization stores that are stored in AD DS. For more information, see Understanding Authorization Manager Auditing.
You can delegate the administration of scopes to other people if both of the following conditions are met:
- The authorization store must be stored in
AD DS, AD LDS, or Microsoft SQL Server.
- Authorization rules are not used in any task
or role definitions defined within the scope you want to