Upon analysis, I learnt that even _KPROCESS objects can be members of the ActiveProcessLinks list. What is the difference between _EPROCESS and _KPROCESS objects? When is one created and one not? What are the conceptual differences between them?
Windows – what is the difference between _EPROCESS object and _KPROCESS object
kernelwindows
Related Solutions
Windows Server 2003 and later (i.e. anything after Windows XP 32 bit) provide the where.exe
program which does some of what which
does, though it matches all types of files, not just executable commands. (It does not match built-in shell commands like cd
.) It will even accept wildcards, so where nt*
finds all files in your %PATH%
and current directory whose names start with nt
.
Try where /?
for help.
Note that Windows PowerShell defines where
as an alias for the Where-Object
cmdlet, so if you want where.exe
, you need to type the full name instead of omitting the .exe
extension.
Since there is so much confusion about functionality of standard service accounts, I'll try to give a quick run down.
First the actual accounts:
LocalService account (preferred)
A limited service account that is very similar to Network Service and meant to run standard least-privileged services. However, unlike Network Service it accesses the network as an Anonymous user.
- Name:
NT AUTHORITY\LocalService
- the account has no password (any password information you provide is ignored)
- HKCU represents the LocalService user account
- has minimal privileges on the local computer
- presents anonymous credentials on the network
- SID: S-1-5-19
- has its own profile under the HKEY_USERS registry key (
HKEY_USERS\S-1-5-19
)
- Name:
-
Limited service account that is meant to run standard privileged services. This account is far more limited than Local System (or even Administrator) but still has the right to access the network as the machine (see caveat above).
NT AUTHORITY\NetworkService
- the account has no password (any password information you provide is ignored)
- HKCU represents the NetworkService user account
- has minimal privileges on the local computer
- presents the computer's credentials (e.g.
MANGO$
) to remote servers - SID: S-1-5-20
- has its own profile under the HKEY_USERS registry key (
HKEY_USERS\S-1-5-20
) - If trying to schedule a task using it, enter
NETWORK SERVICE
into the Select User or Group dialog
LocalSystem account (dangerous, don't use!)
Completely trusted account, more so than the administrator account. There is nothing on a single box that this account cannot do, and it has the right to access the network as the machine (this requires Active Directory and granting the machine account permissions to something)
- Name:
.\LocalSystem
(can also useLocalSystem
orComputerName\LocalSystem
) - the account has no password (any password information you provide is ignored)
- SID: S-1-5-18
- does not have any profile of its own (
HKCU
represents the default user) - has extensive privileges on the local computer
- presents the computer's credentials (e.g.
MANGO$
) to remote servers
- Name:
Above when talking about accessing the network, this refers solely to SPNEGO (Negotiate), NTLM and Kerberos and not to any other authentication mechanism. For example, processing running as LocalService
can still access the internet.
The general issue with running as a standard out of the box account is that if you modify any of the default permissions you're expanding the set of things everything running as that account can do. So if you grant DBO to a database, not only can your service running as Local Service or Network Service access that database but everything else running as those accounts can too. If every developer does this the computer will have a service account that has permissions to do practically anything (more specifically the superset of all of the different additional privileges granted to that account).
It is always preferable from a security perspective to run as your own service account that has precisely the permissions you need to do what your service does and nothing else. However, the cost of this approach is setting up your service account, and managing the password. It's a balancing act that each application needs to manage.
In your specific case, the issue that you are probably seeing is that the the DCOM or COM+ activation is limited to a given set of accounts. In Windows XP SP2, Windows Server 2003, and above the Activation permission was restricted significantly. You should use the Component Services MMC snapin to examine your specific COM object and see the activation permissions. If you're not accessing anything on the network as the machine account you should seriously consider using Local Service (not Local System which is basically the operating system).
In Windows Server 2003 you cannot run a scheduled task as
NT_AUTHORITY\LocalService
(aka the Local Service account), orNT AUTHORITY\NetworkService
(aka the Network Service account).
That capability only was added with Task Scheduler 2.0, which only exists in Windows Vista/Windows Server 2008 and newer.
A service running as NetworkService
presents the machine credentials on the network. This means that if your computer was called mango
, it would present as the machine account MANGO$
:
Related Topic
- Windows – the difference between Cygwin and MinGW
- Windows – How to run a PowerShell script
- .net – Difference between “managed” and “unmanaged”
- Java – Failed to load the JNI shared Library (JDK)
- Windows – the difference between NTFS Junction Points and Symbolic Links
- Linux – How do SO_REUSEADDR and SO_REUSEPORT differ
- Windows – Filename too long in Git for Windows
Best Answer
This is simplified, but the kernel mode portion of the Windows O/S is broken up into three pieces: the HAL, the Kernel, and the Executive Subsystems. The Executive Subsystems deal with general O/S policy and operation. The Kernel deals with process architecture specific details for low level operations (e.g. spinlocks, thread switching) as well as scheduling. The HAL deals with differences that arise in particular implementations of a processor architecture (e.g. how interrupts are routed on this implementation of the x86). This is all explained in greater detail in the Windows Internals book.
When you create a new Win32 process, both the Kernel and the Executive Subsystems want to track it. For example, the Kernel wants to know the priority and affinity of the threads in the process because that's going to affect scheduling. The Executive Subsystems want to track the process because, for example, the Security Executive Subsystem wants to associate a token with the process so we can do security checking later.
The structure that the Kernel uses to track the process is the KPROCESS. The structure that the Executive Subsystems use to track it is the EPROCESS. As an implementation detail, the KPROCESS is the first field of the EPROCESS, so the Executive Subsystems allocate the EPROCESS structure and then call the Kernel to initialize the KPROCESS portion of it. In the end, both structures are part of the Process Object that represents the instance of the user process. This should also all be covered in the Windows Internals book.
-scott