What account do COM+ components run under when registered via the regasm tool? I didn't notice any command parameters for regasm to identify the account. Given regasm requires admin privileges to run, I'm assuming COM+ components run w/admin privs as well?
What language is your component written in?
if it's in .NET you can set assembly attributes that can control the security configuration of your COM+ application.
checkout http://msdn.microsoft.com/en-us/library/c11b9998.aspx
and in particular: http://msdn.microsoft.com/en-us/library/system.enterpriseservices.applicationaccesscontrolattribute.aspx
I don't know of any command parameters for regasm that can give you permissions.
if you will be more specific about what you are trying to do, I might be able to help you.
Related
I've just developed a .NET program which has the ability to patch itself.
I've noticed that the patching process only runs if I choose "run as administrator".
It seems I need to "create and embedd an Application Manifest", according this this:
https://msdn.microsoft.com/en-us/library/bb756929.aspx
So my question:
Is it normal for applications like mine (which can patch themselves) to require Admin rights, and is this the route I should be going?
Thanks
If your application does not normally require elevation then I don't recommend that you request it in your manifest because it will be very annoying for your users. Firefox uses a NT service to get around the UAC dialog but I can't really recommend that either unless your updates are very frequent.
I would suggest that you write a little updater application that does the patching. It can request elevation in its manifest and this way the user only has to elevate when there is something to patch. If you don't want another .exe in your bundle, you can execute yourself again with the runas verb when you need to patch.
Edited the NSIS script to include this line:
AccessControl::GrantOnFile \"$INSTDIR" "(S-1-5-32-545)" "FullAccess"
This gave the User account full access to the application folder within Program Files, meaning my patcher could write to it without any problems.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH
Folks,
I've got a strange issue at the moment with a visual studio 2010 built MSI...
When I run the msi, it performs a few tasks, then executes a tool we built - this tool then carries out some more advanced work we couldn't do within a custom task.
The issue here, is then when the msi starts my custom built tool, it doesn't execute it with the same credentials as I start the MSI with (i.e. my administrative login).
Is there a parameter I can pass to an MSI to enforece this? Or perhaps I can pass the credentials to the process when I start it?
My process is started using Process process = Process.Start(procInfo) nothing fancy. I've also noted the ability to pass in a parameterised username/password/domain, but this will vary depending on the user who is installing - can this be extracted from the installer somehow?
Any help (or questions) welcomed.
Dave
EDIT: for clarity... I'm running the MSI under my domain account, and I want my custom process to run under that 'context'. At present, it starts (regardless of whether I start as administrator or not) under the SYSTEM account (rather than mydomain\me). I'm using Windows Server DataCenter edition if that helps...
I should also add, I think this is a policy issue, but I've no idea what to check/where to check...
By default Windows Installer runs custom actions as the current user. If the MSI is elevated, custom actions will run as the elevated user.
Please note that if you are running the MSI as an Administrator, it doesn't mean your custom actions will have full Administrator privileges. On Vista or higher any user can gain Administrator privileges through elevation.
So if your custom actions need Administrator privileges, make sure they use the msidbCustomActionTypeNoImpersonate flag so they run under the local system account.
If this is not the problem and you just need access to the current user data, can you please give me more details?
Is it possible to successfully deploy an assembly containing event handlers for a custom SharePoint list feature (thus, classes that depend on the Microsoft.SharePoint assembly) to a web application's bin instead of the GAC?
The option to do so certainly appears to be present in the XML markup in my feature's manifest.xml file. However, I've seen several references that deploying CAS policies for the assembly are a must with little instruction on how to successfully achieve this for an assembly that requires privileges like access to the SharePoint object model. I've also seen discussion suggesting that the GAC is nearly a requirement because of difficulties/issues with CAS.
I have been able to actually deploy the assembly to the folder. The security issues however, have been a big impediment. The only way I've been able to get my assembly to run (instead of simply erroring out with exceptions) is by elevating the web.config's trust level to <trust level="Full" originUrl=""> which won't fly in my environment. I'm hoping to verify that what I'm trying to do is possible before I continue to further wrestle with CAS.
If this is possible, if anyone has guidance or resources that would assist me in modifying my feature to deploy my event handlers in this fashion, I'd appreciate it.
Don't elevate the web.config's trust level - pretty large hammer for a tiny problem. You must package up a custom CAS policy in your WSP to grant your assembly higher privileges that the web.config bestows on it.
-Oisin
One way to approach this is to crank up the logging, record the various exceptions that are thrown and then write a CAS policy manually. This is a very probabalistic approach and rather painful.
It seems likely that all of the permission demands for any given method or class are known up front. If so, it should be possible to write a tool to statically analyse your code and dependant assemblies and compose the required CAS file. Unfortunately, I'm not aware of any tool that does this.
For what it's worth, GAC'ing your assembly seems much "lighter" than upping the trust level.
If I got your question right, you want to deploy a list event receiver to the web application's BIN directory.
This is not possible within SharePoint 2010, but I don't know if it was supported on MOSS 2007 (i guess it wasn't supported either).
This behavior is by design, because SharePoint internally uses the System.Reflection.Assembly.Load() Method to load the event receiver assembly. The Load() method does only work with fully qualified assembly names, thus requiring the assembly to reside in the global assembly cache.
I am using Visual Studio 2008 to build an MSI install package. Within the install I have numerous custom actions. Within the OnAfterInstall custom action I attempt to start an exe which is deployed by the install. The exe starts ok, but runs within a security context of NT AUTHORITY\SYSTEM (i.e. under the elevated privileges granted to the Windows Installer process). I actually need the exe to run in the security context of the currently logged-on user who started the install in the first place. Does anyone know how to start the exe so it runs in this 'reduced' context. I really want to avoid having to ask the user for their login credentials if possible.
You need to use Remote Desktop Services API: http://msdn.microsoft.com/en-us/library/aa383464%28v=VS.85%29.aspx . It is available starting from WinXP.
This API allows you to run your application in context of any logged in user account. You need to be running as a SYSTEM to be able to use it. And you are.
For instance you may enumerate sessions using WTSEnumerateSessions, then take user token by WTSQueryUserToken and run application using this token.