怎样配置CRM的SPN

关于SPN   服务主体名称,也称为一个SPN,是一种名称,唯一标识一个服务实例。用来验证Kerberos身份验证的SPN的必须正确设置。SPN是Active Directory属性. 但不暴露在AD的管理单元.   确保正确的SPN的设置变得非常重要,比如讲CRM, SQL SRS的应用.   如果应用程序分别在不同的服务器上,我们会需要用户凭证从一台服务器传递到另一个台服务器。这个过程称为Kerberos委派。例如,当用户运行了在CRM中的SRS的报表时,我们必须验证CRM,然后将请求发送到SRS服务器。CRM服务器会模拟用户对SRS的请求。如果SPN身份验证不正确,CRM服务器上的授权就会失败,SRS的请求会用NT AUTHORITY \ ANONYMOUS登录, 随后就会导致401身份验证错误。     SPN 格式   SPN的格式是<service class>/<host>:<port>/<service name>.   端口号和服务名字是SPN参数的可选项。最常见的就是看到SQL SPN使用端口号及服务名字。 通常你需要定义SQL的port和数据库实列的服务名字。在其他一些场景,SPN也需要定义一些IIS的应用程序。 当Web应用程序/服务没有用标准的HTTP 80端口(HTTP)或443(HTTPS)的监听时, 你需要定义IIS端口.  如果使用默认端口,您不需要使用的IIS服务的SPN. 如果你使用自己定义的端口的话,你就需要定义IIS 的 SPN.     缺省SPN   默认情况下的主机服务类型的SPN会设置在所有计算机帐户下.这个SPN用来表示同时表示NETBIOS 和FQDN. 主机SPN的格式是:  HOST/<COMPUTERNAME>  和HOST/<COMPUTERNAME>.<FQDN>.   当SQL SERVER 安装时会需要运行SQL service的帐户. SPN会自动注册到这个账户下用MSSQLSvc\<ComputerName>:<Port> 这样的格式. 如果在安装完后你更改SQL的service account,你可能会碰到duplicate SPN 的问题,除非你移掉原用的账户 MSSQLSvc SPN,而使用这个你更改的帐户。…

1

MS CRM E2团队和文档

MSCRM产品基于多个包括AD, SQL Server, IIS, Exchange Server等多个微软平台.  Microsoft Dynamics CRM Engineering for Enterprise (MS CRM E2) 团队集合了各个方面产品的专家, 为企业级用户提供最佳的技术解决方案.  特别是在安全性和性能调优方面贡献良多.    以下是该团队近期发布的重要文档.  该信息将不定期更新.     – 关于在MSCRM4.0平台上实现字段级安全性的论述Security and Authentication in Microsoft Dynamics CRM: Field-level Security in Microsoft Dynamics CRM: Options and Constraints   – 关于MSCRM4.0安全模式的论述Security and Authentication in Microsoft Dynamics CRM: The Microsoft Dynamics CRM Security Model…


CRM 4.0 字段级别的安全控制 (Field-level Security,简称FLS)

之前很多朋友问到字段级别的安全控制实现(Field-level security,FLS)。 4.0产品中没有提供该feature, 不过微软E2部门发布了一篇白皮书讲述了可能的技术实现方法方法,应该考虑到的安全漏洞和限制: Field-level Security in Microsoft Dynamics CRM: Options and Constraints   如果自己实现个人认为工作量还是很大的。 作为市场上成功实现案例参考,C360公司有产品实现了Field-level security c360 Field Level Security for Microsoft Dynamics CRM 4.0 C360的实现我个人的理解是在展示层(presentation layer)而不是在平台层(platform layer), 所以根据我们的白皮书应该还有很多改进的地方。   另外一家是 GaleForce IndustryCRM Add-ons for Microsoft Dynamics CRM,个人没有研究过。   已经有很多客户提出对FLS的需求,产品组的确在5.0里认真考虑客户的反馈,但5.0最终发布的时候是否会包含FLS功能,要等到明年拿到Beta的时候才能看到产品组官方的决策。:)   另外有朋友问到5.0的信息,我们的官方渠道是在下面这个地方下载(需要注册partner的帐号): Statement of Direction for Microsoft Dynamics CRM 该文档列数了CRM未来的方向 (关键词 Microsoft Dynamics CRM…


CRM 4.0 用户 (users)和Active Directory的集成绑定

  FAQ1: 我们使用了Active Directory的ADMT工具做了跨域用户的迁移,从此以后那些被迁移过的用户无法登录到CRM系统中,什么原因呢? 解答: 这个 要从CRM 4.0中和AD的绑定说起。正常情况下登录的时候,用户会被IIS那里验证,传出一个WIndows AuthInfo信息,CRM平台拿到这个信息后会比对SystemUserAuthentication这个库表,对应找到UserId,通过SystemUserOrganization库表找到该user所属的Organization和在那个Organization里面的CrmUserId. 有了这个信息后读取特定的OrganizationDB的SystemUserBase库表,找到ActiveDirectoryGuid,DomainName信息, CRM然后访问Active Directory来验证自己库表里存储的信息是否和AD中的保持一致,如果不一致本次验证失败。如下图表所示黄色部分的信息都是CRM在安装配置过程中从Active Directory里面读取的数据。 如果Active Directory使用工具ADMT迁移跨域用户后,用户的ActiveDirectoryGuid不会改变,但是AuthInfo和DomainName都会变掉,导致CRM数据库里的信息和AD的信息不一致。   解决办法是: 如果你的域关系是单向信任的 (one-way trust),你需要安装Update Rollup 7. 然后使用CRM 的Deployment Manager来重新映射用户 (修改用户对应的alias,比如testDomain\name),CRM 平台会自动去Active Directory系统获取更新最新的相关信息。     FAQ2. 我们公司的AD域被重新建过了,我们备份了CRM数据库,在新的域里面安装了CRM软件和SQL server后我们把CRM数据库恢复上线。所有的用户的Alias和域名都没有更改过。但是CRM系统无法访问? 解答: 原因参见FAQ1的解释,重新建的AD域AuthInfo和ActiveDirectoryGuid都会变掉了。解决办法是使用Import Organization工具做重新部署。 具体过程参看 952934    How to move the Microsoft Dynamics CRM 4.0 deployment   如果你的CRM数据库很大并且要映射的用户很多,需要安装如下的hotfix来提高性能 The Import Organization wizard takes a…

1

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:…


MSCRM用什么身份来执行工作流中的操作

MSCRM中的所有操作都需要有身份验证, 工作流中的所有操作也不例外.  本文介绍了这方面的规则.   当工作流是自动运行, 即被创建、修改、分派等动作触发的, 则运行其工作流步骤使用的身份是该工作流的创建者。   当工作流是手动通过使用“运行工作流”菜单触发的, 则运行其工作流步骤使用的身份是手动触发工作流的用户。   前一种情况, 需要保证工作流的创建者有足够的权限运行工作流的所有步骤; 后一种情况, 则手动触发工作流的用户不但要有触发工作流的权限, 还要有执行工作流中所有步骤的权限.  如不符合以上条件, 工作流会失败.   以上的规则保证了CRM的安全规则的严密性, 需要大家在设计工作流时考虑到.   Thanks,Chris


在ISV页面中调用CRM Web Service时使用Impersonate的几个场景

MSCRM作为平台, 其扩展性已为大家所熟悉.  作为扩展的终极方案, 加入自己编写的ASPX页面并在页面里调用MSCRM的Web Service, 能实现更为复杂的客户需求.  我们知道MSCRM中的所有操作都需要有身份验证, 调用Web Service也不会例外.  本文讨论了如何在自己编写的ASPX页面(下文称为ISV页面)中用正确的身份模拟(Impersonate)调用MSCRM的Web Service的几个场景.   场景一  ISV页面部署在CRM站点的ISV目录下  这种情况下无论你的CRM使用的是On-Premise还是IFD的认证方式, 都必须使用CrmImpersonator类, 将调用CRM Web Service的代码写在CrmImpersonator的段落中.  CrmImpersonator会建立一个线程, 将当前CRM使用者的身份运用到调用的CRM Web Service中. 该场景的实现方法, 请参见 Authentication from an ASPX Page   场景二  ISV页面部署在非CRM站点, 使用者是非CRM用户 这种场景常见于CRM与其它接口的互动, 比如从公司的Internet网页获得客户数据, 或者CRM与其它应用进行的数据交互.  因为ISV页面的使用者不是CRM用户, 我们必须指定一个CRM用户的身份来调用CRM Web Service, 这可以非常容易的在代码中实现.  注意这个时候CRM用户需要有合适的权限来执行ISV页面中CRM相关操作. 该场景的实现方法, On-Premise验证方式请参见 Impersonation, IFD验证方式请参见 Web Form (IFD) Authentication   场景三  ISV页面部署在非CRM站点, 使用者是CRM用户 这时候一般会要求使用当前用户的身份来运行ISV页面中的CRM…

2