匿名远程访问COM+应用时被拒绝访问的问题

  有个客户在一个Win2k3的域下建立了一个COM+应用服务器,而客户端是一个工作组机器。 为了重现这个场景,我们按照以下的方式,允许以匿名的方式访问调用COM+应用:如何以匿名方式远程调用COM+,但还是在客户端出现了拒绝访问的错误。 在网络监视器中显示了拒绝访问错误(status=0x5)被返回到服务端。 客户用很多客户端在远程调用这个COM+应用,不能把它们全添加到这个域里。 我们通过以下方式进行一个快速的测试: 1.在两台机器上创建相同的用户名和密码。将COM+认证从“交互用户(Interactive User)”改变为这个测试账号。 2.在COM+应用服务器端,启用机器上的安全日志。在本地安全策略->本地策略->审计策略下,启用账号登录事件和登录事件的错误审计 在一个域控制器替代本地安全策略的情况下,我们需要检查域控制器安全策略。之后做一个”gpupdate /force”。做这个就是为了确保在安全日志里生成合适的事件日志项。 3.重演一遍这个问题,发现安全日志里有这个类型的错误: Event Type: Failure AuditEvent Source: SecurityEvent Category: Logon/Logoff Event ID: 534Description:Logon Failure:Reason: The user has not been granted the requestedlogon type at this machineUser Name: Domain Test User accountLogon Type: 8Logon Process: Advapi             这里的登陆类型(Logon Type)8表示“通过网络访问此电脑”的用户权限被禁止。 4.检查Win2K3域,发现客户未被赋予普通域用户“通过网络访问此电脑”的权限。 为了修正这个错误,我们在域控制器(DC)上创建了一个测试组织单位(OU),并将这个COM+应用服务器移到测试组织单位(OU)中,确保应用于此的域组策略没有定义“通过网络访问此电脑”的用户权限。然后在这个COM+应用服务器中,打开GPEDIT.MSC,进入本地安全策略->本地策略->用户权限,给所有人(everyone)“通过网络访问此电脑”的权限。…

0

在预编译 (Pre-Compiled) 的ASP.NET应用中页面设置失效的问题

我的客户有一个验证视图(viewstate)MAC失败的问题。作为应急措施,他想在找出最终的解决方案之前,禁用视图MAC验证。然而当他在配置文件中添加了如下的设置后,还是有问题。 <pages validateRequest=”false” enableEventValidation=”false” enableViewStateMac=”false” viewStateEncryptionMode=”Never”> 客户的应用是一个预编译 (Pre_compiled) 的ASP.NET应用,且可更新(updateable)的选项被禁用。看了由编译器通过上述设置生成的代码后,我们发现这些设置是硬编码。所以这意味着仅仅简单地在web.config里添加上述设置,并不会影响预编译的应用。为了使其生效,必须重新编译整个应用。  [DebuggerNonUserCode] private void __BuildControlTree(default_aspx __ctrl) { __ctrl.EnableViewStateMac = false; __ctrl.EnableEventValidation = false; __ctrl.ViewStateEncryptionMode = ViewStateEncryptionMode.Never; 这是一个By-Design的行为。 ASP.NET预编译概述如下: http://msdn.microsoft.com/en-us/library/bb398860.aspx Wei Zhao from AGPC DSI Team  

0

委托非管理员账号回收IIS 7远程应用池的问题

最近客户频繁问到的一个问题是,当用户没有获得管理员权限时,是否能远程地回收一个IIS主机上的应用池。不幸的是,应用池的回收需要管理员权限才能运行。但是,通过使用MSDeploy,我们能设定recycleAPP provider作为委托,并将其运行在提升后的管理员权限下。然后,通过使用一个本地的标准用户账号或者一个IIS管理员账号,我们能在远程调用recylceApp provider,通过这个提升了权限的recycleApp provider,只要此用户在IIS里有应用池的访问权限,就能远程地回收那些应用池了。 可以通过以下步骤解决此问题: 1) 安装或确认IIS管理服务被激活。 2) 安装服务器和远程机器上最新版本的Web Deploy。相关资料见: http://www.iis.net/download/WebDeploy 3) 在服务器端的IIS中,选择管理服务。勾选“启用远程连接”,如果管理服务(WMSVC)正在停止状态,就启动它。 4) 还是在服务器端,选择管理服务委托,然后选择recycleApp provider。我在IIS的机器里建立了一个管理员账号,叫做Recycler,它将得到提升的权限,以回收应用池。 5) 还是在服务器端,选择“IIS管理员用户”并添加所需的用户。在此例中,我添加了IISUser1。现在,到你所希望被允许执行远程回收的站点,在行为面板中选择“IIS管理员权限”和“允许用户”。 6) 最后,我们现在可以从远程机器运行msdeploy命令进行测试。 msdeploy.exe -verb:sync -source:recycleApp -dest:recycleApp=”Default Web Site”,wmsvc=remote-computer,userName=IISManagerUserName,Password=IISManagerUserPassword,recycleMode=”RecyleAppPool” –allowUntrusted 对于我们的例子,我们将运行如下: 注:如果远程机器上没有合法证书,请使用-allowUntrusted标记。这能忽略那些证书错误。 更多关于Web Deploy recycleApp provider的信息见:http://technet.microsoft.com/en-us/library/ee522997(WS.10).aspx 顺带一提,在某些情境,即使你所有配置都正确,你也可能在运行命令时看到如下的信息。 我有一个客户遇到了这个错误,通过测试能够按下面所述的步骤重现。如果没有安装IIS管理服务角色,就安装msdeploy包;或者当msdeploy在服务器上被激活,而管理服务角色被删了然后重装,缺少必要的handle。要解决此问题,只需重装msdeploy即可。 Matthew from APGC DSI Team  

2

IE访问IIS7.5架设的需Windows认证的网站时出现不停弹框的问题

这是一个安装了IIS的Windows 2008系统,它已运行了一些Sharepoint站点。这些Sharepoint站点使用Windows认证,且他们都正常运行。 现在在此服务器上部署了一个新的Web站点,并启用了Windows认证(采用内核态),但当通过HTTP://MyWebServer:8080或HTTP://MyWebServer.MyDomain.com:8080访问此站点时,IE会不停地请求认证。 首先,我们用域认证信息(domain credentials)测试了基本认证(basic authentication),它是成功的。然后我们启用了登陆事件的审查(audit)功能;不幸的是,不管是否成功进入了Web站点,我们都没能发现任何登陆事件的记录。 为了找出与此有关的更多信息,我们启用了IIS FREB跟踪功能,发现“IIS Web Core”设置了401状态,其错误信息是“拒绝访问”。 现在,我们不得不回来看看对Kerberos纠错最有用的信息——网络监视跟踪记录。从捕获的信息来看,我们确认了Kerberos错误是KRB_AP_ERR_MODIFIED。 有两个引发该错误的常见原因: 1. 错误的DNS设定 2. 客户端发送的ticket被用不同的密钥加密/解密。 我们用netmon确认了DNS的运行在意料之中。我们用Ldp工具审查SPN,当查询SPN时得到了如下的结果 Dn: CN=MyWebServer,…….. …… servicePrincipalName (11): …. HOST/MyWebServer.MyDomain.com; HOST/MyWebServer; …. Dn: CN=SPS_Service_Account……. …. servicePrincipalName (18): …… HTTP/ MyWebServer.MyDomain.com; HTTP/ MyWebServer; …… 我们能看到,HTTP/MyWebServer是SharePoint服务里注册的账号(被用来运行SharePoint应用池),运行在内核态认证的IIS 7以上服务器是不需要它的。然后回IIS MMC查看,我们发现所有SPS站点都采用用户态的Windows认证,它需要把SPN账号注册到应用池认证中。这就是SPS站点以Windows认证的方式运行的原因。 新添加的站点使用用户态Windows认证,需要在机器账号中注册的SPN的账号。这与SharePoint站点产生了冲突。 这解释了为何我们得到了KRB_AP_ERR_MODIFIED错误。当IE访问http://MyWebServer:8080时,请求HTTP/MyWebServer的ticket,它被注册在SharePoint服务的账号里。IE把该ticket传递给Web服务器。在服务器端,IIS尝试使用机器账号对该ticket解密。这必然会失败,因为它被另一个密钥解密。 为了解决此问题: 1. 我们给新添加的站点,如MySite,使用host头,将其加到站点绑定中。 2.注册SPN HTTP/MySite的本机账号 3.现在,我们使用http://MySite访问此Web站点。 随后,我们做以下SPN的配置: MyWebServer: HTTP/MySite HTTP/MySite.MyDomain.com HOST/ MyWebServer HOST/…

0