I have a script that I run to lockdown a windows 7 computer to run a VM Client when booted.
when it runs it creates the local user account that is going to be used for logging in
Checks for the DefaultPassword reg key and if is not there creates the key
It sets the registry values for
AutoAdminLogon value to 1
DefaultdomainName value to the local machine name
DefaultPassword value to the local user account password
DefaultUsername value to the local user that was setup in the script
ForceAutoLogon value to 1
LogonType value to 0
After this is done the computer reboots and should login as the local user automatically
but it doesn't. I've check the keys and prior to the reboot everything is correct. But after reboot its back to what it was before the script was run.
The weird thing is .. if I run the script again .. everything works.
Has anyone got any ideas why this is happening???
As I said if I run the same script again AFTER the reboot it set the registry entries with no problems and they stay after the 2nd reboot. So I'm thinking there something going on after the first reboot .. my first thoughts where Domain Group Policies but if that was the case then I would get the same results on the 2nd run of the script and reboot. I have another script that I run after this one that sets the local user startup to launch the VMClient and disables taskmanager , lockworkstation, and change password functions when they use ctlr-alt-del keys, which is done in the registry .. this work just fine.
My instinct says that it's a feature of ForceAutoLogon, rather than a problem with PowerShell's Set-ItemProperty.
ForceAutoLogon Article
Extract:
"In addition to logging on an account automatically, the ForceAutoLogon setting also logs you back on after you log off.
Setting the ForceAutoLogon setting effectively locks out all users aside from the one you are forcing."
After search and search for a resolution to my problem I finally found the issue.
One of the Forums I check mentions the AUTOLOGONCOUNT reg key .. when I looked at my computer it was not there.. after I had rebooted the computer .... This is a Corporate Computer and we use MDT to reimage the computers ... so it does autologon a couple of times. Which when it is done the count is set to zero and the autologon is set to zero .. but the AUTOLOGONCOUNT reg key is still there. so when I ran my script it would set it and at reboot .. unset it .. DUH me LOL .. any I re-image a computer and delete this key and ran my powershell script and all is good
thanks for those that gave me ideas
Related
Yet another works-fine-locally-but-looses-its-mind-in-a-remote-session problem.
I have a PS script that runs standard Windows command line ftp.exe to get a file. Works a treat when ran directly, however when ran remotely via Invoke-Command it suddenly leaves the files with the encrypted bit set.
If I then, in the same PS session (in the same script), run cipher /d on the file, I get Access Denied. However if I log onto the remote machine using the same account, I can decrypt it.
So, question the first, is this a "feature" of ftp.exe? I can't find anything suggesting as such, but no other method of creating a file seems to result in it being encrypted, so I'm left thinking it is an intentional act by the application, like it checks the logon type and encrypts if it a network logon.
Second, why can I not immediately decrypt it? Same account, same session.
The essential bits of the script in question:
#the ftp script is just open, user, binary, get, quit
& ftp -n -v -s:"$script"
& cipher /d "$file_path"
I realize this is probably a pretty obscure edge case, but I'll leave an answer just in case anyone runs into anything similar.
As usual, ProcMon has all the answers...
At my company %HOMESHARE% is set to a network file server (by some GPO I believe).
As ftp.exe is retrieving a file, it writes to a temp file and then once finished, copies it over to the specified location. Even after knowing this, one might expect %TEMP% to be used for such a purpose, but no.
I'm not quite sure exactly how ftp.exe goes about determining the temp file location, but when I'm in a PSsession, it chooses my Documents folder (%USERPROFILE% I suppose), but when I'm in an RDP session it uses %HOMEPATH%. So of course my Documents folder is set to encrypt new files and so the temp file is encrypted and gets copied over, but the file share is not so it copies over clean.
Also, while I have found nothing official stating this, it does seem that cipher.exe is completely ineffective for a network logon. If after entering a PSSession I create a new file with Set-Content and attempt to encrypt using cipher /e <file> it gives the same access denied. Same account over RDP encrypts no problem;
I have a .bat file that starts up a powershell script.
Within this powershell script, i startup PowerBI with a given database.
The powershell script waits till powerBI has been done starting up, and will then be exporting data to some datadump files.
Doing this manually works fine, and also when its on the task scheduler to run when user is logged on.
The moment i change this to "Run whether user is logged on or not" it doesnt work anymore.
The reason behind this, is that it seems that powershell is unable to start PowerBI and therefore there is no open data to query in the rest of the script.
So the positive side is it runs the bat and powershell just fine, only the powershell itself seems incapable to start powerBI.
Are there any solutions to this? should i for example use a different method to call the appliation to start?
currently the powershell snippit to start the app looks like this:
$PBIDesktop = "C:\Program Files\Microsoft Power BI Desktop\bin\PBIDesktop.exe"
$template = "C:\LiveData\Data.pbix"
$waitoPBD = 60
$app = START-PROCESS $PBIDesktop $template -PassThru
log_message "Waiting $($waitoPBD) seconds for PBI to launch"
Start-Sleep -s $waitoPBD
I faced similar issue. So, sharing my experience..
First of all, please verify couple of things.
Specify user account which will be used to invoke the job. Also, ensure that, the account have sufficient permission.
Don't forget to un-check the checkbox (as shown in screenshot) under Conditions Tab
Just found this one - sorry it took so long :D
But, i had this totally nervwrecking issue to.
Solution for me is to realize that the task scheduler is very deep part of the OS.
Thats why i have to grant access to the file, for the computername$ (system name) on the file or folder containing the file to run.
Rightclick on the file or folder -> Security. Select edit and add [Name of your computer]$ and give the read and execute permissions.
That's the only way I can make it run.
But i hope you found the solution in the meantime :)
Background:
I have several registry keys that are saved and used to update/configure remote PCs in my environment. I may not have deployed the device, previously, but I use these registry keys to update the PC as I fix/repair/etc...I am part of a team of 45 managing about 25,000 workstations and peripherals in our region of the enterprise.
if I use this command from my Win 10 PC to a Win 7 PC, it executes without problems.
psexec \remotecomputer -u domain\adminaccount regedit.exe /i /s "\server\share\directory1\directory2\directory3\someregistry.reg"
psexec starts regedit, imports the above registry file and closes.
If I run that exact same command from my Win 10 PC to another Win 10 PC, I get the following error, from CMD as ADMIN,
"PsExec could not start regedit.exe on REMOTEPC_HOSTNAME:
The system cannot find the file specified."
it can't find regedit??? WTF??
I'm curious why Win 10 is blocking me, as an admin, from importing a registry key?
I've tried reg import as a solution, but I keep getting syntax errors and it can't find the file/pathway.
It's almost like the remote PC, doesn't recognize admin input due to UAC settings?
In testing, I've set the group policy editor to enable remote registry tools, no change. I've enabled remote registry services and set to start the service automatically. I can access the PC registry via remote registry...but psexec just won't work on the remote device.
I can RDP to the device and run the command line equivalent:
regedit.exe /i /s "\UNC\pathway...\etc*.*reg" it executes, without issues.
this proves that regedit is working
Can anyone provide some expertise on this?
add -s flag to psexec to run regedit
The old PsExec trick of running RegEdit doesn't always work. This is because psexec depend on a hidden SMB Administrator service. (Which in any security sense should be disabled.)
PsExec allows redirects of the input and output of a remotely started
executable through the use of SMB and the hidden $ADMIN share on the
remote system. With this share, PsExec uses the Windows Service
control Manager API to start the PsExecsvc service on the remote
system which creates a named pipe that PsExec communicates with. This
named pipe is what allows for input/output redirection back to the
system that launched PsExec.
So instead, in order to remove any TrustedInstaller owned registry Keys, you can use a different tool. This worked:
ExecTI - Run as TrustedInstaller
Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe
I have a task to set up a Windows 2008 server in AWS, fully scripted.
I need to add a user but so far have tried dsadd with no apparent results. I tried various permutations of the command and finally copied and pasted the example:
dsadd user “cn=John Smith,ou=SouthEmployees,dc=northwindtraders,dc=com” -disabled no –pwd C^h3Bdo9# -mustchpwd yes
But nothing extra shows up in the server manager list of local users, and the command just returns with no indication of error or success.
Any idea on what I'm doing wrong, or another way to do this?
This had to be done with PowerShell:
# Add required ID
$server=[ADSI]"WinNT://$env:computername"
$user=$server.Create('User','my_username')
$user.SetPassword('longpassword')
$user.SetInfo()
I am running a large study where we have staff in various countries collecting information on tablet computers running Windows 10 Enterprise. Each staff member is assigned to a tablet and they log into the tablet with their standard username and password. These users do not have local admin rights on the machines, but all tablets have a single Administrator Username and Password which I know and these are uniform across the tablets.
Each night, users invoke a program on their tablets that uploads data to our servers and then we pass information back to the tablet during this synchronization process. Otherwise, they are disconnected from the internet. At the end of the synchronization process a program is executed that allows me to run any script I like, but the script executes under the standard user account (i.e. without elevated privileges).
I need to update all the tablets with a bug fix for software that they use on the tablets and I'd like to do this during the synchronization process. The bug fix is contained in a simple executable file that can be easily pushed to the staff memebers' tablets along with any code I like during the sync. If users were running the synchronization program as administrators, this wouldn't a problem as I could simply run the executable via a script at the end of the synchronization. But they aren't, so I'm trying to find a way that I could run a script (I don't really care what it is. It could be a windows batch file, a vbs script, VB.NET, powershell, etc.) and have that script execute with administrative privileges and run the installation without the UAC prompt interfering.
I don't even mind supplying the admin password in plaintext to be honest, since these users are all our employees and they can't really do anything really concerning to us with it (and I could always deploy a subsequent file through the synchronization process to delete the program that has the password in it). I realize this sounds somewhat complicated, but in a nutshell, I'd like to carry out these steps:
Send the bug update executable to the tablet computer (I can do this now)
Develop custom code, that will pass admin credentials to the tablet and install the executable in 1 without having the UAC appear (I can send the script to the tablet during sync but do not know how to execute it as the Admin without getting the UAC prompt).
Any ideas how I can do this? I've explored this all day with minimal success using PowerShell scripts like the ones described here and here. This was the closest I got after storing the credentials in $cred, but it continued to give me the UAC prompt:
Start-Process PowerShell.exe -Cred $cred -ArgumentList '-command &{Start-Process -FilePath C:\MySyncPath\BugFix32.exe -Verb runas}]
UPDATE
After some additional work, I think I'd be able to get this to run if I could somehow disable to UAC control with a script that can run under the regular user's account and pass the admin credentials to it. Any idea how I might be able to accomplish this? If I could get this to work, even with a reboot, I'd be able to accomplish what I need.
The actual issue you're having is that you want to update your application, but the application is in the Program Files folder (or some other location that standard users are not allowed to modify).
In order to allow any user the ability to update your program, you must grant all users Full Control to your folder. Ideally your application's installer would have done this adjustment to the DACL during installation (when the installer was running as an administrator).
For now you will have to settle for a final one-time requirement that the users elevate to administrator. Then you can disable all security on your application - allowing any user (malicious or not) to modify your application at will.
GrantEveryoneFullControlToFileOrFolder("C:\Program Files\Contoso");
with a pseudocode implementation of:
void GrantAllUsersFullControlToFileOrFolder(String path)
{
PACL oldDACL;
PACL newDACL;
PSECURITY_DESCRIPTOR sd;
//Get the current DALC (Discretionary Access Control List) and Security Descriptor
GetNamedSecurityInfo(path, SE_FILE_OBJECT, DACL_SECURITY_INFORMATION,
nil, nil, ref oldDACL, nil, ref sd);
//Create an SID for the "Users" group
PSID usersSid = StringToSid("S-1-5-32-545");
// Initialize an EXPLICIT_ACCESS structure for the new Access Control Entry (ACE)
EXPLICIT_ACCESS ea;
ZeroMemory(#ea, SizeOf(EXPLICIT_ACCESS));
ea.grfAccessPermissions = GENERIC_ALL;
ea.grfAccessMode = GENERIC_READ | GENERIC_WRITE | GENERIC_EXECUTE;
ea.grfInheritance = SUB_CONTAINERS_AND_OBJECTS_INHERIT;
ea.Trustee.TrusteeForm = TRUSTEE_IS_SID;
ea.Trustee.TrusteeType = TRUSTEE_IS_GROUP;
ea.Trustee.ptstrName = PChar(usersSID);
// Create a new ACL that merges the new ACE into the existing ACL.
// SetEntriesInAcl takes care of adding the ACE in the correct order in the list
SetEntriesInAcl(1, #ea, oldDACL, ref newDACL); //use LocalFree to free returned newDACL
//Attach the new ACL as the object's new DACL
SetNamedSecurityInfo(path, SE_FILE_OBJECT, DACL_SECURITY_INFORMATION,
nil, nil, newDACL, nil);
LocalFree(HLOCAL(sd));
LocalFree(HLOCAL(newDACL));
FreeSid(usersSID);
}
It's not completely unheard of for applications to be modifiable by any user: Most MMOs install updates while you play. MMOs usually have a shim applied by Microsoft that gives all users control of the application folder.
run the script as a domain admin account... and set execution policy before the script is run, then run as administrator... some applications are picky about UAC still, but Set-ExecutionPolicy [bypass/remotesigned] will ensure that you're not prompted. however, sharing and permissions may still be an issue if the domain admin account doesn't have access to the share. psexec does this, but it's literally a matter of doing what i just mentioned and the psexec file essentially writes out the permissions by the end of the script. the intent was to make sure that passwords weren't written in clear text, it hashes the password value. either way, if you want this done securely, using a GPO and making sure your file permissions/share is at the highest level might iterate out the prompt. that's why you'll see some batch files use %1 %2 %3 %4 %5 %6 %7 %8 %9 .... that's because it's automatically requesting elevation and will loop in an iterative cycle until the UAC prompt isn't necessary.
i know i'm bumping an old thread, but this is what i've found, trying to mix and match legacy cmd batches with powershell ... lots to consider about the execution policy leading into the call vs during the call...
This question is in the category of "when people ask for security holes as features".
You cannot bypass (or, if you prefer this phrasing, "programmatically accept") the UAC prompt and automatically elevate without interactive confirmation. UAC is designed specifically to prevent this. (If this were possible, all malware would do it.)
This isn't a PowerShell thing but a general windows 10 thing. You'd need to disable UAC for this. No experience with it on Windows 10 yet though.
You can try setting the EnableLUA registry key to 0. The key can be found in:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
This will probably need a reboot to be active though.