You can use four Windows NT functions to control user access in your application: user accounts, user groups, user rights policies and permissions, and program access control.
You can control user access to your application by using Windows NT user accounts. If users can't log on to the network, they can't run your application.
User accounts are the keys to Windows NT security. Every user who has access to a Windows NT system has a user account consisting of a name, password, and other logon parameters. With the Windows NT User Manager, you can establish, delete, or disable user accounts. You can create as many accounts as needed, and then restrict user access to your application and any Windows NT resource on a per-account basis. This means that properly configured user accounts play a significant role in allowing users access to your application and operating system resources.
Generally, specific applications do not request the Windows NT security administrator to add or change network logon accounts. But as a first line of protection, Windows NT authentication is available if your enterprise application needs it.
For More Information User access security is part of the larger Domain, sub-domain, and Groups permission structures within the Windows NT security model. For more information, search for "User Accounts" in MSDN Library Visual Studio 6.0.
Another way to limit access to your application is by collecting users into groups. A user group is a set of users who have identical network rights. Putting user accounts into groups simplifies user access administration. User groups also make it easier to grant multiple users access to a designated network resource: all you have to do is grant a specific access permission to the group (instead of to each individual user).
By defining user groups, you are creating your application's security model: certain groups will have access to a given set of application permissions, while other groups will have access to other permissions. To develop such a security model, you need to determine all of the potential users, list the data and resource access operations that each user needs, and, finally, group the users according to access permissions. For example, a set of user groups based on levels of secrecy permissions could be: Public, Private, Confidential, and Secret.
User rights policy controls the rights granted to user groups and individual user accounts. User rights policy also specifies restrictions such as password expiration and lockout duration. Permissions apply to specific securable resource objects, such as files, directories, and services.
You control user access rights to network resources and services (such as "log on to a server," and "back up and restore data") by using both user rights policy and permissions: first assign specific rights to a user or group, and then assign permissions to securable resource objects. In this way, you can specify who is allowed to use these objects and under what conditions they can use them.
With careful coordination of user and group account rights, your enterprise application can leverage Windows NT security to control user access.
For More Information For a thorough discussion of user rights with a recommendation of certain changes to the default Windows NT installation, search for "Securing Microsoft Windows NT Installation" in MSDN Library Visual Studio 6.0. Additional information can be found by searching for "Working With User and Group Accounts" in MSDN Library Visual Studio 6.0.
Your application can also control access by programmatically limiting access rights to certain users or groups. For example, you can assign selected component interfaces to certain users, thereby preventing others from using the component's method. As another example, you can use the ASP Session object to store a user's permission level and limit the visibility of certain Web pages. You can also create your own security module to function as a "gate keeper" to certain component functions.
However, program access control requires a lot of administration. Each time you need to change the access permissions, you must typically rebuild and redistribute the component. A better choice is to leverage the access security built into Microsoft Transaction Server (MTS). MTS simplifies the administration of component access privileges and uses the access permissions already set up with user and group accounts.
For More Information For more information on controlling access with MTS, see Securing Microsoft Transaction Server in this chapter.