We deploy our .NET applications by putting them on the LAN, and allowing users to run from there. We are part of a very large organization and do not have have admin rights to the individual computers, the servers, nor the domain. We don't even have admin rights to our development machines.
When a user runs application a Dot-Net application from a network share, it fails due to a security exception. In the past, we've used CASPOL (user level) to trust the file server, but this is a headache. We've developed custom code to copy the assembly to the local drive before execution, effectively bypassing trust issue. Neither solution is a good answer. I understand that Dot Net 3.5 will eliminate the issue.
When we broached the topic with our IT section, they gave us blank stares when we asked about setting trust on a machine or server basis.
A Microsoft site says
If you are the code's developer or publisher, you may also digitally sign it and then modify security policy to grant more permissions to code bearing that signature.
One of our IT people is asking me about what we need in regards to the cryptographic key. I want to make sure my assumptions are correct before responding.
- Assumption One: A key genereated by the SN.EXE tool can be somehow trusted at either a domain or enterprise level.
- Assumption Two: Once such a key is trusted, and we sign our code with it, the assemblies will be trusted to run off of a network share.
- Assumption Three: The "trusting" is an action of the part of the domain admin/enterprise admins and would be global for the domain/enterprise. My guess is that they would add it to the enterprise/domain key store through some active directory magic.
Are my assumptions correct, or am I way off base? One last question, could this same key be used to sign vba macros?
