8
.NETアプリケーションをLAN上に配置し、ユーザーがそこから実行できるようにして展開します。私たちは非常に大規模な組織の一員であり、個々のコンピュータ、サーバー、またはドメインに対する管理者権限を持っていません。私たちは開発マシンに対する管理者権限も持っていません。ネットワーク共有上の.NETセキュリティ例外
ユーザーがネットワーク共有からDot-Netアプリケーションを実行すると、セキュリティ例外のために失敗します。以前は、CASPOL（ユーザーレベル）を使用してファイルサーバーを信頼してきましたが、これは頭痛です。実行前にアセンブリをローカルドライブにコピーして、信頼の問題を実質的に回避するカスタムコードを開発しました。どちらの解決策も良い答えです。私はDot Net 3.5がこの問題を解消することを理解しています。
IT部門の話題を紹介したとき、マシンまたはサーバーごとに信頼を設定するように頼んだときに、彼らは私たちに空白の目をつけました。
Microsoft siteを使用すると、コードの開発者や出版社であれば、あなたはまた、デジタルそれに署名し、その署名を保有する コードに多くの権限を付与するためのセキュリティポリシーを変更 こと
言います。
私たちのIT担当者の1人が、暗号鍵に関して必要なものについて私に尋ねています。私は私の前提が正しかったことを確認してから応答したいと思っています。
- 仮定ワン：SN.EXE toolによってgenereatedキーは、何らかの形で、ドメインまたはエンタープライズレベルのいずれかで、信頼することができます。
- アサンプション2：このようなキーが信頼され、コードで署名されると、アセンブリはネットワーク共有から逃れることができます。
- アサンプション3：「信頼」はドメインadmin/enterpriseadminsの部分のアクションであり、ドメイン/エンタープライズにとってグローバルになります。私の推測では、いくつかのアクティブディレクトリの魔法を使ってエンタープライズ/ドメインのキーストアに追加することになります。
私の前提は正しいですか？最後の質問ですが、これと同じキーを使ってvbaマクロに署名できますか？
ITへの周りのキーを送信することに対処するために持っていけないが、その実際にはいけない。この方法では、 .net4は、2.0ランタイムを使用しているので3.5ではなく、この問題を解消します。 – aL3891
この質問を投稿する前に、いくつかのStackOverflow投稿を読み込んでいましたが、ほとんどの人が3.5をセキュリティポリシーで削除しました。私はもっと調査します。 –
@ aL3891：.NET 3.5 SP1では、デフォルトでローカルイントラネットへの完全な信頼が与えられます（http://blogs.msdn.com/b/shawnfa/archive/2008/05/12/fulltrust-on-theocalinranet.aspx） 。 .NET 4.0では、コアCLRによるCASポリシーの評価が削除されています（http://blogs.msdn.com/b/shawnfa/archive/2010/02/24/so-is-cas-dead-in-net-4- or-what.aspx）。 –