現在、従業員が Active Directory プロファイルの特定の要素を更新するために使用する .hta ファイルがあります。これにより、システム管理者はその問題に対処する必要がなくなります。.hta ファイルの理由は明らかです。これにより、多くのセキュリティの封鎖が取り除かれ、他の方法では (私の知る限り) 実行できないこと (Active Directory プロファイルの更新など) をマシンで実行できるようになります。
セキュリティへの影響は承知していますが、この .hta アプリケーションをブラウザベースの .net アプリケーションに転送するよう求められています。これは可能ですか？もしそうなら、なぜそれが可能ですか？ブラウザからは比較的不可能な (そしてそうあるべき) もののように思えます。
ブラウザベースの.netアプリケーションの意味によると思います。私は、Web ページとしてユーザーに提示され、AD (または他のリポジトリ) を更新する多くのユーティリティを作成しました。このような場合、アプリケーションの少なくとも一部がサーバー上で実行されます。ブラウザーの Web ページは、このサーバー コードへのアクセスを提供するだけです。
この背後にはいくつかの技術があります。ユーザーが .hta を自分自身として実行すると仮定しています。ASP.NET を使用して同様のことを行うことができます。ASP.NET は IIS 上で実行されます。ブラウザーとして IE を使用している場合は、Windows 統合認証を使用するように IIS (および IE) を構成できます。これは、IE が Windows セキュリティ トークンを IIS に渡すことを意味します。これにより、IIS は、ユーザーが誰であるか、および最近 DC に対して自分自身を認証したことを認識できます。IIS はこれを ASP.NET に渡すので、アプリケーションもこれを認識できます。ユーザーを「偽装」し、ID を使用して処理を行うようにアプリを構成できます。
または、アプリで使用する資格情報を定義し、IIS ApplicationPool を使用して ASP.NET サイトを実行するか、AD を呼び出すときに資格情報をコードで直接使用することができます。私がこれを行ったのは、ユーザーが自分の資格情報ではできないことを実行できるようにしたかったためであり、その権限を委任して直接アクセスを許可したくありませんでした。これは、プロセスに検証を追加できることを意味します。
System.DirectoryServices、別名 S.DS (または System.DirectoryServices.Protocols (別名 SDS.P) と呼ばれる .NET 名前空間を使用しますが、これは使いにくいか、または .NET 3.5 に付属する System.DirectoryServices.AccountManagement) およびそれを使用してADを読み取って更新できます。
詳細を知りたい場合は、質問を更新してください。お手伝いします。