Example: I am logged in as user TestUser. From this user I am going to run a command line as an administrator named AdminUser.
Is it possible from this command line to determine the name of the currently logged in TestUser?
I already have scheduled task which is always running as AdminUser, but in its action (batch file), I need to name of the currently logged in user.
Any ideas?
As far as I know this is not really possible.
Depending on how much you know about the environment of the users, the following might be a workaround however:
The command
qwinsta
will give you a list of sessions for the computer. Within these sessions one will be the active one, so if this program is used in an interactive session only this will basically contain the "logged in user" as you described it (it is far more complicated really, there could be many users logged on but only one can be active and I just hope you know enough about the usage scenario of your program to make use of that). You could parse the output and work with that username.
Of course this is a dirty hack and it assumes that during the run time of your task there is no chance that users change.
Also though I chose the qwinsta.exe because it is a very basic approach that needs no API calls or something I am still not sure if the CMD has sufficient parsing capabilities to get the necessary information for you.
%username% variable contains.. well, the user name.
echo/%username%
EDIT
As you said, because you are in a scheduled task, you can get the user name from Windows Registry
#echo off
for /f "tokens=3" %%a in ('reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData\1 /v LoggedOnUserName') do (
set "user=%%a")
set "user=%user:.\=%"
echo/%user%
Now %user% variable contains the logged user name.
Here is a quick way to make this happen using a batch file would be this command:
for /F "tokens=1,2" %%i in ('qwinsta /server:%COMPUTERNAME% ^| findstr "console"') do set tempVar=%%j
echo %tempVar% will show whatever user is actually logged in. Not the user who launched the batch file.
Related
I need to make customization to all new users and I chose modifying registry to achieve this. When I loaded default user NTUSER.DAT file and add, all current user changes. Though I see most customization keys are imported, I have problem with few keys.
Even though they are loaded in HKEY_USERS\NTUSER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer, i dont see the same in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer.
this applies to few other keys as well.
any suggestion/help is appreciated
HKEY_CURRENT_USER holds the user settings for the currently logged in user (and is usually abbreviated HKCU). This is actually just a link to HKEY_USERS\<SID-FOR-CURRENT-USER> where <SID-FOR-CURRENT-USER> you can find in Win32_UserAccount class, e.g. as wmic.exe useraccount get Name, SID.
This hive is automatically loaded from file %USERPROFILE%\ntuser.dat on signing in, and you can see it running dir /A %USERPROFILE%\ntuser.dat.
The HKCU has nothing to do with a hive loaded to the registry from file C:\Users\Default\NTUSER.DAT (and named as NTUSER in your case). If you make changes to this default user profiles registry, all new user profiles will be equally affected.
I recently learned that ~ refers to the HOME variable. So, if I set HOME=/foo and then try to use a bash script that would like to cd ~/Documents it ends up saying:
foo/Documents: No such file or directory
What's best practice in this situation? Crash and complain to the user that they overwrote HOME? Or is there some way to recover the default value of HOME?
I think you should just treat this like any other problem accessing files. If the file you're trying to access doesn't exist, or you're trying to create a file in the directory and you can't, you print an error message. If it's critical to the operation of the application, you exit after reporting the error.
As far as I'm aware, most applications that need to use the user's home directory just use the HOME environment variable, they don't try to second guess it.
There shouldn't be any security implication of this. The user still needs appropriate permission to access the files, so redirecting HOME won't allow them to write someone else's files that they shouldn't. If your application is set-uid, it should always revert back to the user's ID when opening files in the user's directory, not use the elevated privileges.
The source of truth for the user's home directory is /etc/passwd, which contains a line for every user on the system, listing the user's name, home directory, and some other information. If your question is "what is so-and-so's home directory?", then you should look it up in /etc/passwd.*
However, while /etc/passwd is correct, if the user has clobbered $HOME with some other path, they may want you to use that value instead of the "real" home directory. Unless there's a security problem with allowing the user to spoof the home directory, it may be preferable to blindly use the value given by the user.
Personally, I would check whether $HOME is a directory (e.g. with if [[ -d "$HOME" ]]), and if so, use it as is. If not, parse it out of /etc/passwd using grep and cut, perhaps with a warning printed to stderr to remind the user that their $HOME is bad. You can grep for the UID printed by id -u, which cannot be clobbered by a non-root user.
If you're really going to worry about $HOME being clobbered, however, you should also worry about $PATH, the $LC_* variables, and several other environment variables which can break various things. Ultimately, it's easier to just assume these variables are correct and use them as-is, unless there is a security concern. That would mean just blindly use $HOME and don't worry too much about it being wrong.
* On systems which are using LDAP or a similar networked system to manage accounts, the user's account might not be listed there. In some cases, there's an /etc/passwd.cache or something similar, which may contain the user, but this is not guaranteed to work on every system. Running strace(1) on whoami(1) can help indicate where this information is coming from.
Pardon my very broad question here guys. I don't ever really do much coding (at all) and was hoping you guys could help me out. Basically what I would like to do is have an end user run a script that asks them what Session ID they would like to disconnect. This will be used in conjunction with the "tsdiscon" command.
So the script would open > Ask for session ID > disconnect that session ID.
Seems pretty simple but like I said, I never do any of this. Thank you guys for any help!
It's not very robust, but try this:
sidkill.bat
#echo off
cls
set /p sid=Enter Session ID:
echo Disconnecting session %sid%
tsdiscon %sid%
i got an idea to make something like keychain with keys, which will contain possible passwords to extract my password protected archives. So passwords will stay hidden, but user will still able to extract archive without knowing password.
Problem is if i send password via parameter it is shown in command line parameters.
set mypass=12345
unrar.exe x test.rar -p%mypass%
i tried also send pass via echo but it doesnt seems to work
#echo off
#echo 12345 | unrar.exe x test.rar -p
How to solve this?
The unrar executable does not provide a mechanism to securely accept the archive password. It is accepted in plain text form. There's no getting away from that and you should stop trying to do so.
Use the rar DLL interface instead which gives a slightly increased level of obfuscation. Of course, a moderately determined hacker could inspect the parameters that are being passed. Or inspect the file that is being extracted.
Using of #echo off is the correct approach.
Do note that when you call
#echo something
that "something" is always shown even when you disabled the echo using #echo off.
Also I agree with Uli Gerhardt about the use of unrar.dll instead as this will give you even better control over the extracting process.
EDIT: If you put this code into batch file (*.bat) you will see that the commands won't be shown.
#echo off
set mypass=12345
notepad %mypass%
Same should apply when sending commands from your application.
EDIT2: Do you know that you can even find already made Delphi component which alows you to make use of unrar.dll?
Check at bottom of this page: http://www.rarlab.com/rar_add.htm
To enable my application to startup with admin rights at user login, I use a task in task scheduler. And it works fine. Mostly. Now I've received bug reports saying that this fails:
rootFolder->RegisterTaskDefinition( _bstr_t(name.toWideCharPointer()), task,
TASK_CREATE_OR_UPDATE, _variant_t(L"Builtin\\Administrators"), _variant_t(),
TASK_LOGON_GROUP, _variant_t(L""), ®isteredTask) -> 0x80070534
0x80070534 seems to mean "No mapping between account names and security IDs was done". I'm following (pretty much verbatim) the example at:
http://msdn.microsoft.com/en-us/library/aa381911(v=VS.85).aspx
Ideas what has gone wrong, and how to fix it ? The application has manifest set so the user needs to be admin to run it.
Question: The "Builtin\\Administrators" group, it is language dependent, isn't it ? I think that the user in question might have a non-english Windows 7. If so I imagine it would work better with specifying "S-1-5-32-544" instead ( http://support.microsoft.com/kb/243330 )
Update: So the explicit call looks like:
rootFolder->RegisterTaskDefinition(
_bstr_t(name.toWideCharPointer()),
task,
TASK_CREATE_OR_UPDATE,
_variant_t(L"S-1-5-32-544"), // Language independent "BUILTIN\Administrators"
_variant_t(),
TASK_LOGON_GROUP,
_variant_t(L""),
®isteredTask)
Make sure that the application is executed with elevated privileges, otherwise that call will fail.
The problem indeed lies in the parameter _variant_t(L"Builtin\\Administrators"), which is hard-coded to English version of Windows. By using the language agnostic security identifier "S-1-5-32-544" ( http://support.microsoft.com/kb/243330 ), the problem is resolved.
Update: So the explicit call looks like:
rootFolder->RegisterTaskDefinition(
_bstr_t(name.toWideCharPointer()),
task,
TASK_CREATE_OR_UPDATE,
_variant_t(L"S-1-5-32-544"), // Language independent "BUILTIN\Administrators"
_variant_t(),
TASK_LOGON_GROUP,
_variant_t(L""),
®isteredTask)
Make sure that the application is executed with elevated privileges, otherwise the call will fail.
After spending some time, I've seen that more modifications than just _variant_t(L"S-1-5-32-544") are needed to make this "Logon Trigger Example (C++)" example work.
All the details can be found in this answer.