1

I am a developer and curious how Windows server machines are used.

  • A) I believe that they show interactive login screen but run without any user had ever logged-in.
    Correct?

In context of definition of (*), under which account the booted Windows AD-joined-machine is identified/secured by AD DC (Domain Controller):

  • B) Local machine account (Table 1 in (*))
  • C) Domain machine account (Table 2 in (*))

AD-joined machine show login screen permitting 2 basic logins thereafter:

    1. Local user account
    1. Domain user account

In which context - B) or C) - runs the following after A), i.e after login screen, the further logged-in local user 1)?

Update 1:
I know how identification, impersonation, and delegation of processes work.

This question is about when a Windows machine is booted and shows the interactive login screen with choices.

  1. Under which machine account is it booted before any (interactive) user login? when it shows login screen?

Well, basically I am re-writing the original questions.

But, having read (*), I cannot understand why "Machine SID for computer DEMOSYSTEM" (in Table 1) is needed at all. It is not used to access other machine before joining machine to AD, even less it seems to be needed after (joining a machine to AD).

Update 2:
Also, it is difficult to believe that local user account of machine before joining to domain is the same as after joining. Computer is identified and channel is secured by DC even for local account of AD computer but not for workgroup one.

Subquestions forked from this question:

Cited:

Related question:

Glorfindel
  • 1,213
  • 3
  • 15
  • 22

2 Answers2

9

Your question is not stated very clearly... howewer, here's how it basically works:

  • Each process running on a Windows machine runs in the context of a user account; this can be one of the three machine accounts (more on this later), a local user account or a domain user account.
  • A process can be started either by a logged on user, or as a service.
  • A process started by a logged on user inherits the user's security context, and it can interact with the user's session (keyboard/mouse/screen or RDP).
  • A service is a process that runs in background without direct user interaction; it can be started automatically when the system starts. A service, too, runs in the security context of a user account, just like any interactive process; this can be a local or domain user account, or a system account. A service can't interact directly with user sessions.
  • A process running in the context of a local user account can only access resources on the local machine (if allowed); it has no valid credentials to log on to other systems, and it can connect to network resources only by supplying another set of credentials, either those of a domain user account or of a local user account on the remote server.
  • A process running in the context of a domain user account can access local resources (if allowed) and network resources (if allowed) on other domain joined computers.
  • A process running in the system context can use one of three system accounts: Local System, Local Service and Network Service. These are built-in to every Windows computer since XP/2003 (before that only Local System existed).
  • A process running as Local System has full privileges on the system; a process running as Local Service has lower privileges (same as a standard user accounts) and can't connect to network resources; a process running as Network Service has the same local privileges as Local Service, but can access the network.
  • In either case, when a process running in one of the three system contexts connects to a network resources (so this is only true for Local System and Network Service, as Local Service just can't do that), it authenticates against remote system using the computer's machine account in the domain.

To sum it up:

  • If the process runs as a local user account, it doesn't have valid logon credentials on remote systems.
  • If the process runs as a domain user account, this user account is used for logging on to remote systems.
  • If the process runs either as Local System or Network Service, it logs on to remote systems using the computer's machine account in the domain.

Update:

There's not a single account under which "the machine is booted". When you are at the logon screen, there are lots of things running on the system: basic system services, the programs which actually manage the logon screen itself, and possibly plenty of application services if the system is a server. Each one of these processes can run under a different user account. Most system services, anyway, run using one of the three system accounts (Local System, Local Service, Network Service). You can see which account a service runs as in the Services MMC (and/or in the Task Manager).

The machine SID, as stated by that article and many others, is not actually needed or used for anything, besides being a "prefix" for the SIDs of local user accounts (which, as such, are never seen nor referenced outside the system itself); network authentication on behalf of the system uses the computer's domain account.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • @Massimo, thanks, this is basically answered. I shall postpone accepting the answer a little bit hoping that someone tell some more cute things. – Gennady Vanin Геннадий Ванин Aug 23 '10 at 14:58
  • Let me make it more clear for me. The local user account of joined to domain Windows is used exactly the same as before joining machine to domain? Are local user accounts of AD machine identified or managed by AD DC? – Gennady Vanin Геннадий Ванин Aug 23 '10 at 15:04
  • If AD machine is identified even before user logged-in, what does it change in AD machine local user identification or use (in comparison with it before joining the machine to AD)? – Gennady Vanin Геннадий Ванин Aug 23 '10 at 15:06
  • This may help http://serverfault.com/questions/61191/what-happens-when-a-computer-joins-an-active-directory-domain/61201#61201 – Kara Marfia Aug 23 '10 at 15:26
  • @vgv8, nothing changes for local user accounts when the machine is joined to a domain (unless some very specific GPOs are in place); they remain valid users, but for that system only; no other system will recognize them, or even be aware of their existence. – Massimo Aug 23 '10 at 15:48
  • @Massimo, I am somehow not satisfied with this answer. Something should be different. It is possible to include Domain Admins group to local Asministrators group. Correct? Is it possible to do the same for workgroup Windows computer (local) Administrators group? – Gennady Vanin Геннадий Ванин Aug 24 '10 at 16:01
  • @vgv8, local users and groups are exactly that: they are *local* to a given machine; they're not recognized outside that computer, and thay can't be used anywhere else. You can't put MachineA\UserA or MachineA\GroupA into MachineB\GroupB, or into Domain\GroupC. Domain users and groups are instead recognized by all computers in the domain, so you can put Domain\UserA or Domain\GroupA into MachineX\GroupX. – Massimo Aug 24 '10 at 17:07
  • One can include domain user into local Administrators group of AD computer. True? It is impossible to do the same for workgroup Windows. True? – Gennady Vanin Геннадий Ванин Aug 25 '10 at 03:51
  • See "Subquestions forked from this question" list of link in my main post, it is being dynamically updated – Gennady Vanin Геннадий Ванин Aug 25 '10 at 05:14
  • @vgv8 - what he is saying is true. If you choose not to believe it or don't understand why, don't get aggressive. Do some research on your own. – MDMarra Aug 25 '10 at 05:16
  • @vgv8 Yes, you can put domain accounts (both users and groups) into a local group. You can't put local accounts into a domain group. If Windows isn't domain-joined, then there aren't any domain accounts. – Richard Gadsden Aug 27 '10 at 15:24
  • Richard Gadsen, thanks, I could not understand "If Windows isn't domain-joined, then there aren't any domain accounts". What does then this http://msgoodies.blogspot.com/2006/04/runas-without-domain-trusts.html tell about? – Gennady Vanin Геннадий Ванин Aug 27 '10 at 15:43
  • @vgv8, that means "run this process as it would normally (i.e. the current logged in account), but if it needs to connect to a remote server, use these credentials for authenticating *to the remote host*.". – Massimo Aug 27 '10 at 17:04
2

Local accounts work exactly the same way on computers that are domain-joined or part of a workgroup. They have nothing to do with the domain and are not "secured by a DC" or any other part of AD.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • I am afraid to be banned for misunderstanding these issues in the same post. So, I forked them to http://serverfault.com/questions/174196/workgroup-windows-users-or-groups-can-use-domain-accounts-but-not-vice-versa – Gennady Vanin Геннадий Ванин Aug 25 '10 at 05:09
  • As I understood from following discussions, this is not correct. Local accounts of domained computers are under GPO from DC which local Administrator cannot override. This was the main purpose of question - to have or not second dual-boot workgroup Window for development. Domained computer simply does not give any chance. – Gennady Vanin Геннадий Ванин Aug 25 '10 at 23:35
  • Local accounts are not affected by domain GPO targeted at Users; Domain GPO for computers is still applied to the Domain Computer. – Chris S Aug 26 '10 at 00:58