Windows xp sp2工作站间DCOM设置
Windows xp sp2上市后，全球一片“升级”之声，尤其是sp2“不阻止非正版升级”策略，对于我国的许许多个人甚至是单位有着致命诱惑。基于其宣传的“安全中心”等功能，本人于近期对两台计算机进实施了升级。正当升级后的新鲜感尚未完全消失时，麻烦来了。
我以前开发的ＤＯＣＭ远程查询系统跑不动了，每当客户端要访问服务端时，ＤＣＯＭ安全性其经典的“拒绝访问”就会在一声大响中出现。天哪，为了让其运行，我甚至开始将平台由ＤＣＯＭ转换到ＣＯＭ＋环境，在ＣＯＭ＋中，经过一阵域和角色的设置后，客户端终于能运行了。然而在偶然的一次服务器测试中，“安全中心”提示我，是否阻止“dllhost.ex”穿越防火墙？一瞬间，我突然明白了为什么我的DCOM不能正常运转的原因：是防火墙在做怪！联想到在解决安全问题时查阅过的SP2文档内容，我开始重新对DCOM服务和客户端进行设置，终于它又能转了！现在看看本人历经半月“顿悟“的的设置过程：
一、设置Windows Workstation之间的最低安全属性：
Windows对于独立工作站（不在域中）之间的DCOM互访，运用ＮＴＭＬ安全包进行安全性检查。根据ＷＩＮＤＯＷＳ的安全帐户设置机制，对于不同的ＷＩＮＤＯＷＳ工作站，其帐户的ＳＩＤ是不同的，即使是在两台工作站上有相同名称和密码的帐户，在进行安全性验证时，二者仍然是不同的帐户。为实现跨工作站的ＤＣＯＭ访问，已有许多人针对ＷＩＮＤＯＷＳ２０００、ＸＰ做了讨论，这里本人只采用自己测试过的办法（虽然其安全性不好）。
服务器端设置：
１）、运行ＤＣＯＭＣＮＦＧ，在［组件服务］·［计算机］·［我的电脑］上设置计算机范围的默认安全属性，在［属性］的［ＣＯＭ安全］页上，点击“编辑限制”将“访问和权限”、“启动和激活权限”中Everyone的最低远程访问权限调整为“允许”（图1.1、图1.2）。
图1.1
图1.2
2）、设置服务器的访问权限，并将Everyone加入到“启动和激活权限”和“访问权限”中，并设置其全部权限为“允许”（图1.3、图1.4）：
图1.3
图1.4
客户端一将应用服务器的类型库导入到本地计算机后，一般不需要做其他设置。如果，客户端同时也是服务器，则其也要按上述要求设置。
二、设置Windows sp2的防火墙：
服务器端：
对于ＤＬＬ型（进程内服务器）的服务器，将dllhost.exe加入到防火墙的例外程序和服务中（图2.1）。对于EXE型（进程外服务器）的服务器，必须将该应用程序可执行文件加入到例外程序和服务中（图2.2）。这一步是sp2下实施正确访问的前提（除非你禁用防火墙）。
图2.1
图2.2
客户端：
纯客户端只须将DLLHOST.EXE加入到防火墙的列处程序列表中即可，对于客户/服务器同体的，则仍需将服务器可执行文件加入到例外程序列表中。
三、COM＋的设置。
由于COM＋运行环境的宿主加载程序也是dllhost.exe，因此，对COM＋服务器和客户端也必须将dllhost.exe加入到防火墙的例外程序列表中才可顺利运行。
四、DCOM和安全性考虑
上述设置是基于本地局域网内无恶意用户为假设前提的，对于无连接INTERNET的局域网，则这种设置并不是可推荐的安全设置（甚至可说是不安全的）。为保持相对的安全性，在sp2的防火墙设置中，你可以对其应用范围进行设置，使其限制在指定的网络范围内，如：局域网段内或指定的地址范围内(图4.1)。
图4.1
由于DCOM推出至今已有10多年了，从技术上讲虽然其在安全性上有许多可进行细微控制的功能，但是许多人认为，掌握DCOM安全性并将其熟练的应用于开发过程中是一个巨大的挑战，其学习成本和应用效率的负比例是许多人不能接受的。因此，本人认为DCOM应用服务无论从安全性还是开发效率上，应尽快向COM＋环境转移。COM＋直观的角色安全机制及其细微到方法级的安全控制，使大多数小型应用不需要在安全设置方面化太大的精力。这些在本人解决DCOM安全问题时有非常深刻的体会：COM＋不居然不需要我调用CoInitalizeSecurity、 IClientSecuryity就可以直接控制域帐户的区别访问，真是“xxx Cool”。而且COM＋的托管服务概念，正是向NET前进的快速路。当然，我们在应用COM＋的同时，我们的技术、知识、商务就会越来越无法摆脱Microsoft的影响和控制。但是，我们为了简单地生活每天都在妥协，对于正确的技术何不为高效、易用而向其妥协呢。只要我们自己不停止对其他知识的探索，我们的知识不会让“软件”实现“硬垄断”。中日韩三国的LINUX开源代码协议正是此意。
昆仑踏月 2004年11月3日 于乌鲁木齐
