在Exchange2010中为邮箱服务引入了一组丰富而实用的技术、功能与服务。RBAC(基于角色的访问控制)无疑是这一组功能的亮点之一。在2010的版本中，基于角色的访问控制(RBAC)将会替代老版本中所使用的权限模型。在这片文章中，笔者将着重给大家介绍一下RBAC的特性以及部署过程中的注意事项。
一、RBAC对于不同类型的用户有不同的作用。
在2010的Exchange系统中，将会全部使用基于角色的访问控制体系。在2007以前的版本中所采用的权限控制模型将会被全部淘汰掉。其实基于角色的权限控制体系并不是一个新事务，在其他应用系统中都有比较不错的表现。微软在这里只是引进了这一体系，并结合Exchange的特点进行了优化而已。
那么RBAC对于Exchange来说，到底有哪些革命性的变化呢？简单的说，管理员可以通过RBAC基于角色的访问控制体系，为不同的角色定义极其多样、精确的权限模型。如果有八个字来概括的话就是“丰富多彩”、“精确定位”。
具体的说，对于不同类型的用户会友不同的收益。如对于最终用户来说，管理角色分配策略定义了用户可以在其的邮箱上说配置的内容。如可以控制用户能否更改自己邮箱的签名、更改过滤策略等等。还可以控制最终用户是否可以更改其个人信息、联系人信息、通讯组成员等等。这些特性有时候非常有用。如在一个企业中使用Exchange，则管理员可能会为整个公司的员工建立一个通讯簿。此时这个通讯簿最终用户就不能够随意更改。默认情况下，这些策略会自动应用于每个邮箱。或者由用户手工启用也可以。
而对于管理员用户来说，又会有不同的裨益。管理角色组能够定义管理员用户或者专家用户能够在系统中管理的内容。简单的说，就是角色组可以将需要的一系列管理角色联系起来，组成一个虚拟的“集合”。系统管理员可以通过作为角色组成员来添加或者删除用户，或者在角色组中添加和删除角色分配，从而可以控制成员只管理组织的某些特定方面。在大型的Exchange应用中，这非常有好处。因为此时企业往往有多个系统管理员。如各个分支机构都会有一个邮箱管理员。这些邮箱管理员之能够进行一些简单地维护工作。如新加用户或者删除用户，以及本地的数据备份等等。其他的维护任务，如防火墙策略等等只有某个特定的管理员才可以完成。
这种设计即可以在不同的管理员之间进行合适的授权，以实现分工合;同时也可以提高系统的灵活性，为不同的分支机构分配不同的管理策略，并由各自的管理员负责维护。[IT专家网独家撰稿]
二、2010与2007版本权限管理的主要差异。
2010与2007在权限的管理上主要的差异就是在2010中使用了RBAC(基于角色的访问控制)体系。具体的来说，这个差异主要是体现在ACL访问控制列表上。
众所周知，如果要在2007版本上实现比较复杂、全面的权限控制，则需要借助于ACL访问控制列表。虽然ACL功能比较强大，但是其也会给管理员带来很多的困扰。如在2007中，修改了ACL之后往往会出现一些莫名其妙的结果;有时候需要通过升级来维持ACL的更改;在非标准模式下使用ACL会受到诸多限制等等不利因素。但是在2010中由于采用率RBAC，这些困扰都将烟消云散。因为通过RBAC，管理员更不不需要修改和管理ACL访问控制列表。这才是这两个版本在权限管理上的重要差异。而RBAC基于角色的访问控制只是一种表象。
#p#
三、角色组管理的注意事项。
在实际工作中，我们可以将Exchange的用户分为两类：管理员用户和最终用户。而管理员用户又可以分为两类：管理员与开发人员。有时候可能Exchange的现有功能无法满足用户的需求(虽然现在Exchange的功能已经很强大)，此时就需要在原有的功能上进行一些简单的二次开发或者部署配置。如可能需要跟OA系统集成等等。虽然他们同属于管理员，但是他们的任务是不同的。如开发人员可能只管理Exchange的特定功能，其很少会涉及到Exchange现有功能的配置。为了避免开发人员一不小心改动了邮箱配置给其他用户带来不必要的困扰，往往会对他们进行权限的控制。
假设遇到这种需求，该如何解决呢？笔者的建议是，通过2010的RBAC权限控制体系，可以将管理角色组分为两个。普通的管理员只维护组织、收件人等配置;而开发专家管理人员则只负责对Exchange的特定功能的开发与修改。通过这么分类，就可以防止这两类人员之间的工作相互干扰。
另外，管理角色组可以将管理角色与一组管理人员或者专家用户进行有机的关联。如开发人员只具有限的管理能力，没有被授予广泛的管理权限。此时也会出现一个新的问题。如当开发人员需要对刚才开发的某个功能进行测试，却发现自己没有某个作业的权限。遇到这种情况的话，又该如何处理呢？对此笔者也有一个建议。某个特定的角色组能够关联公用管理角色。这个公用管理角色可以使开发人员也可以参与到管理组织以及收件人的配置中去。在有需要的时候，如在测试的过程中可以将它们关联起来。等到完成之后，再剔除他们之间的关系。操作起来可以省心很多。
对于角色组的管理，笔者总结一下。主要就是对于非最终用户，在必要时也需要进行分类分组管理，以避免相互之间产生不必要的干扰。有时候由于某种特殊的原因需要“越权”的话，则可以将其临时关联到“公用管理角色”，以满足特定权限的需要。注意，等到作业执行完毕的时候，一定要收回相关的权限。“杯酒释兵权”，可以提高Exchange服务器的安全与稳定型。
四、直接用户角色分配简化策略管理。
一般情况下，在RBAC中是先将角色(是否具有进行某项作业的权限)分配给角色分配策略。然后再将角色分配策略与用户进行管理。简单的说，就是权限、策略、用户。注意，权限不能够直接与用户进行关联，必须通过策略这个中间媒体。这是RBAC的核心。在比较复杂的企业中，这种特性比较实用，可以强迫管理员通过策略来管理用户以及用户所拥有的权限。但是如果企业规模比较小，用户数量比较少，此时采用这种管理模式的话，就有点“杀鸡焉用牛刀”的感觉。
在这种情况下，就需要采用“直接用户角色分配”功能，来简化权限的管理。“直接角色用户分配”是RBAC中的一种例外的方法。可以用于将角色直接分配给用户，而不使用角色组或者角色分配策略。但需要为特定用户提供一组比较精细的权限(即只有少数的用户、甚至只有一个用户需要)，此时直接角色分配就会非常有用。
不过在使用这种角色分配机制的时候需要注意其缺点。使用“直接角色分配”会增加权限模型的复杂性。具体增加的程度根据权限而定。如当某个用户离职了，需要手工删除角色与用户的关联。为此除非有特殊的必要，一般不建议使用直接用户角色分配这个功能。
一般情况下，可以将角色分配策略和直接角色用户分配两种方法结合起来使用。如假设只有一个管理员的话，管理员可以为自己采用直接角色用户分配的功能。然后为其他用户采用角色分配策略。
