目前,我们有一个 .hta 文件,员工可以使用它来更新其活动目录配置文件的某些元素。这使系统管理员不必处理该问题。.hta 文件的原因是显而易见的。它解除了许多安全障碍,并允许机器执行其他情况下无法执行的操作(例如更新活动目录配置文件)(据我所知)。
我意识到安全隐患,但我们被要求将此 .hta 应用程序转移到基于浏览器的 .net 应用程序。这甚至可能吗?如果是,为什么可能?从浏览器看来,这似乎是(并且应该是)相对不可能的事情。
目前,我们有一个 .hta 文件,员工可以使用它来更新其活动目录配置文件的某些元素。这使系统管理员不必处理该问题。.hta 文件的原因是显而易见的。它解除了许多安全障碍,并允许机器执行其他情况下无法执行的操作(例如更新活动目录配置文件)(据我所知)。
我意识到安全隐患,但我们被要求将此 .hta 应用程序转移到基于浏览器的 .net 应用程序。这甚至可能吗?如果是,为什么可能?从浏览器看来,这似乎是(并且应该是)相对不可能的事情。
我想这取决于您所说的基于浏览器的 .net 应用程序的含义。我编写了许多实用程序,这些实用程序以网页的形式呈现给用户,并更新了 AD(或其他一些存储库)。在这些情况下,至少有一部分应用程序在服务器上运行。浏览器中的网页仅允许访问此服务器代码。
这背后有几项技术。我假设您的用户自己运行 .hta。您可以使用 ASP.NET 执行类似的操作。ASP.NET 在 IIS 上运行。如果您使用 IE 作为浏览器,则可以将 IIS(和 IE)配置为使用 Windows 集成身份验证。这意味着 IE 将 Windows 安全令牌传递给 IIS,以便 IIS 知道用户是谁,并且他们最近已向 DC 进行了身份验证。IIS 将此传递给 ASP.NET,因此您的应用程序也可以知道这一点。您可以配置您的应用程序,使其“模拟”用户并使用他们的 ID 执行操作。
或者,您可以定义应用程序使用的凭据,并使用 IIS 应用程序池运行 ASP.NET 站点,或者在调用 AD 时直接在代码中使用凭据。当我希望用户能够使用他们自己的凭据做一些他们不能做的事情并且我不想通过将权限委派给他们来授予他们直接访问权限时,我已经这样做了。这意味着我可以在流程中添加验证。
您使用名为 System.DirectoryServices 的 .NET 命名空间,也称为 S.DS(或 System.DirectoryServices.Protocols(又名 SDS.P),但这更难使用,或 System.DirectoryServices.AccountManagement 随 .NET 3.5 提供)和您可以使用它来阅读和更新 AD。
如果您想了解更多信息,请更新您的问题,我会尽力提供帮助。