CRM 4.0中的Active Directory安全组 (Security Groups)
CRM 4.0 的安全控制除了使用自身系统内部的Role-based机制外，还需要和SQL Server 和Reporting Service系统打交道。为了统一安全控制，使用5个安全组来协调 (前面三个对库控制)。
注: 这5个安全组也可以在安装CRM 4.0的时候通过手动创建后使用配置文件指定，其命名可以自己指定,参看:
946677 How to install Microsoft Dynamics CRM 4.0 with the minimum required permissions
1. PrivReportingGroup
该安全组用来控制对CRM数据库(config 和orgdb)的读访问权限(CRMReaderRole), 不能做写库操作。这个主要是CRM Data Connector用的，需要对ConfigDB有读的权限。
2. SQLAccessGroup
这个控制谁有权利直接连接访问SQL数据库，该安全组对CRM库有db_owner级别的权限-可读可写; 可以发布更改删除报表 (publisher). 这个是CRMAppPool帐户需要属于的组。
3. ReportingGroup
该安全组用来控制对CRM的OrgDB数据库 读访问权限(具体主要是那些FilteredViews视表)，对ConfigDB没有任何访问权限。可以浏览执行SQL报表(Browser Role)。这个组用来做报表访问功能的。
上面3个安全组直接控制了谁可以登录SQL数据库(SQL Logins),登录后能访问哪个数据库(DB Roles)。 尽管CRM平台用来和SQL连接的connection string里指定了Windows集成验证，但是终端用户不会允许用来向CRM库写数据,CRM的设计让所有的写库操作一定需要通过Impersonation使用服务器进程运行的帐号进行.
比如:
Provider=SQLOLEDB;Data Source=MyCRMSQLMachine;Initial Catalog=CRMOrgDB;Integrated Security=SSPI
情景1: 用户Bob登录CRM 网页站点
此时CRM平台是使用CRMAppPool的帐户来做SQL Server 连接的. Bob如果要新建实体，修改记录等，都是通过CrmAppPool来做模仿(Impersonate)实现的
情景2: 用户Bob访问CRM报表 (安装CRM Report Connector)
此时CRM Connector是使用Report Service的帐户来做SQL Server 连接的.
情景3: 用户Bob动态执行导出的Excel数据 (dynamic Excel generated by Export to Excel )
此时是使用当前执行Excel的用户的帐户来做SQL Server 连接的。
4. PrivUserGroup
该安全组并不控制任何对SQL数据库的访问，属于CRM平台自身使用判断用户是否有权利模仿(Impersonate)别人。这个使用者主要是服务器进程比如CRM AppPool(w3wp.exe), CRM Reporting Connector(w3wp.exe for RS 8.0 or 9.0, ReportingservicesService.exe for 10.0). 编程人员可以通过CrmImpersonator class来告诉CRM平台某些代码需要服务器进程使用模仿的方式进行。
968243 The Microsoft SQL Server Reporting Services account is not added to the PrivUserGroup group if you install Microsoft Dynamics CRM 4.0 and Microsoft SQL Server Reporting Services on separate computers
https://support.microsoft.com/default.aspx?scid=kb;EN-US;968243
5. UserGroup
这个是所有加入CRM中的用户属于的安全组。在3.0中用来判断用户是否是个CRM用户，在4.0中已经不再强制做检查，出于兼容方面考虑还是存在4.0里面了。
thanks
Clifford (张立岩)