解析进程为何不能访问网络资源

昨天被windows服务不能访问网络资源搞得焦头烂额，我的运行环境如下：

用C#写的Windows服务使用localSystem运行，电脑本身不在域中(电脑如果是用域账号登录就没有这个问题了)，但使用windows凭据登录域并访问其中一个共享网盘。登录系统使用的账号是Administrator。该服务操作本机的各种资源都是没有问题的，但访问网盘不管是以IP直接访问还是使用Administrator已经映射的网盘都是无权限的。使用该服务调用Net Use来建立网络连接也不行。

网上找了半天，找到一篇[e-mail]转载的文章：http://blog.itpub.net/10752043/viewspace-961042/

讲的相对通俗易懂，特拿来收藏。

通读之后，我觉得一种解决办法是使用user安装，然后将服务的登录账号改为本机当前使用的帐户(Administrator)并输入密码，找到这篇文章前我就是这么做的[已实现]，只是部署时比较费时。

另一种办法是以localSystem安装运行，但允许服务与桌面交互[待验证]。--简单测试了一下，还是不行啊

原文如下：

前言

  system权限的进程使.NET use访问网络共享时产生“系统发生 1312 错误，指定的登录会话不存在，可能已被终止。”，本文试图对此进行一下解释。再有就是使用IIS创建的进程通常也不能使用网络资源，产生的错误是一样的，原因也在这篇文章里阐述了。

　

本地系统账号

  当用户登录系统时，windows NT/2000 将验证他的密码，如果用户验证成功，系统产生一个访问令牌，它包含用户安全标示符(SID)、组SID列表、特权列表和模拟(Impersonating)信息等安全信息。该用户启动的任何进程都将附加该令牌，访问令牌代表进程的安全环境，它控制了进程与可保护对象(securable object)的交互。当进程访问一个可保护对象时，系统将该对象的访问控制列表(ACL)中的每个访问控制项(ACE)和访问令牌中的 SID 进行比较以确定进程是否可以访问该对象。由于用户启动的任何进程都将附加该用户的访问令牌，因此任何进程都知道用户的 SID 并且可以访问它。

  Local System 账号是内置的系统账号，所有系统进程都在 Local System 的安全环境中运行，Local System 账号是用于启动服务的默认账号，它继承了服务控制管理器的安全环境，在本地计算机上拥有几乎无限的权限。在 Local System 账号环境运行的进程没有与任何已登录的用户账号相联系，没有用于验证的信任凭证（用户名、域和密码），而该信任凭证(credential)用于网络上其他计算机的验证，这样以 Local System 账号运行的进程就不能访问网络资源，如网络共享。

  在 Local System 账号环境运行的进程和普通进程的不同之处在于：

1) 注册表的 HKEY_CURRENT_USER 键是和缺省用户而不是当前用户相联系的，要访问其他用户的配置文件，需要先模拟该用户，然后再访问 HKEY_CURRENT_USER 。

2) 可以打开 HKEY_LOCAL_MACHINESECURITY 注册表键

3) 该进程不能访问网络资源，如共享、管道，因为它不能提供信任凭证，而只能使用空连接。 在 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters 处的 NullSessionPipes 和 NullSessionShares 的值指明了可以被空连接访问的管道和共享。

或者也可以设置 RestrictNullSessAccess = 0，以允许空连接的用户访问该计算机上的所有管道和共享。（呵呵，这个是个安全隐患呦，可不要干呀。上边两个值最好也全都设成空）

4) 不能和其他程序共享对象，除非在创建对象时设置 DACL 允许用户访问。

5) 如果启动命令行提示符来运行批处理文件，用户可以按 Ctrl+C 来终止批处理的运行，并且用户就获得了一个 Local System 权限的 shell。

IIS服务的模拟

  正是由于服务程序运行在权限极大的 Local System 账号下，如果网络客户也使用该账号来访问系统将给系统带来安全隐患，因此 NT/2000 提供了模拟功能 --- 服务程序在处理客户请求时使用一个权限较低的客户身份运行，处理完客户请求再恢复。IIS就是使用这个原理，虽然配置 iis 以 Local System 账号运行，而一般的匿名请求就是以 IUSR_computer 身份（guests 组）和 IWAM_computer 身份（guests 组）运行的。模拟又分两种，在进程里使用模拟令牌来模拟某个用户（模拟令牌里的用户）和使用主要令牌来创建新的进程。在进程内的某个线程可以使用 ImpersonateLoggedOnUser（同时需要提供一个代表某个登录用户的模拟令牌）模拟用户时，这个线程就是该模拟令牌代表的用户的身份，处理完成后使用 RevertToSelf 恢复自己的身份。创建新的进程使用 CreateProcesSASUser（比 CreateProcess 函数多一个主要令牌的参数），这样启动的新进程就不是父进程的身份，而是主要令牌代表的登录用户。对于ASP、asa等ISapi扩展，是动态连接库的形式，是进程内的模拟；而CGI程序（cmd.exe，ncx99.exe）则是使用的创建新进程方式进行的模拟。

  不过即使我们通过IIS启动了进程，一般仍然不能使用网络资源，就是不能使用 net use，如果使用将产生“系统发生 1312 错误。指定的登录会话不存在。可能已被终止。”的错误，这是因为不同的登录类型造成的。windows NT支持以下5种登录类型：

登录类型 含义 LOGON32_LOGON_INTERACTIVE  交互登录：这个是通常的本地登录或者终端服务、telnet等 LOGON32_LOGON_SERVICE  服务登录：作为服务登录系统 LOGON32_LOGON_NETWORK  网络登录：用于高性能的服务来验证明文密码 LOGON32_LOGON_BATCH 批处理登录：用于批处理服务器或者同时处理多个明文验证的高性能服务器 LOGON32_LOGON_UNLOCK  解除锁定登录：设计用来为 GINA DLL 记录交互登录用户解除工作站锁定的。这种类型允许在工作站解除锁定时产生一条审核记录

除了以上5种登录类型外，Windows 2000 还支持以下两种类型LOGON32_LOGON_NETWORK_CLEARTEXT，LOGON32_LOGON_NEW_CREDENTIALS（详细详细参见 msdn 里关于 LogonUser 函数的解释）。

根据 IIS 验证方式的不同，IIS支持不同的登录类型。IIS 4支持以下5种类型的验证方式：

验证类型

模拟类型 匿名登录(没有验证)，允许密码自动同步（缺省） Network － 网络 匿名登录(没有验证)，禁止密码自动同步 IIS Clear Text － IIS明文 基本验证 IIS Clear Text － IIS明文 集成NT验证，NTLM Network － 网络 客户端使用 SSL Certificate Mapping Interactive － 交互

 

  可否访问网络资源由模拟的登录令牌类型决定，网络登录令牌是不能访问网络资源的，因为这种类型的访问令牌是在通过网络完成验证后由服务器创建的，服务器使用这种令牌来访问网络上的其他计算机是一个安全隐患。

交互登录就和本地登录一样，是可以访问网络资源的。

IIS 支持的第三种类型的访问令牌是批处理令牌，它是设计用来在安全的环境里进行批处理工作的，批处理令牌也可以访问网络资源。

IIS 明文验证的概念来自于IIS是以明文的方式获得用户名和密码的事实。管理员可以控制明文登录创建交互令牌、批处理令牌还是网络令牌，这由 metabase的 LogonMethod 属性决定。缺省这种登录创建交互令牌。

  一般管理员在配置 IIS 时会允许密码自动同步（这样就不用关心 IUSR_computer 用户的密码的更改），还有就是集成 NT 的 NTLM 验证也是比较常见的，不过这两者验证都将创建网络访问令牌，因此我们就不能访问网络资源了。

　

参考文献：

source/Access%20Tokens.html">Access Tokens Client's Security Context LocalSystem Account Impersonating Clients q207671-Accessing Network Files from IIS Applications ImpersonateLoggedOnUserCreateProcessAsUser RevertToSelf LogonUser   以上所有资料均来自MSDN

　

注：关于MSDN资料里系统账号特殊之处这段：

• The registry key HKEY_CURRENT_USER is associated with the default user, not the current user. To access another user's profile, impersonate the user, then access HKEY_CURRENT_USER.

本来2000/5的资料是这样的：

• The service cannot open the registry key HKEY_CURRENT_USER.
  

后来获得最新资料，微软的说法有变，意思自然也不同了。