Shulou(Shulou.com)05/31 Report--

This article mainly introduces how to use RBAC to control user rights in Exchange2010. It is very detailed and has certain reference value. Friends who are interested must finish reading it.

First, RBAC has different functions for different types of users.

In 2010 of Exchange systems, role-based access control systems will all be used. The access control model used in versions prior to 2007 will be eliminated. In fact, the role-based access control system is not a new transaction, which has a good performance in other application systems. Microsoft only introduced this system here and optimized it according to the characteristics of Exchange.

So what are the revolutionary changes in RBAC for Exchange? To put it simply, administrators can define extremely diverse and accurate permission models for different roles through the RBAC role-based access control system. If there are eight words to sum up, it is "rich and colorful" and "accurate positioning".

Specifically, there are different benefits for different types of users. For end users, for example, the administrative role assignment policy defines what users can configure on their mailboxes. For example, you can control whether users can change the signature of their mailbox, change the filtering policy, and so on. You can also control whether end users can change their personal information, contact information, distribution group members, and so on. These features are sometimes very useful. If you use Exchange in an enterprise, the administrator may create an address book for employees throughout the company. At this point, the end user of the address book cannot change it at will. By default, these policies are automatically applied to each mailbox. Or it can be enabled manually by the user.

For administrator users, there will be different benefits. Administrative role groups can define what administrator users or expert users can manage in the system. To put it simply, role groups can connect a series of required administrative roles to form a virtual "collection". System administrators can control members to manage only certain aspects of the organization by adding or removing users as members of role groups, or adding and removing role assignments in role groups. In large-scale Exchange applications, this is very beneficial. Because enterprises often have multiple system administrators at this time. For example, each branch office will have a mailbox administrator. These mailbox administrators are able to do some simple maintenance work. Such as adding new users or deleting users, as well as local data backup and so on. Other maintenance tasks, such as firewall policies, can only be done by a specific administrator.

This design can carry out appropriate authorization between different administrators to achieve division of work; at the same time, it can also improve the flexibility of the system, assign different management policies to different branches, and be maintained by their respective administrators. [exclusive contribution by IT expert Network]

Second, the main differences between 2010 and 2007 versions of rights management.

The main difference in privilege management between 2010 and 2007 is the use of RBAC (role-based access control) system in 2010. Specifically, this difference is mainly reflected in the ACL access control list.

As we all know, if you want to achieve more complex and comprehensive access control on version 2007, you need to rely on ACL access control list. Although ACL is more powerful, it will also bring a lot of trouble to administrators. For example, in 2007, there are often some inexplicable results after modifying the ACL; sometimes you need to upgrade to maintain the changes of the ACL; and there are many restrictions on using ACL in non-standard mode, and so on. But these problems will go away in 2010 due to the adoption rate of RBAC. Because through RBAC, administrators do not need to modify and manage ACL access control lists. This is the important difference in rights management between the two versions. However, the role-based access control of RBAC is only an appearance.

Third, the matters needing attention of role group management.

In practice, we can divide Exchange users into two categories: administrator users and end users. Administrator users can be divided into two categories: administrators and developers. Sometimes the existing functions of Exchange may not be able to meet the needs of users (although the functions of Exchange are already very powerful), so it is necessary to do some simple secondary development or deployment configuration on the original functions. If you may need to integrate with the OA system and so on. Although they both belong to administrators, their tasks are different. For example, developers may only manage specific functions of Exchange, which rarely involve the configuration of existing functions of Exchange. In order to prevent developers from accidentally changing the mailbox configuration to bring unnecessary trouble to other users, they are often subject to permission control.

Suppose you encounter this kind of demand, how to solve it? The author's suggestion is that through the 2010 RBAC authority control system, the management role group can be divided into two groups. The average administrator only maintains the configuration of the organization, recipients, and so on, while the development expert manager is only responsible for the development and modification of specific functions of Exchange. Through this classification, the work between these two types of personnel can be prevented from interfering with each other.

In addition, administrative role groups can organically associate administrative roles with a group of managers or expert users. For example, developers have only limited management capabilities and are not granted a wide range of management rights. A new problem will also arise at this time. For example, when a developer needs to test a function that he has just developed, only to find that he does not have permission for a job. If we encounter such a situation, how should we deal with it? The author also has a suggestion for this. A specific role group can be associated with public administrative roles. This common administrative role allows developers to participate in the management organization and the configuration of recipients. They can be associated when necessary, such as during testing. Wait until it is finished, and then remove the relationship between them. It can be a lot easier to operate.

As for the management of role groups, the author summarizes it. Mainly for non-end users, classification and grouping management is also needed when necessary to avoid unnecessary interference with each other. Sometimes if you need to "exceed your authority" for some special reason, you can temporarily associate it to a "public administrative role" to meet the needs of specific permissions. Note that when the job is finished, be sure to withdraw the relevant permissions. "the right to release troops with a cup of wine" can improve the security and stability of the Exchange server.

Fourth, direct user role assignment simplifies policy management.

In general, in RBAC, roles (whether they have permission to perform a job) are assigned to the role assignment policy first. Then the role assignment policy is managed with the user. Simply put, it is permissions, policies, users. Note that permissions cannot be directly associated with the user, but must go through the intermediate media of policy. This is the core of RBAC. In more complex enterprises, this feature is more practical and can force administrators to manage users and their permissions through policies. However, if the scale of the enterprise is relatively small and the number of users is relatively small, if this management mode is adopted at this time, it will feel like "killing a chicken with a cow's knife".

In this case, you need to use the "direct user role assignment" function to simplify the management of permissions. "direct role user assignment" is an exception in RBAC. Can be used to assign roles directly to users without using role groups or role assignment policies. However, direct role assignment is useful when you need to provide a more elaborate set of permissions for specific users (that is, only a small number of users, or even only one user).

However, when using this role allocation mechanism, you need to pay attention to its shortcomings. Using Direct role assignment increases the complexity of the permission model. The specific degree of increase depends on the authority. For example, when a user leaves, you need to manually delete the role's association with the user. For this reason, it is generally not recommended to use direct user role assignment unless there is a special need.

In general, you can combine role assignment strategy with direct role user assignment. If it is assumed that there is only one administrator, the administrator can adopt the functions assigned by the direct role users for himself. Then adopt a role assignment strategy for other users.

The above is all the contents of the article "how to use RBAC to control user rights in Exchange2010". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.