英文:
WebDAVModule: Cannot query authoring rules
问题
IIS正在从Windows 2012升级到Windows 2022,同时IIS从v8.5升级到v10。该服务器上托管的应用程序是一个文件上传网关,通过https://接收文件,可以使用POST或PUT方法。对于PUT方法,我们使用WebDAV来处理。为了预测试此迁移,我将生产服务器克隆到一个单独的VNet中,以避免与原始生产服务器冲突。原始生产服务器位于域中,但所有文件上传的用户帐户都是本地帐户,域对服务器的功能并不重要。因此,我将测试服务器退出了域,加入了一个工作组(WORKGROUP)。
我在Postman中设置了两个测试用例,以测试POST和PUT方法。我已经测试了这两个用例对我的生产服务器,每个Postman测试用例都有效!现在我将主机名更改为我的测试服务器。奇怪的是,POST方法成功了,但PUT方法失败了。我打开了失败请求跟踪,以下是我找到的信息:
无法查询授权规则
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>3</Level>
<Opcode>5</Opcode>
<Keywords>0x200</Keywords>
<TimeCreated SystemTime="2023-05-31T18:31:35.121Z"/>
<Correlation ActivityID="{40000004-0006-FD00-B63F-84710C7967BB}"/>
<Execution ProcessID="7412" ThreadID="5536"/>
<Computer>R8EUSXREX</Computer>
</System>
<EventData>
<Data Name="ContextId">{40000004-0006-FD00-B63F-84710C7967BB}</Data>
<Data Name="ModuleName">WebDAVModule</Data>
<Data Name="Data1">Cannot query authoring rules</Data>
<Data Name="Data2">/_REXDTSTesting/ab6b04fd/MyFile[r8#e13c1f92ba614aee80f2b5694a6094ff].txt</Data>
<Data Name="ErrorCode">2147943732</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>MODULE_WARNING</Opcode>
<Keywords>
<Keyword>Module</Keyword>
</Keywords>
<freb:Description Data="ErrorCode">No mapping between account names and security IDs was done.
(0x80070534)</freb:Description>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/events/trace">
<EventGuid>{D79A948E-95F1-417B-A731-B7A79DEC7AE5}</EventGuid>
</ExtendedTracingInfo>
</Event>
需要注意的几点:
这发生在基本身份验证成功之后。凭据是有效的。以下是跟踪的摘要(下面的摘要在实际跟踪输出中位于上面),以证明这一点:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>4</Level>
<Opcode>11</Opcode>
<Keywords>0x2</Keywords>
<TimeCreated SystemTime="2023-05-31T18:41:42.723Z"/>
<Correlation ActivityID="{40000002-0000-FC00-B63F-84710C7967BB}"/>
<Execution ProcessID="7412" ThreadID="5836"/>
<Computer>R8EUSXREX</Computer>
</System>
<EventData>
<Data Name="ContextId">{40000002-0000-FC00-B63F-84710C7967BB}</Data>
<Data Name="AuthType">4</Data>
<Data Name="NTLMUsed">false</Data>
<Data Name="RemoteUserName">_REXDTSTesting</Data>
<Data Name="AuthUserName">_REXDTSTesting</Data>
<Data Name="TokenImpersonationLevel">2</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>AUTH_SUCCEEDED</Opcode>
<Keywords>
<Keyword>Authentication</Keyword>
</Keywords>
<freb:Description Data="AuthType">NT</freb:Description>
<freb:Description Data="TokenImpersonationLevel">ImpersonationImpersonate</freb:Description>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/events/trace">
<EventGuid>{C33BBE8F-985B-4080-81E6-005F1A06B9E2}</EventGuid>
</ExtendedTracingInfo>
</Event>
因此,身份验证已成功。WebDAV授权规则确实存在。实际上,我已将其删除并重新创建,以排除从域到工作组的过渡可能引起的任何混淆。Web应用程序以LocalSystem身份运行。简而言之,所有这些问题的最终问题是,为什么WebDAVModule无法查询授权规则?
谢谢您的帮助!
英文:
I am upgrading an IIS application server from Windows 2012 to Windows 2022. Naturally, IIS is being upgraded from v8.5 to v10 during the course of the OS upgrade.
The application hosted on this server is a file upload gateway. It accepts files via https:// using either POST or PUT. For the latter, we use WebDAV to process the PUT. (Our application, engineered as an HttpModule performs some "extension processing", we rewrite the name of the file placed onto our server and we log certain data to our application database. I mention this just for the sake of completeness. These features are working well when files are POSTed to the application server.)
In order to pre-test this migration, I set up a clone of our production server into a separate VNet so it won't conflict with the original production server. The original production server is in a domain, but user accounts for all file uploads are local accounts and the domain is not integral to the server's function. Therefore, I've exited the test server - in its separate VNet - from a domain which is simply inaccessible to it and I'd joined it to a workgroup - WORKGROUP.
I have two test cases set up in Postman, to test both POST and PUT. I've tested both of these against my production server. In each case the file is created on the server. Each Postman test case is valid! Now I change the host name to my test server. Oddly enough, the POST succeeds but the PUT fails. I turned on Failed request tracing and here is what I find:
Cannot query authoring rules
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>3</Level>
<Opcode>5</Opcode>
<Keywords>0x200</Keywords>
<TimeCreated SystemTime="2023-05-31T18:31:35.121Z"/>
<Correlation ActivityID="{40000004-0006-FD00-B63F-84710C7967BB}"/>
<Execution ProcessID="7412" ThreadID="5536"/>
<Computer>R8EUSXREX</Computer>
</System>
<EventData>
<Data Name="ContextId">{40000004-0006-FD00-B63F-84710C7967BB}</Data>
<Data Name="ModuleName">WebDAVModule</Data>
<Data Name="Data1">Cannot query authoring rules</Data>
<Data Name="Data2">/_REXDTSTesting/ab6b04fd/MyFile[r8#e13c1f92ba614aee80f2b5694a6094ff].txt</Data>
<Data Name="ErrorCode">2147943732</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>MODULE_WARNING</Opcode>
<Keywords>
<Keyword>Module</Keyword>
</Keywords>
<freb:Description Data="ErrorCode">No mapping between account names and security IDs was done.
(0x80070534)</freb:Description>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/events/trace">
<EventGuid>{D79A948E-95F1-417B-A731-B7A79DEC7AE5}</EventGuid>
</ExtendedTracingInfo>
</Event>
Several things to keep in mind.
This happens AFTER Basic authentication has succeeded. The credentials are valid. Here is the abstract from the trace (the abstract below precedes the one presented above in the actual trace output) to prove it:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>4</Level>
<Opcode>11</Opcode>
<Keywords>0x2</Keywords>
<TimeCreated SystemTime="2023-05-31T18:41:42.723Z"/>
<Correlation ActivityID="{40000002-0000-FC00-B63F-84710C7967BB}"/>
<Execution ProcessID="7412" ThreadID="5836"/>
<Computer>R8EUSXREX</Computer>
</System>
<EventData>
<Data Name="ContextId">{40000002-0000-FC00-B63F-84710C7967BB}</Data>
<Data Name="AuthType">4</Data>
<Data Name="NTLMUsed">false</Data>
<Data Name="RemoteUserName">_REXDTSTesting</Data>
<Data Name="AuthUserName">_REXDTSTesting</Data>
<Data Name="TokenImpersonationLevel">2</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>AUTH_SUCCEEDED</Opcode>
<Keywords>
<Keyword>Authentication</Keyword>
</Keywords>
<freb:Description Data="AuthType">NT</freb:Description>
<freb:Description Data="TokenImpersonationLevel">ImpersonationImpersonate</freb:Description>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/events/trace">
<EventGuid>{C33BBE8F-985B-4080-81E6-005F1A06B9E2}</EventGuid>
</ExtendedTracingInfo>
</Event>
So authentication to the server has succeeded. The WebDAV authoring rule does exist. In fact, I deleted it an recreated it to rule out any confusion which might have been caused by the transition from Domain to Workgroup. (These are local accounts, and I can't envision any direct correlation but no harm to drop and recreate the rule, just to rule that out.)
The web application runs under the identity of LocalSystem.
In a nutshell, the final question this all leads up to is, why can't WebDAVModule query the authoring rules?
Thanks for your assistance!
答案1
得分: 0
问题出在那些模糊不清的用户上,就是下面截图中作者规则的第一行。这些用户帐户是域帐户。但我已将此服务器从域中移出,因此WebDAV尝试解析这些用户失败了。这导致WebDAV放弃了继续处理任何其他作者规则的尝试。(有人可以争论说,WebDAV在这方面应该更具容错性,因为删除一个终止用户的帐户 - 例如 - 可能会导致所有的作者规则失效。但事实如此。)
因此,为了使这对更广泛的上下文有意义;如果您看到此WebDAV错误 - 无法查询作者规则 - 请确保您作者规则中识别出的帐户都是有效的!
一旦我删除了那些有问题的用户帐户,我的PUT请求就开始成功了!
英文:
The problem was due to those smudged out users, the first line of authoring rules in the screenshot below. Those user accounts are domain accounts. But I had pulled this server out of the domain so WebDAV's attempt to resolve those users failed. This aborted WebDAV's attempt to process any more authoring rules. (One could argue that WebDAV should be more fault-tolerant in this regard since the deletion of a single account for a terminated user - for example - can bring down all of your authoring rules. But, it is what it is.)
So to make this relevant for the broader context; if you are seeing this WebDAV error - Cannot query authoring rules - check to ensure that the accounts identified in your authoring rules are all valid!
As soon as I removed those offending user accounts, my PUTs started succeeding!
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论