I have some problems regarding WMI scripting on Windows 8. More precisely, remote connection from Win7(not that relevant) to Windows 8. Note that the following issues do not happen when the client machine runs Windows 7.
First one is getting data regarding the current shares on that machine. Specifically, I am trying to get the Path property of the shares, that is local path.
In windows 7 it works perfectly, in windows 8 however it returns null(ran with wbemtest from remote computer).
First I thought that there is a problem with the WMI system. Then I ran the same query directly on the win8 machine. That returned the actual local path of the share. This led me to believe that there are problems with the WMI security on that machine.
Another issue I have with WMI on win8 is that it does not allow me to run things as Administrator, even though the user used to log is is the Administrator.
Regarding the security settings on the win8 machine, I gradually lowered them to try the exact position in which I can operate. I have reached the level where Everyone has every access, so it is the lowest security possible. Hope someone can help.
After a few days of just playing with security around Wmimgmt.msc and dcomcnfg I finally found a way to run wmi as administrator on a remote machine. Although this is not exactly what I did, I found that this works great: I activated the Administrator account: net user administrator /active:yes. Then I entered User accounts and set a password for the Administrator account. I then opened Wmimgmt.msc and set allow on all security for the Root node and cimv2 node. After this Wmi remotely(logged on as administrator) works as a charm
Related
I had one client who could not connect to a samba share giving the error that the credentials where wrong while I was sure they where not.
This happened suddenly on a laptop with Windows 10 while other clients with Windows 10, Windows 7 and Ubuntu etc. all where able to connect.
At first I was suspecting the problem beeing a change in the hash or key for the share - and maybe it really was because Putty was saying so when I tried to SSH into the server.
But I could not find any saved connection to delete with net use.
The solution was to change a setting in secpol.msc which is accessible as administrator via the search even in Windows 10 Home.
I had to set LAN-Manager-Authenticationlevel to just send NTLMv2.
You will find this setting under Security settings -> local -> Security options -> Network Security: LAN-Manager-Authenticationlevel.
(I translated this from German. Feel free to edit with nativ english wording.)
I have Visual Studio 2013 and a pretty basic MVC web application.
When I am connected to my work network (hard wire or VPN) I can open up VS without issue. However when not connected to my work network I get the following error:
---------------------------
Microsoft Visual Studio
---------------------------
Creation of the virtual directory http://localhost:54156/ failed with the error: Unable to access the IIS metabase. You do not have sufficient privilege to access IIS web sites on your machine.
---------------------------
OK
---------------------------
I've tried granting my user rights to IIS via the aspnet_regiis -ga mydomain\myuser and that did not help.
I am certainly running VS as an administrator. It works just fine when connected to the network. Our security and server teams do not seem to understand why this would behave this way.
Is this IIS Express? I (and those I work with) often get a similar error due to the domain login script encrypting My Documents. It's fixed by simply decrypting
Documents\IISExpress\config\applicationhost.config
Not sure if that's the issue here though;
Ultimately I believe this to be an issue between our network policies and the IIS and .NET installs.
When I was off network it could not access the cached user folders. Switching from having the home drives on network to having them local did not fix the issue (assuming some files were still referencing the network location).
I had my system refreshed and started with my user folders as local and have not had the issue since.
I know it's an old question, but at my location the user profile is stored on the network. When I checked to see if the IISExpress application was encrypted as Chad Schouggins suggested, I didn't even have a documents folder. Ultimately, the answer was really simple:
turn the machine off and back on again.
I have a small winforms app that creates a new event log source.
I run it as administrator for the elevated privileges.
The code checks to ensure the specified event log does not exist and then creates the source. This worked fine on my Windows 7 machine, but when I run the app on Windows Server 2008 R2 SP1 it tells me the source already exists. I know it doesn't because a) this is a fresh installed of Windows Server 2008 R2, and b) I added code to return a list of all the log sources and my new one was not in the list.
I know about the "first 8 characters" being the significant ones and I made sure my source names was completely unique.
Here's the super-easy code (of course I have try/catches around this):
if (!EventLog.SourceExists(sourceName))
{
EventLog.CreateEventSource(sourceName, logName);
}
Can anyone tell me why Windows Server 2008 is lying to me?
Local (or domain) administrators are not the most powerful accounts on a Windows box.
There are other accounts that have higher (though also more limited) access.
SourceExists() will return false if it exits but you don't have access rights to know about it, and it's perfectly possible for an administrator to be denied access to something.
Also, there are reserved names for things in odd places that can trip you up. Creating folders with the names CON COM or LPT used to cause odd issues on server 2003.
So there also are a whole bunch of reasons why CreateEventSource() can fail - dig into the inner exception(s) as well, often those provide critical detail.
Which event log source name was failing for you?
Would you post the exception stack?
I'm working on a DCOM application with the server and client on two machines, both of which are running WinXP with Service Pack 2. On both machines, I'm logged in with the same username and password.
When the client on one machine calls CoCreateInstanceEx, asking the other machine to start up the server application, it returns E_ACCESSDENIED.
I tried going into the server app's component properties in dcomcnfg and giving full permisions to everyone for everything, but that didn't help.
What do I need to do to allow this call to succeed?
Update: When the server app is running on a Windows 2000 box, I do not get this error; CoCreateInstanceEx returns S_OK.
Right, so if your Authentication level is set to Default. What is the authentication level set to in the Default Settings? Just out of interest. (although the fact that it works to a 2000 box probably makes that redundant)
EDIT:
Also: I seem to remember doing a lot of rebooting when I used to play/work with DCOM so maybe a quick reboot of both machines when you're happy with the dcomcnfg settings wouldn't go amis either.
If the PCs aren't both members of the same domain, you need to also given launch & access permissions to "ANONYMOUS LOGON". "Everyone" does not include this.
Three things to check:
1) Go back to dcomcnfg and make try making sure that not just the access security but also the "launch permissions" section contains the appropriate security users or groups.
2) Ensure that the Authentication Level is set to something else other than "None"
3) Also check that the location on disk that the component is located is actually accessible to the account configured in the security permissions you set.
EDIT:
One more: Are you calling CoInitialiseSecurity() first too? That rings a bell!
EDIT2:
Based on your update: Try dropping the firewalls completely on both XP machines and see if that makes a difference. You may need to let DCOM through explicitly.
What is the flavor of your Windows 2000 box, btw? Professional, Server, Adv Server...
Also, is there a difference between domain membership between the two (one on a domain, the other not, different domains, etc...?)
One more thing - DCOM errors will appear in the System event log at times - especially for object creation - did you check there for clues?
I had the exact same problem.
The problem happens in machines that have XP SP2+ OS or newer.
I solved it using the following steps:
Verify that both client and server computers are on the same domain.
You need to use the same user in both computers, or, if you want to use different users in client and server you need to make sure that both client and server users have privliges on both computers (in particular - make sure that they are members of Distributed COM users group.
open Componenet services MMC (run dcomcnfg).
Go to My Computer->Properties->Default Properties and make sure that Default Impersenation Level is "Identify"
Go to COM Security tab, in both in Access permissions and Launch and activation permissions go to Edit Limits, and add Local and Remote access permissions to the client and server users of your COM application
Make sure that you have a firewall exception in port 135 for your application...
I hope this helps you!
Okay, so I'm running a small test webserver on my private network. I've got a machine running Windows 2000 Pro, and I'm trying to run an ASP.NET app through IIS.
I wrote it so that the webpage would use the registry to store certain settings (connection strings, potentially volatile locations of other web services, paths in the local filesystem where certain information is stored etc...) Of course, it worked fine when testing with VStudio.NET 2005, because the user running the app has elevated privileges. However, running it on IIS I get a "Access to the registry key 'HKEY_LOCAL_MACHINE\Software' is denied.", which suggests the IIS user doesn't have read access to that part of the registry (I only do reads through the website itself, never writes).
I was like "okay, simple enough, I'll just go give that user rights to that part of the registry through regedit." The problem is, I don't see an option anywhere in regedit to change security settings... at all. Which got me thinking... I don't think I've ever actually had to change security settings for registry hives/keys before, and I don't think I know how to do it.
Half an hour of searching the web later, I haven't found any usable information on this subject. What I'm wondering is... how DO you change security rights to portions of the registry? I'm stumped, and it seems my ability to find the answer on Google is failing me utterly... and since I just signed up here, I figured I'd see if anyone here knew. =)
If your having touble with RegEdit in Windows 2000 you can try the following:
Copy the Windows XP RegEdt32.exe to the Windows 2000 Machine
Using a Windows XP Machine, connect to the Windows 2000 registry remotely: File > Connect Network Registry
You can set permissions at the folder level for which you want to grant user permissions read/write access.
In your case, right click on the "Software" folder and select "Permissions".
You'll probably know the rest from there.
EDIT: If you still run into issues, you may want to modify your web.config file and use impersonation to have your web application run as a certain user account. Then you can put a tighter reign on the controls.
RegEdt32.exe will allow you to set permissions to registry keys.
Simply right click on a Key (Folder) and click Permissions, then you can edit the permissions as you would an file system folder.
I did so, assuming that a Security setting would be available. I didn't see any "Security" option when I right-clicked on the Key. =( I triple-checked just to make sure... and I just tried it on my XP machine, and it does indeed have the "Permissions" section... but the Windows 2000 machine doesn't. (how's that for wierd?)
In my searching, I found:
http://www.experts-exchange.com/Programming/Languages/.NET/ASP.NET/Q_21563044.html
Which notes that RegEdit for Windows 2000 doesn't have the Security/Permissions settings... but it proposes no solution to the problem. (Whoever asked the question was using Windows XP so he was okay... but in my case, it's 2000)
Is there any way to make it happen specifically in 2000?
EDIT: Ahhhh... if worse come to worse, I suppose I can do the impersonation as mentioned below... though if I can't set security settings for the registry in 2000, I'm left with making that user have Administrative access (I assume?) to actually get those rights, which sadly defeats the purpose. =(
Oh, let me try that! I didn't realize you could remotely connect to another registry.
(EDIT: I was wrong, it did work... it just took several minutes to respond to my request to change permissions remotely)
The remote connection idea did it! You're good! Thanks so much for your help! I never realized you could remote connect with RegEdit... you learn something new every day, they say! =) Thanks again for your assistance! =)
On another note though, about copying the XP version of RegEdit to Windows 2000... is that safe? I figured they would be coded in such a way as to be incompatible... but I could be assuming too much. =)
Just use RegEdt32.exe instead of Regedit.exe.
Go to the desired key or folder, then open the security menu and click on 'permissions'.