i need to run a WMI script, to create a process on a remote with specific privileges (in a domain).
The scenario is as the following:
Computer A with domain user a
Computer B with domain user b
Computer C with domain user c
Domain admin user, called administrator
from computer A, im running runas.exe, and creating a new CMD prompt with administrator account privileges.
from this command prompt, im running a VBS script to create a remote process on computer B (successfully).
Within the new process on computer B im trying to access directories on both computer A and C. both result in Access denied (5).
when im running on computer B runas, using the administrator privileges, i do have the access to other computer, and the domain admin privileges, but when the process is ran from WMI i dont.
If i am running cmd.exe, and i type whoami, i get DOMAIN_NAME\Administrator, so i know for sure i am running in the domain admin privileges.
Does anyone have an idea of what the reason for this might be?
because i am running from session 0 i dont have premissions to access other computers (some kind of protection mechanism?)
Running in the context of user session (\ session 1 mostly) will fix the authentication problem
Related
Connecting remotely into a windows machine using the OpenSSH service provided by windows always starts an elevated session.
Is it possible to start a non elevated session and elevate after the fact? if so how?
Based on this github discussion: https://github.com/PowerShell/Win32-OpenSSH/issues/1652
bagajjal:
For admin users, ssh connection is an elevated session. Given you are
an admin and has elevated session, you can write to c:\windows.
This is by design.
jborean93:
The biggest issue when you were to use the limited token after an SSH
logon is that you cannot then get your elevated token. On an
interactive logon you can right click and say Run as administrator and
confirm through the UAC prompt but on a network logon like SSH there
is no way for UAC to prompt you. So if this was a functionality you
will never be able to swap from the limited to full token of your
admin account.
I need to call WNetGetConnection to get the UNC path and it works good when application run as standard user but it returns 1201(ERROR_CONNECTION_UNAVAIL) error code when application run as admin. According to the documentation its working as expected.
If the network connection was made using the Microsoft LAN Manager
network, and the calling application is running in a different logon
session than the application that made the connection, a call to the
WNetGetConnection function for the associated local device will fail.
The function fails with ERROR_NOT_CONNECTED or
ERROR_CONNECTION_UNAVAIL. This is because a connection made using
Microsoft LAN Manager is visible only to applications running in the
same logon session as the application that made the connection. (To
prevent the call to WNetGetConnection from failing it is not
sufficient for the application to be running in the user account that
created the connection.)
that means its not possible at all to get the UNC path from the app running as admin ? Is there some other way ?
This is by design. Network shares created by a non-elevated account are not visible under elevation, and vice versa.
See this question on Super User for discussion of the issue. There is apparently a registry setting that enables mapped drives to be shared between elevated and non-elevated accounts but I've never tried it myself.
Network connections cannot normally be shared across different Windows login sessions. This is regardless of admin account / elevation level. Each Windows login or impersonation session needs to create its own network connections.
I am trying to use named pipes on Windows XP SP2+. The pipe server will be a service, running as some kind of administrator / system level account. The pipe client could be any user, possibly a guest, possibly an admin. In my case, I am fine with having a guest account successfully communicate with my service running as administrator.
Before I start using the pipe in my client code, I want to validate that the other side of the pipe is really owned by an administrator / the system.
I have discovered the GetSecurityInfo function, and I think I should be able to use that as part of the solution. However, I don't know how to get from a SID to an "is admin" check.
The default owner for all objects created by an administrative account (including the system account) is the well-known Administrators group, and you can't assign ownership of an object you create to someone else without administrative privilege.
So you can check as follows:
Use GetSecurityInfo to fetch the SID of the owner of the pipe object.
Use CreateWellKnownSid with the WinBuiltinAdministratorsSid option to create a SID for the Administrators group.
Use EqualSid to compare the two SIDs.
Make sure that when you open the pipe (using CreateFile) you pass the SECURITY_IDENTIFICATION flag to ensure that the potentially malicious server cannot impersonate you.
I am working on the examination system and need to implement the following scenario:
User ( standard windows user ) completes the exam and then it is saved on the network share.
For security reasons the share does not have permissions for this user account. So I use impersonation API ( LogonUserEx, ImpersonateLoggedOnUser, RevertToSelf).
It all worked fine when the user with which I do the impersonation had admin privileges on the
local computer but the requirements are that it will be standard user.
With standard user the share is not visible. When I log in interactively with this user the share is visible and writable. So I assume that the standard user can not mount share when not logged in interactively. Is this correct? Is there a workaround?
The only time my code runs with elevated privileges is during the setup of the software.
I thought about using WNetAddConnection2 API but I need the share to be mounted to
this "hidden" user profile and not the administrator one that runs the setup.
I have a script written in Visual Basic that starts a process (given to the script as an argument) on a remote system (again, given as an argument) using WMI. This script works fine when using an Administrator account on the remote system, but when using a non-administrator account, I get the following error:
ConnectServer Failed w/ (-2147024891) Access is denied.
I'd like to be able to run processes on remote systems as a non-administrator user with this script, and I'm pretty sure the problem is due to security settings on the remote system, but I've not been able to reset the right ones.
It sounds like you need to configure launch and activation permissions for this user, on the target machine, via DCOMCNFG. By default non-admin users do not have remote launch and activiation permissions.
Alternatively, depending on the operating system you are connecting to, there may be a "Distributed COM Users" group to which you can add your user. This group already has the appropriate permissions. The Distributed COM Users group was first included in Windows Server 2003 Service Pack 1 (DCOM Security Enhancements).
You can read more about WMI and DCOM permissions here. More detailed steps on how to configure WMI and DCOM are included in the serverfault thread Which permissions/rights does a user need to have WMI access on remote machines?.