In the cmd prompt, is there a command I can run to display the password of the currently logged in user?
My usage scenario is this. I have an arbitrary bat script that runs 3 programs sequentially:
REM do some work
foo.exe
REM do some more work
Half way through foo.exe, it prompts for the current user's password before continuing. This defeats the purpose of scripting, which is automation because after kicking off the script, I must check back half way to enter the password.
Solution 1:
Hard code the password into script and pipe it.
REM do some work
echo hard.coded.password | foo.exe
REM do some more work
This approach has 2 problems right away:
Putting pwd in a bat file is insecure.
Others can't run the script because each has a different pwd.
So ideally, I'd like to do:
REM do some work
command-that-prints-current-user-pwd-to-output | foo.exe
REM do some more work
This way, password is not hard coded in the script, therefore making it more safe and shareable.
Thanks
No you can't. Only the user knows the password. Windows doesn't.
Passwords are one way hashed and the hash is stored not the password. Being one way it can't be reversed. When you enter a password it is hashed and the hashes compared.
Related
I am working on an application that requires my users to share their fully-qualified-domain-name of their windows machine.
To help my users to extract their machine's FQDN, I want to share simple command line steps that they can copy/paste and execute on their terminals to get the result.
I was thinking of below command to extract local machine's FQDN:
echo %COMPUTERNAME%.%USERDNSDOMAIN%
But there are few problems of this command.
It gives output in ALL CAPS. (I can live with it)
It gives incorrect output if the variable is not set.
For example:
If USERDNSDOMAIN value is not set, then, you'll get following output:
echo %COMPUTERNAME%.%USERDNSDOMAIN% //<- Run this on cmd prompt
ClientComputerName.%USERDNSDOMAIN% //<- wrong output: Notice '%USERDNSDOMAIN%' is appended in o/p
Is there any way to stop echoing a variable if it's value is not set?
Please note that I want to extract "fully qualified domain name" of my windows machine through CMD prompt only.
You can get the FQDN name using PowerShell.
=== Get-FQDN.bat
#ECHO OFF
FOR /F %%A IN ('powershell -NoLogo -NoProfile -Command ^
"([System.Net.Dns]::GetHostByName($Env:COMPUTERNAME)).HostName"') DO (
SET "THEFQDN=%%A"
)
ECHO %THEFQDN%
If you have multiple users, then you surely have some way to get programs and batch files installed on them. Once this batch file script is installed into a directory on the user's PATH, it is a one-line command.
Get-FQDN
1st, please note that the "USER DNS Domain" is NOT the domain the computer is joined to, it is the domain the USER who is logged in belongs to.
If you log in as a user from a trusted domain, or a child or parent domain, then it will display that domain.
So, if you log in as a LOCAL account it will be blank (likely you are running into this)
There is a fairly simple way to get the actual computer domain however, by using NLTest. (For the like of me I could never figure out why Microsoft didn't pre-populate a variable with this info.)
At the CMD Line simply dump this into the command prompt (I believe you will need to run with admin privileges but I haven't tested):
FOR /F "tokens=3" %_ IN ('nltest /DOMAIN_TRUSTS /PRIMARY ^|FIND /I "0:"') DO #(ECHO.%COMPUTERNAME%.%_)
The result will be in all caps because that is how Microsoft displays this info.
Here is an example output:
MYLAPTOP.USERS.MYDOMAIN.LOCAL
But on-re-read you want something the users know how to do themselves, so ymmv if you could just send a reference email, or hand it to them each time they need it.
If you just wan this info and other info easily available you could use BGInfo or other options like that to set the desktop background.
Alternatively you could change the logon scripts to generate a simple text file with all the info each time the user logs on, and placed in a certain folder you tell them to look in.
I have a simple .bat script triggered on user login to create a uniform work environment (load items to public desktop) as well as a few other small tasks - all are successful.
At the end of this script, I would like to call an additional .bat script and also open a system root folder if criteria is met. This however never occurs. The script I am calling begins with user prompt, and I notice scripts running as group policy do not always open a cmd window etc.
REM --------------------------------------------------
REM -----Update Newest Box & Scales / Uber Script-----
REM --------------------------------------------------
:BOXSCALE
if exist C:\scalescripts\Scale_Box_v3_Script.bat goto UBER
echo -
echo -
echo Scale_Box script is not up to date, please follow directions
call \\ant\fc\Dept\Photo\SDF8\SDF8_JW\scripts\Scale_Box_Uploader_v3\Scale_Box_v3_Uploader_Installer.bat
:UBER
if exist D:\Uber_Share_v2\Uber_Share_v2.bat goto END
echo -
echo -
echo Uber Share script is not up to date, please run installer as ADMIN
%SystemRoot%\explorer.exe "\\ant\fc\Dept\Photo\SDF8\Studio\Tech\scripts\Uber_Share_v2"
Pause
:END
Exit
The first bit (:BOXSCALE) is intended to launch a secondary script that contains mostly robocopy commands. It does require user interaction at the first bit. The second simply opens a server path in windows explorer for user. I am afraid that the user interaction is the problem as the start up script isn't visible to user when launched via GP Logon.
If I run this script manually, I receive the prompt from the first script and the system root opens as intended, but not if it is run via group policy login. I have also tried inputting the last two commands into a separate script and calling that, which also fails. Any ideas to get these last few items to run?
I found the solution to the problem. As suggested, it was the fact that the .bat script I was calling contained a user prompt. As the GP Logon script runs in the back ground, the user is unable to acknowledge prompt leaving the script hanging.
I have a Windows batch script which executes a program psexec that requires a password. Rather than having the password visible in plain-text within the batch script, I simply have %1 in the batch script, and I'm passing the password as a CMD line parameter instead.
I have #echo off to prevent the password from being displayed back, and I have an exit at the end of my batch script to close the CMD window once executed (so you can't scroll up and read the password). I realize that this still isn't entirely secure, as the CMD line parameters are stored in memory, and the password could potentially be read.
What I would like to know is:
1) How long are CMD line parameters held in memory? Are they removed from memory after the "exit"?
2) What is required for a hacker to access the memory to view the password? Is this "easy" to do?
3) Is this any less safer than storing the password in an environment variable (see link below)?
http://social.technet.microsoft.com/wiki/contents/articles/19911.how-to-use-an-environment-variable-as-a-password-credential-to-run-a-batch-script.aspx
I am trying to develop a simple script that can run a second script as the machine's local administrator. As the first script I am currently trying:
set name=%computername%
runas /noprofile /user:%name%\Administrator "cmd.exe /c %cd%bg2.2.bat"
When I run the script it never seems to run the second script, which is located in the same directory. The second script is only for copying files.
del "C:\Windows\obh_logo.bmp"
copy "%cd%obh_logo.bmp C:\Windows\obh_logo.bmp"
When the first script runs I am prompted for the admin password as expected and once I enter it, a second command prompt seems to flicker on the screen then vanishes. It never appears to run the second script. What seems to be the reason for this not working?
%cd%will probably not point where you think it does, (just tested it, of course the variable gets replaced before the command gets called and does actually point to the first scripts dir, but the problem still persists in the second script)
the runaschanges the working directory for the cmd.exe instance you are starting, probably to C:\Windows\system32.
replace it with %~dp0, which yields the drive and path of the current batch file.
But! Your script will not run the second file elevated, just under the Administrator account, which is not the same. Manual confirmation is always necessary, see here for possible ways to request elevation from within your script.
I now assume the missing rights is the actual problem, add a pause statement in your second script to watch it, or call it with cmd /k so the console doesn't close.
I am trying to pass a password into a Windows executable (simulating user input). Whenever I try to do that I get "no console available for secure input". The executable is an ORACLE executable called cdxdbi.
I am trying to call it like this:
CDXDBI.exe < params
where params is a file containing the password. Without the paramters the executable brings up a cmd terminal prompting for the password (twice).
How can I inject parameters into the terminal? I do not have more information on the exe, unfortunately. Anyone had the same issue and can provide a solution?
Best regards,
Sebastian
Assuming the following
CDXDBI is a console based application
The password prompt is the first and second line reads of stdin
Something like this might work
(
echo Password
echo Password
)| CDXDBI.exe
Otherwise, you will have to use one an external tool like mentioned in the comments.