我是一名开发人员，很好奇 Windows 服务器机器是如何使用的。
- A) 我相信它们显示了交互式登录屏幕，但在没有任何用户登录的情况下运行。
对吗？
在定义的上下文中（*），启动的 Windows AD 加入计算机在该帐户下由 AD DC（域控制器）识别/保护：
连接 AD 的机器显示登录屏幕，随后允许 2 次基本登录：
-
- 本地用户帐户
-
- 域用户帐户
在哪种上下文中 - B）或C） - 在A）之后运行以下命令，即在登录屏幕之后，进一步登录的本地用户1）？
更新 1：
我知道流程的识别、模拟和委派是如何工作的。
这个问题是关于 Windows 机器何时启动并显示带有选择的交互式登录屏幕。
在任何（交互式）用户登录之前，它在哪个机器帐户下启动？当它显示登录屏幕时？
嗯，基本上我正在重写原来的问题。
但读过（*），我完全不明白为什么需要“计算机 DEMOSYSTEM 的计算机 SID”（在表 1 中）。在将机器加入 AD 之前，它不用于访问其他机器，在将机器加入 AD 之后（将机器加入 AD）似乎更不需要它。
更新 2：
此外，很难相信计算机在加入域之前和加入域之后的本地用户帐户相同。即使对于 AD 计算机的本地帐户，计算机也可以通过 DC 进行识别和通道保护，但对于工作组计算机则不行。
从该问题衍生出的子问题：
引用：
相关问题：
答案1
您的问题没有表述得很清楚...然而，它的基本工作原理如下：
- Windows 机器上运行的每个进程都在用户帐户的上下文中运行；这可以是三个机器帐户之一（稍后会详细介绍）、本地用户帐户或域用户帐户。
- 进程可以由登录用户启动，也可以作为服务启动。
- 登录用户启动的进程继承了用户的安全上下文，并且可以与用户的会话（键盘/鼠标/屏幕或 RDP）进行交互。
- 服务是在后台运行而无需直接用户交互的进程；它可以在系统启动时自动启动。服务也在用户帐户的安全上下文中运行，就像任何交互式进程一样；这可以是本地或域用户帐户，也可以是系统帐户。服务不能直接与用户会话交互。
- 在本地用户帐户上下文中运行的进程只能访问本地计算机上的资源（如果允许）；它没有有效的凭据来登录到其他系统，并且只能通过提供另一组凭据（域用户帐户或远程服务器上的本地用户帐户的凭据）才能连接到网络资源。
- 在域用户帐户上下文中运行的进程可以访问其他加入域的计算机上的本地资源（如果允许）和网络资源（如果允许）。
- 在系统上下文中运行的进程可以使用三个系统帐户之一：
Local System和Local Service。Network Service自 XP/2003 以来，这些帐户内置于每台 Windows 计算机中（在此之前仅存在本地系统）。 - 以本地系统身份运行的进程对系统拥有完全权限；以本地服务身份运行的进程具有较低权限（与标准用户帐户相同）并且无法连接网络资源；以网络服务身份运行的进程具有与本地服务相同的本地权限，但可以访问网络。
- 无论哪种情况，当在三个系统上下文之一中运行的进程连接到网络资源时（因此这仅适用于本地系统和网络服务，因为本地服务无法做到这一点），它会使用域中的计算机的机器帐户对远程系统进行身份验证。
把它们加起来：
- 如果该进程以本地用户帐户运行，则它在远程系统上没有有效的登录凭据。
- 如果该进程以域用户帐户运行，则该用户帐户用于登录远程系统。
- 如果该进程作为本地系统或网络服务运行，它将使用域中的计算机的机器帐户登录到远程系统。
更新：
没有一个帐户可以“启动机器”。当您在登录屏幕上时，系统上运行着许多东西：基本系统服务、实际管理登录屏幕本身的程序，以及如果系统是服务器的话可能运行的大量应用程序服务。这些进程中的每一个都可以在不同的用户帐户下运行。无论如何，大多数系统服务都使用三个系统帐户（本地系统、本地服务、网络服务）之一运行。您可以在 MMC Services（和/或任务管理器）中查看服务以哪个帐户运行。
正如该文章和许多其他文章所述，机器 SID 实际上并不需要或用于任何事情，除了作为本地用户帐户 SID 的“前缀”（因此，在系统之外永远不会看到或引用）；代表系统的网络身份验证使用计算机的域帐户。
答案2
本地帐户在加入域或属于工作组的计算机上的工作方式完全相同。它们与域无关，并且不受“DC 保护”或 AD 的任何其他部分保护。