直接给结论：这个场景下是可以解决DCOM交互式用户权限错误的，但需要针对性调整DCOM权限配置和IIS应用池身份，而不是依赖默认设置。

下面是具体的分步操作，都是针对你这个ASPX展示数据库数据的场景设计的：

• 第一步：精准配置DCOM组件的权限
  首先打开命令行输入dcomcnfg打开组件服务，找到你用到的DCOM组件：

  1. 右键组件→属性→切换到「安全」标签
  2. 在「启动和激活权限」区域选择「自定义」，点击「编辑」
  3. 添加你的IIS应用池对应的账户（比如默认的IIS AppPool\DefaultAppPool），给它授予本地启动和本地激活权限
  4. 同样在「访问权限」里做相同操作，给该账户授予本地访问权限
  5. 如果你的DCOM组件需要修改配置，还得在「配置权限」里添加该账户并授予对应权限

• 第二步：对齐IIS应用池身份与DCOM权限
  不要让IIS用默认的临时账户跑，建议：

  • 如果是内网环境，可以创建一个域账户，给这个账户分配DCOM的启动/激活/访问权限，同时给它数据库的读取权限
  • 在IIS管理器中找到你的应用池，把身份改成这个域账户，确保密码同步
  • 避免用LocalSystem这类高权限账户，除非业务必须，不然有安全风险

• 第三步：在ASPX代码中显式指定DCOM身份（可选但推荐）
  如果你需要更细粒度的控制，可以在代码里指定DCOM的运行身份，让它和ASP.NET的上下文一致：

  // 实例化你的DCOM对象
  MyDCOMComponent comInstance = new MyDCOMComponent();
  // 设置模拟级别为Impersonation，让DCOM使用当前ASP.NET请求的账户运行
  comInstance.ImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
  

  这能避免DCOM默认用交互式用户身份运行导致的权限不匹配问题

• 第四步：验证数据库权限链
  最后别忘了，整个链路的权限要通：IIS应用池账户→DCOM权限→数据库读取权限，任何一环断了都会出问题。可以用该账户登录服务器，手动测试连接数据库和调用DCOM组件，快速定位问题

之前的类似问题没解决你的场景，大概率是因为没把IIS应用池的身份和DCOM权限绑定起来——很多通用方案只讲了DCOM权限，没结合IIS的运行上下文，所以对你的ASPX场景不适用。

内容的提问来源于stack exchange，提问作者Reginald Lloyd