Am able to auto-start my program by copying its shortcut into the start-up folder. However i want the program to auto-start on completing boot, even before any user is logged in. How is this possible?
I found this for windows 7 & maybe it'll work with Windows 8 too.
If you want it to start before the user logs on, you will have to start it as a service.
Here is the startup sequence of the major registry keys, starting immediately after bootmgr has been read and ending with the program shortcut entries in the two Startup folders.
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute. This can include instructions to schedule the running of chkdsk but not user programs.
Services start next, followed by the RunServicesOnce and RunServices registry keys (if present)
User then logs on to the system
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\UserInit. This points to the program C:\WINDOWS\system32\userinit.exe and the entry ends with a comma. Other programs can be started from this key by appending them and separating them with a comma.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell. This should contain just one entry, explorer.exe.
Program entries in these 2 registry keys for ALL USERS start next:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and \RunOnce
Program entries in these 2 registry keys for CURRENT USER start next:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run and \RunOnce
Programs in the Startup Folders of All Users and Current User are started last of all.
Important programs like antivirus and firewall start early in the sequence as Services. The icons that appear in the Notification Area (bottom right of the screen) are just their user interfaces, i.e. options and preferences.
The additional location for 32-bit software in a 64-bit computer is HKLM\SOFTWARE\Wow6432Node and HKCU.
Source
Related
I turned off (set 0 value in "Enabled") AES 128\128 cipher, and SHA, SHA256, SHA384, MD5 hashes in windows server 2012 R2 registry (hosted on aws).
Then I used command "Restart-Computer" and cannot to login via RDP to my server. How can I restore RDP connection ? and connection at all ?
Thanks in advance.
There is the answer from aws support:
There are 3 methods using which you can revert the registry changes. Request you to follow the Methods in a sequential manner if the current Method fails.
Method 1 - Connecting to the registry of the problematic instance from another instance in the same VPC and revert the changes. (You can launch a test instance temporarily in the same VPC if you don't have any existing instance (s) in the same VPC.)
1. Open Registry Editor from the working instance which is in the same VPC as problematic instance.
2. Click on File->Connect Network Registry.
3. Enter the FQDN of the server and Click on Ok.
4. Enter the credentials and Click Ok.
5. Now Expand the Remote computer (Problematic instance) hive and revert the changes.
Method 2 - Access the problematic instance using TightVNC.
1. Ensure that the non-working instance has IAM role assigned to it with Policy named "AmazonEC2RoleforSSM" attached to the IAM role. To create and Attach an IAM role See Link https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html & https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role
2. Now Install TightVNC on a working instance which is in the same VPC and subnet. Link to download TightVNC MSI: https://tightvnc.com/download.php 3. Right click on the MSI > Properties > Under the General Tab > Ensure the file has been Unblocked by Ticking the Unblocked check box.
4. Now copy the msi file on the problematic instance as well. Copy the MSI to C$ on the problematic instance (\\c$). For simplicity sake rename the MSI to TightVNC64.msi 5. Now go to https://console.aws.amazon.com/systems-manager
6. On a Left Pane, Under Actions, Click on Run Command.
7. Click on Run Command and Search for Command Document named "AWS-RunPowerShellScript".
8. Select AWS-RunPowerShellScript and under Command Parameters paste the below command:
Start-Process -FilePath "C:\TightVNC64.msi" -ArgumentList ("/q SET_PASSWORD=1 VALUE_OF_PASSWORD=YouSecurePasswordGoesHere SERVER_ADD_FIREWALL_EXCEPTION=1") -Wait -PassThru
9. Scroll down and Under Targets, Select the Problematic Instance.
10. On the bottom of the page Click Run.
11. Wait for command status to get successful.
12. Launch the TightVNC Viewer on your working instance and provide the IP/FQDN of the problematic instance followed by the credentials that you have provided under command in Step 8.
13. You will be connected to the Instance and can make changes in the registry.
Method 3 (Method will require Stop and Starting of the instance.)
1. For Detaching the Root Volume from the problematic instance and Attach it to the working instance request you to please watch video from 1:47 to 3:40 in following article:
https://aws.amazon.com/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/
2. Open Disk Management Console (diskmgmt.msc) and Right Click on the Disk showing Offline status and Click Online.
3. Once the Disk is Online, Go to My computer and make a note of the Drive letter of the disk which you have attached.
4. Open Registry Editor and Select HKLM.
5. Click on File and Load Hive. Provide any name for eg. "Recovery".
6. Expand the "Recovery" key and revert the changes i.e. Enable the value for AES 128\128 cipher, and SHA, SHA256, SHA384, MD5 hashes.
7. Once all the changes are made, Select the "Recovery" Key and Click on File and Unload Hive.
8. Open the Disk Management console and take the disk offline.
9. Now for re-attaching the root volume to your problematic instance, request you to please watch video from 08:02 to 9:28 using the same link: https://aws.amazon.com/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/
Additionally, first of all you should ensure that yuor IP-address in range of inbounds-rules of the failured instance.
in my case I, first of all tried to use amazon app "app2rescue" for diagnostic failured instance, bit it didn't show any helpful (did show only few possible issues with firewall, but it's not related to my issue).
Then I tried the first method - but I could not get access to remote registry (I assume that on the target machine was disabled "Remote registry" service).
And finally, I used the third method and it fixed my problem. During this operations I faced only one issue - before failure I was changing the currentControlSet, and when I attached volume to temp server, I was trying to find exactly it, but found out that currentControlSet is enabled only when this registry is used for current OS (when this registry works), so I found my problem-parameters (sha, md5 etc) in the controlSet001 instead of currentControlSet.
I have windows service program that starts an exe process, and have another user interface
that can start same exe like service.
problem is when I start exe from UI, exe can access network share files and in task manager
can be viewed without checking the check box: show processes from all users.
but when start process from serivce, I can't see it in task manager list, and have to check
the checkbox I mentioned.
in both situation username tab in task manager is the same, but in start from service not listed
without checking the checkbox.
I checked all 4 types in ProejctInstaller class from serivce project:
this.serviceProcessInstaller1.Account = System.ServiceProcess.ServiceAccount.LocalService;
any idea?
Good day.
I am developing a program that will be used in a corporate environment by the end users. The application will automatically fix certain errors as soon as the user selects the application name, chooses the symptom or error message and clicking on the fix button.
The idea behind is to decrease the amount of calls we receive at the IT Service Desk (The company's personal Call Centre for IT Issues) and at the same time assist the end user by resolving the issue within a minute (versus waiting on the phone for up to 15 minutes or more).
I've am not yet allowed to upload an image of the application, but imagine a small'ish windows form with 2 columns; Aplication name and Synptom. The user will choose the application's name, click on the error message and click on the FIX button. This basically automates whatever we has IT Techs would manually.
The problem I'm facing is that some of the code is supposed to be executed with adminsitartor rights, eg. Stop and Start a given service, adding regsitry entries for Local Machine, etc.
Given the fact that none of the users will be allowed to have elevated rights and the fact that they need to use this application as a sort of "self-help" alternative without the need to call the IT Service Desk, is there a way to give a set of code "administrator permissions"? The application should NOT request the user to enter ANY passwords.
Regards,
Willem
No way, AFAIK: the model in common operating systems is process-centric, so that the process is given permissions that are then inherited by its code. You can elevate such privileges at some point, but that will be for the whole future life of the process (or as long as the authentication token for it ceases to be valid).
In windows the right way to do that is to employ a back-end service: at boot, you start the service called IT_Auto_Fixer_Back_End with high permissions (try to avoid Administrator, NetworkService or LocalService could be enough for you). When the app IT_Auto_Fixer_Front_End is started with USER privileges, it operates until it needs something with high privileges. At that point it sends a request to the service, that will do it.
If you choose this way, some important advices:
The IT_Auto_Fixer_Back_End must not become a backdoor! If you use TCP as form of communication with IT_Auto_Fixer_Front_End, make it listen localhost only and use SSL (yes!) to encrypt local traffic
It must not be possible to invoke arbitrary commands using IT_Auto_Fixer_Back_End. You need to enumerate the possible requests that could be made (i.e. a command like stop_mysql_service rather than accepting directly the string net stop mysql - the application logic will translate your string into the real OS command)
Every input from the user could be used to perform command injection. To prevent this, use the Windows API that requires an array for the command - this way if the user adds options to a command (i.e. the name of the service in net stop) they won't be interpreted as another command (common scenario: when accepting the name of the service as a parameter, a malicious user that tries to execute something like net start mysql ; net user /add hacker t00E4sy). Authentication and encryption will not help you against this, you must escape any user input that goes inside the command.
Sanitize your ENVIRONMENT by using the API that executes commands setting the PATH (and other relevant variables), so that the user will not be able to taint the PATH, executing C:\temp\net.exe instead of C:\Windows\System32\Net.exe
IT_Auto_Fixer_Back_End service should be authenticated: it should check every time if the request comes form the user by checking if the Kerberos token is valid (Windows => you get a very nice Kerberos environment for free!). This will prevent someone else to break into the machine, use SSL to connect to the localhost port and elevate privileges through your service
The above (authentication) still stands when something else (i.e. shared memory, windows sockets, a file, etc...) is used as communication channel between IT_Auto_Fixer_Back_End and IT_Auto_Fixer_Front_End
Life gets harder when you want to properly implement something dealing with multiple level of permissions...
I have an Okuma OSP Machine Controller running Windows XP.
By default it attempts to automatically log on when the machine is turned on.
We have changed the default administrator password and now the auto-log on fails every time.
How can I turn off this feature or update the password so that it succeeds?
Machine Types Effected: Any machine with P200 or P300 control running Windows-XP
4/1/2014: Confirmed the same applies to new OSP-300 Windows 7 controls
2/1/2015: There is another (easier) way to accomplish this on Okuma controls.
This can be done using a utility in the TOOLS directory called the "Auto Logon Setting Tool". This is perfect for anyone uncomfortable with editing the registry.
Tool location:
The utility:
Just choose the user you wish to to be logged on automatically, and click the "Register auto log-on" button.
This feature is enabled from the factory to allow users to get up and running quickly while still having the machine password protected. Because it is recommended to change the default password this is most likely a very common situation.
The automatic login behavior can be changed by editing registry settings.
Click Start, type "regedit" (sans-quotes) in the run box, and press enter.
In the folder structure in the left pane, navigate to the following folder:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
To turn the feature OFF, change the key value of "AutoAdminLogon" to '0'
Similarly, the default user name and password can be changed by editing the appropriate keys to restore the functionality of the auto login feature.
Reference Microsoft Support article here.
Using Windows 2003, I'm look for a way to create a "logoff script" that will continue with the current logoff then immediately login another user. So, "UserA" logs off. Script fires to login "UserB".
This is part of an application upgrade for a computer where we have written the 'shell'; similar to a kiosk application. For the upgrade we need to logon as 'Adminstrator' then, when the upgrade has completed, logoff 'Administrator' and logon as 'sample_user'. We would like to accomplish this WITHOUT rebooting.
Note, I do not want a script that will initiate the logoff (i.e. "shutdown"). I'm looking for a script that will run upon the user logging off (set via Group Policies). As above, the script should log a different user on.
Thanks.
Don't think it's possible in the stated way (script at logoff).
You'd have to set the machine to logon automatically as a specified account and then log off (having it log on automatically for you) and then you'd have to disable that feature again afterwards, by placing a temporary logon script... generally sounds messy.
The actual setting can be made using tools like Microsofts Shared Computer Toolkit or similar (not so sure how the "normal" registry auto-login behaves at manual logout but I've had an XP kiosk that would automatically log on instantly, even if you logged out manually - you had to override it using some key like shift+logoff to be able to manually specify the login again, so somehow it can be made).
The "easiest" way might be to replace msgina.dll with someone of your own making...
But why are you doing this? Just use runas and start whatever you need to do as that other user without logging off the console user - it's a multi-user system afterall? The desktop is just fluff ^^
(This will anyhow require that the user credentials are available to your script, which kind of makes it redundant as you compromise the security of that account - defying the purpose of having that second account in the first place, for whatever purpose it exists?)
I would try setting the registry to autologon with the user you want, and then simply logging off the admin user. That should log your kiosk-user right back on.
Not sure how to login another user once the current user logs off (not sure if windows would let you...)
But you can use shutdown to logoff:
shutdown /?
Here's some ideas that probaly fall into the "cheap hack" category:
How about logging in at UserB in the first place, and then using runas /user:userA <cmd> to run the first part of the install process?
If that's unacceptable, I know there's a way to make Windows workstations (those that aren't part of a Domain) automatically log in into a certain user account after a restart. Perhaps if you looked into which Registry changes happen, and duplicated them, a reboot would automatically log in that user. (Of course, as a final stage, after userB logs in, you would have to revert those changes :-)
It also occurs to me to wonder if perhaps there's a way for a service to force an open "login screen" to log in as a certain user. Maybe using some method like the way the Remote Desktop does it remotely... If that's possible, then you could create a service that you install before logoff of userA, that would trigger the login of userB.
You can script it with VNC (there are many free versions, take your pick). Set up a VNC server process on the machine to listen on localhost. When the user logs off, your logoff script will connect to the machine using VNC and send the keystrokes necessary to log on the next user. VNC uses the RFB (remote framebuffer) protocol; there are libraries for most popular languages, so you should be able to get something working quickly. Or there are related tools that might help.
If you were to run something like this as a normal script in a given language, it would most likely not work as when you log out of your account, all processes should be killed along with your running script.
You might be able to create some sort of 'service' that would run on a service account (i.e. always active) that would automatically do this user switching for you.
My bets are on Windows Powershell, although I'm not entirely sure what functionality it has as far as actually creating a service.
A quick search brings up the following (The second link is to a forum but it mentions running Powershell as a service and sending that service a parameter which would be the path to your user switching script)
How to Create a Windows Service using Powershel
Powershell Script as a Windows Service
I don't have a Windows 2003 server or a system with a "Group Policies" setup to test my hunch but you could take a look at SU ("switch user") for Windows. Originally part of the Resource Toolkit this has been extended to a new SUperior SU. Do post the results/script if this works.
You could approach this from the perspective of building a remote control utility (like VNC, etc). The big thing here is that if you want access to the Logon screen (i.e. the CTRL + ALT + DEL / username/password) part, the only kicker is that a Windows Service is the only component that can access this, so you'd have to create one.
The only problem I see with this technique as a whole is that even if you spent a great deal of effort getting it to work (and it would be a pretty big effort), the chances of this working successfully with the whole thing originating from a logoff script (i.e. when stuff is shutting down) are low even due to the number of things that can go wrong when logging back on as Administrator.
Just remember that for anything you need to run as an Administrator, there are easier ways in Windows to make that happen (such as Run As, changing the user permissions on the items that need to update, etc).