I'm curious to know the order of Windows startup during a user login. Does anyone know?
Basically, my application was being invoked by login script that a GPO calls. While 3rd party EXE was being invoked, it was failing to start.
Then, through trial and error, I found that HKCU...\RunOnce keys execute after the login script. Same result, the EXE was being called, but failing to start.
What worked: updated the login script create a shortcut in the user's Startup folder. Now the EXE starts up as expected.
I know that AutoRuns can tell me all the locations where startup items can be placed, does anyone know the execution order as a whole? I was able to find that Run and RunOnce keys get called asynchronously. I can keep testing each startup item that AutoRuns states, but this could take days.
I'm mostly interested in Windows 2003 Server login startup flow, but I would suspect its very similar to other Windows flavors in use today.
Source: Understanding the Startup Process - Windows 7 Tutorial
The normal startup sequence for Windows 7 is:
Power-on self test (POST) phase
Initial startup phase
Windows Boot Manager phase
Windows Boot Loader phase
Kernel loading phase
Logon phase
Kernel Loading Phase The Windows Boot Loader is responsible for loading the Windows kernel (Ntoskrnl.exe) and the HAL into memory.
Together, the kernel and the HAL initialize a group of software
features that are called the Windows executive. The Windows executive
processes the configuration information stored in the registry in
HKLM\SYSTEM\CurrentControlSet and starts services and drivers. The
following sections provide more detail about the kernel loading phase.
Logon Phase
The Windows subsystem starts Winlogon.exe, a system service that
enables you to log on and log off. Winlogon.exe then does the
following:
Starts the Services subsystem (Services.exe), also known as the SCM. The SCM initializes services that the registry entry Start
designates as Autoload in the registry subkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Servicename.
Starts the Local Security Authority (LSA) process (Lsass.exe).
Parses the Ctrl+Alt+Delete key combination at the Begin Logon prompt (if the computer is part of an
AD DS domain).
The logon user interface (LogonUI) feature and the credential provider
(which can be the standard credential provider or a third-party
credential provider) collect the user name and password (or other
credentials) and pass this information securely to the LSA for
authentication. If the user supplied valid credentials, access is
granted by using either the default Kerberos V 5 authentication
protocol or Windows NT LAN Manager (NTLM).
Winlogon initializes security and authentication features while PnP
initializes auto-load services and drivers. After the user logs on,
the control set referenced by the registry entry LastKnownGood
(located in HKLM\SYSTEM\Select) is updated with the contents in the
CurrentControlSet subkey. By default, Winlogon then starts
Userinit.exe and the Windows Explorer shell. Userinit may then start
other processes, including:
Group Policy settings take effect Group Policy settings that apply to the user and computer take effect.
Startup programs run When not overridden by Group Policy settings, Windows starts logon scripts, startup programs, and services
referenced in the following registry subkeys and file system folders:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
SystemDrive\Documents and Settings\All Users\Start Menu\Programs\Startup
SystemDrive\Documents and Settings\username\Start Menu\Programs\Startup
Several applications might be configured to start by default after you
install Windows, including Windows Defender. Computer manufacturers or
IT departments might configure other startup applications.
Windows startup is not complete until a user successfully logs on to
the computer. If startup fails during the logon phase, you have a
problem with a service or application configured to start
automatically.
If you want further information check the source link.
Related
I need to call WNetGetConnection to get the UNC path and it works good when application run as standard user but it returns 1201(ERROR_CONNECTION_UNAVAIL) error code when application run as admin. According to the documentation its working as expected.
If the network connection was made using the Microsoft LAN Manager
network, and the calling application is running in a different logon
session than the application that made the connection, a call to the
WNetGetConnection function for the associated local device will fail.
The function fails with ERROR_NOT_CONNECTED or
ERROR_CONNECTION_UNAVAIL. This is because a connection made using
Microsoft LAN Manager is visible only to applications running in the
same logon session as the application that made the connection. (To
prevent the call to WNetGetConnection from failing it is not
sufficient for the application to be running in the user account that
created the connection.)
that means its not possible at all to get the UNC path from the app running as admin ? Is there some other way ?
This is by design. Network shares created by a non-elevated account are not visible under elevation, and vice versa.
See this question on Super User for discussion of the issue. There is apparently a registry setting that enables mapped drives to be shared between elevated and non-elevated accounts but I've never tried it myself.
Network connections cannot normally be shared across different Windows login sessions. This is regardless of admin account / elevation level. Each Windows login or impersonation session needs to create its own network connections.
Here's what I want to do:
a program that listens in the network for a message, and when that message is received, if the user is not logged in (for example the computer just powered on and windows displays the classic login screen), it automatically logs in a certain user accordingly to the message. the username and password are known and stored safely inside the computer in a configuration for the program i'm talking about.
What I had in mind was a windows service that starts with the computer and also listens to those messages, and if one is received, then it does it's job
but I have no idea of where to start
(basically i'm trying to login a user without having to type the password, which I said is stored and known - need something mostly like the fingerprint software windows 7 comes with, and the ones that you had to install in vista/xp so that fingerprint login would work (fingerprint was only an example) )
There's two methods to pursue depending upon which operating system you're looking to run under.
For Windows XP, Windows 2000, and Windows Server 2003 you need to create a GINA.DLL. This is a replacement DLL which must follow specific rules which handles the authentication process. In your case your replacement DLL would be known by the service which was listening for your start signal, and it would make a call into the DLL with the username and password as appropriate.
MSDN Magazine article on customizing GINA.DLL
MSDN entry on GINA
For Windows Vista/7 and above you'll need to look into the Credential Provider API.
MSDN Magazine article on Credential Provider API in Vista.
MSDN entry on Credential Provider API
You can use windows auto logon feature to do this.
Create a service which waits for the required data on a network socket. Make sure this service is started after the network service (Tcpip). Modify winlogon service properties (manually) so that it depends on your service. By depends, I mean that winlogon service is started after your service.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon to 1
Once you receive the data on your network socket, set the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword
Once the registry settings are in place, then the winlogon service can read those values and proceed with the login process.
For more details on setting the registry values refer: http://support.microsoft.com/kb/315231
I want clarify a little the suggestion of Vikram.exe.
Of cause the usage of AutoAdminLogon seems native for the problem, but saving of the password in registry as a clear text under HKLM\...\Winlogon\DefaultPassword is not good. Since Windows 2000 it is supported the usage of the secrets DefaultPassword which makes the same effect as the DefaultPassword registry value (see Protecting the Automatic Logon Password for the code example).
Another way to force user login or to do any other actions on the login screen is switching to the Winlogon desktop (full name WinSta0\Winlogon). You can use SwitchDesktop and SetProcessWindowStation to do this (see Window Stations and Desktops). If the service run under System account you will have all rights to do this. Depend on the configuration of your service it could be also needed to use SetTokenInformation with TokenSessionId to change the current session id. After the service process will run on the WinSta0\Winlogon desktop you can use functions like FindWindow and other GUI API to place any information in controls of the window (user name, password and so on) of other process. So you can implement more complex scenarios.
Firstly let me just say im not 100% sure how to fully complete such a application but I have a few tips.
you will need to create a Windows Service that starts during the Pre-Login, you can create a service in C#, An example of creating a C# Service is linked below:
http://msdn.microsoft.com/en-us/library/zt39148a(VS.80).aspx
Within your application you would set the property Startup Type to Automatic, This will automatically start your service on boot.
You should know that windows services run under a secure context by account so you will have to get your service to run with privs do do this.
In your Service Properties you can Click Log On and you can
To specify that the service uses the Local Service account, click This account, and then type the following NT AUTHORITY\LocalService.
To specify that the service uses the Network Service account, click This account, and then type the following NT AUTHORITY\NetworkService.
As your trying to do this remotly you will have to look at WMI (Windows Management Instrumentation) and you will be able to start/stop and send commands to your service.
Your service then would send a command to the Login Management (Not Sure of the name).
you may also wish to check this WOL class which will switch the computer on remotely as long as it supports Wake On LAN, If this is for a corporate environment then I advise you to check your network cards to make sure they are supported
http://www.codeproject.com/KB/IP/wolclass.aspx
I know of some education software that I use for schools that's called CC4 ( http://www.rm.com/shops/rmshop/story.aspx?cref=PS1026195 ) and we can do exactly what you need within this system, I'm not fully sure of how it works fully but i believe it takes the same principles described above.
I have a script written in Visual Basic that starts a process (given to the script as an argument) on a remote system (again, given as an argument) using WMI. This script works fine when using an Administrator account on the remote system, but when using a non-administrator account, I get the following error:
ConnectServer Failed w/ (-2147024891) Access is denied.
I'd like to be able to run processes on remote systems as a non-administrator user with this script, and I'm pretty sure the problem is due to security settings on the remote system, but I've not been able to reset the right ones.
It sounds like you need to configure launch and activation permissions for this user, on the target machine, via DCOMCNFG. By default non-admin users do not have remote launch and activiation permissions.
Alternatively, depending on the operating system you are connecting to, there may be a "Distributed COM Users" group to which you can add your user. This group already has the appropriate permissions. The Distributed COM Users group was first included in Windows Server 2003 Service Pack 1 (DCOM Security Enhancements).
You can read more about WMI and DCOM permissions here. More detailed steps on how to configure WMI and DCOM are included in the serverfault thread Which permissions/rights does a user need to have WMI access on remote machines?.
i'm using a Windows 2003 Server.
I have a session with my username on it and i have a windows application (not service) opened on it. I want this application to always be running.
The problem is, when Security updates force Windows to reboot, my session is closed and i need to reconnect to the session to get my application working again ..
How can i do to automaticaly force the opening of my user's session upon server's reboot ? (application launch is in the startup of my session)
Thanks
If you want to have the program running consistently, I would highly recommend making it into a Windows service (see also this page). Then you can set the username that the service logs on with (this is particularly important if the app needs to access networked resources), and even set the stability values to have the service restart itself if the EXE crashes for some reason.
Otherwise, if you really want the computer to login as your user and run the program, you could set the autologon parameters to your username and password, and put the shortcut to your program in the user's Start Menu Startup folder. (But this does not provide you any of the stability benefits that a service would.)
Add a startup script, http://technet.microsoft.com/en-us/library/cc779329(WS.10).aspx
What is the least set of privileges required that an account needs to be assigned in order to install a service using sc.exe? With account privileges I mean Local Security Settings in Windows Server 2003.
This service needs to be installed as part of a deployment script and is done remotely to said server by issuing something like the following command:
sc \\<server> create <servicename> binPath=<directory\service.exe> start=auto
Installing a service remotely requires no privileges on the target machine except the right to log on. But the account used must have the SC_MANAGER_CREATE_SERVICE access right on the Service Control Manager on the machine. This right is by default only given to members of the Administrators group. So by default the installing account must be an administrator on the target machine.
For systems prior to Windows Server 2003 SP1 (i.e W2K3, XP, W2K, etc.) the SCM security descriptor cannot be altered so this is the end of the story - you must be an administrator to install a service.
For W2K3 SP1 and later, if you do not want to run the script as an administrator then you could modify the security descriptor on the Service Control Manager for the target machine to include an ACE for the account the script runs under with the appropriate right(s). In general though, you would probably be better off re-thinking your deployment process to use an administrative account for service installation.