how do I turn off PC using remote desktop with simple user account?
There is a need to restart PC that users often leave on.
PC has no local admin account.
Simple batch "shutdown" just writes that user doesn't have rights.
Could it be possible with some services or programmatically in C# or using remote admin from inside app on the PC (I have access to domain admin) ?
shutdown.exe, but performed by an user that has the SeShutdownPrivilege priviledge. If the user has no privileges to initiate a shutdown with shutdown.exe, then it won't have the privilege with any other API. If such a way would exists, it would be a security vulnerability and that way would be called an 'exploit'.
Grant this privilege to your user so it can shutdown the PC. Open Local Security Settings MMC snap-in, navigate to User Rights Assignments, and grant this privilege, see Assign user rights for your local computer.
Related
imagine there is a Powershell script running under the SYSTEM account on a Windows 10 machine and checks which domain user is currently logged on. No big deal.
Now: I want to check if this logged on user has administrator rights on this machine. Every check I could find so far is only looking at ".IsInRole([Security.Principal.WindowsBuiltInRole]::'Administrator')".
But this only checks if the user is a direct member of the local group "Administrators". But it is possible that within the local Administrators group there is a domain group, and the user is a member of this domain group instead. So he is admin, even if he is not a direct member of the Administrators group.
How can I check for both at the same time? I just want to check IF someone is admin, no matter where those admin rights come from. This check will also run under the SYSTEM account, not with the affected user account itself.
Any ideas?
If the Domain group is part of the local admins group, then by design, all users in that domain group are local admins and has all the rights and privileges that means. So, that code block would still apply.
You have to explicitly check for user rights and privileges assigned. There is no cmdlet for this built-in, so you have to code for it. To see your rights and privs, you can just use the good old whoami.exe...
whoami /priv
# Results
<#
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
#>
... then compare that to the Windows Privilege list that are normally used for Administration actions.
Running this remotely as the logged-on user, cannot be done with PowerShell natively, it's a Windows Security boundary and thus, you'll need something like PSExec.exe from MS SysInternals to try that.
I recently came across an interesting feature of Windows PowerShell JEA (Just Enough Administration) which by default makes use of Windows virtual accounts to run the remote end point in admin context. I also understand these virtual accounts are created ephemeral for that session and get destroyed when the session ends. This also by default has the local admin rights on the machine for that session while the user running the session is a standard user who can carry out privileged operations using that virtual admin account.
This got me into thinking - we have a few apps in our organisation which sadly need local admin rights to run. We are reluctantly granting admin rights for the users of those apps. So I was wondering if there is a way through PowerShell we can create this Virtual account for the duration of however long that application runs? What I am thinking is some sort of wrapper PowerShell which is targeted by the application shortcut which would internally first spin up this virtual account to run that app as? I am assuming we need to configure some sort of one-off constrained custom app-specific JEA endpoint during the installation of the application. Then again, if the app requires the launching user's context to access back-end database etc. I am not sure how that would be taken into account.
I was just wondering if you have any clever thoughts? Thanks, Steve
I'm new to DB2 database. I installed DB2 Express-C on my local machine (Windows 10) to play with it, and I created a sample database.
If I understand correctly, DB2 uses Windows accounts for access to database. The installation created a db2admin user, but this one does not have access to the sample database. So my understanding is that my Windows account has access to this database.
So here is the problem. My company uses Azure Active Directory accounts, using Windows Hello to log in - that means, using a PIN to log in instead of a password (meaning my password does not work for login). However, if I want to connect to the database, I need to do this with my account's password. How can I do this? Do I need to create a local account on my machine instead of using Azure account?
If you are able to create a local-user on your workstation, and assign it a password, and ensure it is a member of local groups DB2USERS (and optionally) DB2ADMNS if those local-groups exist, that is likely to be the easiest option.
You may need to have Windows local-administrative rights to be able to perform those actions.
You can then connect to any local Db2-databases with that local-account and its password (regardless of how you sign-in to Windows).
If you allowed Db2-installation to create local user db2admin (and give it a password) then that local-account is also able to connect to local Db2-databases, including the SAMPLE database. So it's unclear why you write that db2admin account does not have access to SAMPLE database. As long as db2admin has a valid password then that account can connect to SAMPLE if all default settings are active.
Db2-LUW is able to integrate with Active-Directory provided pre-requisites are met and special configuration is performed, see documentation. But unless you have special security plugins for Db2, then any account that wants to connect to local Db2-databases will need a password. With special security plugins, other forms of authentication are possible.
Windows 10 Azure account login gives license to only one user to access windows account. If you login with db2admin in your windows you might lost azure account I am facing such issues.
Better to communicate with IT team of your company and ask to provide DB2ADMN right to your Azure login user. DB2 install properly but not able to create database permission/authorization issue coming.
In our current environment all the users who would like to access ClearCase will require local administrative rights and i'm looking into the options to remove the local admin privs constraint so that all the users should be able to access if they are part of clearcase domain groups like CCUsers.
Local admin privilege should only be required for installing ClearCase, especially when it comes to the MVFS (MultiView FileSystem) part.
But it is also used for launching ClearCase services. Without a privilege elevation, you would see:
C:\>net start albd
System error 5 has occurred.
Access is denied.
From Windows Services
Unable to open service Albd for writing on Local Computer
Error 5: Access is denied.
First, check if you can set those services as "Automatic": they should be started during Windows Startup, even if the user is not an administrator.
This thread recommends:
Click on Atria Location Broker service and select Properties.
On the General tab, "Startup type" should be "Automatic".
On the Log On tab, select the radio button to Log on as "This account" and enter the ALBD user account and password that you should have already setup (e.g. your-domain\clearcase_albd). If you do this properly, the Atria Location Broker service should start automatically for any user.
See also "Troubleshooting ALBD startup failures on Microsoft Windows".
Let's say I'm an administrator on a Windows7 box. I'd like to be able to run commands as other users without knowing their passwords.
This is what happens on linux. If I'm root, I can 'su' to other accounts without providing any password and run commands in their own name.
su (substitute user or switch user) allows changing the account associated with the current terminal. Where Normal user have to give password of the account he wants to change to, super user (root) can change to any ID he wants without giving password.
sudo executes a command as another user but observes a set of constraints about which users can execute which commands as which other users (generally in a configuration file named /etc/sudoers, best editable by the command visudo). Unlike su, sudo authenticates users against their own password rather than that of the target user (to allow the delegation of specific commands to specific users on specific hosts without sharing passwords among them and while mitigating the risk of any unattended terminals).
On windows runas.exe allows a user to run a programs with different permissions than the user's current logon provides. But for this you have to provide credentials. Windows security does not allow an administrator to execute as another user without his credentials. Administrators can do what they want but not under certains limits without control(discretionary power)
Now once it's said, on Windows an administrator can take and give ownership of ressources and then do what he wants, but it's logged.