事件ID 1380是Windows安全日志中一个比较特殊的登录失败事件，完整描述通常为“登录失败: 未授予此计算机上的请求登录类型”。它和常见的密码错误、账户锁定不同，密码本身并没有问题，问题出在账户没有被授予以某种方式登录这台计算机的权限。也就是说，系统在验证凭据之后，根据本地安全策略判断该账户不允许多种登录类型中的一种，于是直接拒绝了这次访问。理解这一点是排查该问题的关键，因为盲目重置密码对解决1380事件基本没有帮助。
一、事件ID 1380的定位与基本信息解读
要分析1380事件，首先需要在事件查看器中找到它。打开运行对话框输入eventvwr.msc，依次展开“Windows日志”和“安全”，然后在右侧操作面板中点击“筛选当前日志”，在事件ID框中填入1380，即可列出所有相关的登录失败记录。建议同时观察该事件出现的时间规律，是集中在某个固定时间段，还是伴随某项计划任务、服务启动而产生，这能帮助快速锁定触发源。
双击打开某条1380事件后，重点关注“常规”选项卡中的几个字段。首先是“帐户名”，它指明了是哪个用户账户被拒绝登录，如果是机器账户（以美元符号结尾的名称）则可能涉及计算机之间的访问；其次是“登录类型”字段，这个数字非常关键，常见的类型包括类型2（交互式登录，即本地键盘登录）、类型3（网络登录，例如访问共享文件夹、远程命令执行）、类型4（批处理登录，典型场景是计划任务）和类型5（服务登录，服务以某个账户身份启动）。明确登录类型之后，排查方向就清晰了：类型3被拒基本可以确定是网络访问权限问题，类型4被拒则要看计划任务运行账户是否具备批处理登录权限。
此外还要留意“进程名”和“工作站名”字段。进程名记录了发起登录请求的程序，例如svchost.exe、cmd.exe或者某个业务程序；工作站名则说明请求来自哪台机器。在域环境中，如果日志出现在成员服务器上，但账户来自其他主机，说明是跨机器访问被拒，此时除了检查本机策略，还需要确认域级别的组策略是否覆盖了相关设置。
二、导致1380事件的常见原因分析
第一个常见原因是“拒绝本地登录”或“拒绝从网络访问这台计算机”策略中包含了目标账户或其所属组。Windows的权限判断逻辑是拒绝优先，只要账户命中了拒绝列表，即使同时处于允许列表中也无法登录。有些管理员在加固系统时习惯把Everyone或某个业务组加入拒绝列表，事后却忘记了具体影响范围，这是生产环境中最容易踩的坑。
第二个原因是允许列表配置不完整。“允许在本地登录”“从网络访问此计算机”“作为批处理作业登录”“作为服务登录”这几个用户权限分配项分别对应不同的登录类型，如果某个账户（尤其是自建的服务账户、计划任务专用账户）没有被显式加入对应列表，或者其原本依赖的组被从列表中移除，就会出现1380。域环境下还要注意，如果域组策略中定义了这些设置，本地策略会被覆盖，单看本机配置容易误判。
第三个常见原因是来宾账户相关问题。当客户端使用来宾身份访问共享资源，而目标机器的来宾账户被禁用，或“拒绝从网络访问这台计算机”中包含Guest时，也会记录为1380或类似的登录失败。另外，部分第三方安全加固软件、堡垒机Agent或者安全基线脚本会批量收紧登录权限，部署之后业务账户突然无法登录，这类情况在排查时容易被忽略，建议同时检查近期是否安装过安全类软件或执行过基线加固脚本。
三、通过本地安全策略修复权限配置
对于工作组环境的独立机器，直接在本地安全策略中调整即可。按Win加R组合键输入secpol.msc打开本地安全策略，定位到“本地策略”下的“用户权限分配”，这里集中了所有与登录类型相关的权限项。根据事件中记录的登录类型，找到对应的策略进行处理：登录类型2对应“允许在本地登录”，类型3对应“从网络访问此计算机”，类型4对应“作为批处理作业登录”，类型5对应“作为服务登录”。
具体操作分两步。第一步，双击打开“拒绝本地登录”和“拒绝从网络访问这台计算机”，把目标账户或其所在组从列表中移除，先排除拒绝策略的干扰；第二步，打开对应的允许策略，例如计划任务场景下打开“作为批处理作业登录”，点击“添加用户或组”，输入被拒绝的账户名称，点击检查名称确认后确定保存。修改完成后运行以下命令强制刷新策略，无需重启即可生效：
gpupdate /force
修改后可以用whoami /all查看当前账户所属的组列表，确认账户是否通过某个组间接获得了权限。如果希望验证网络登录权限，可以从另一台机器尝试访问共享路径，或使用以下命令测试：
net use \\目标机器IP\IPC$ /user:账户名 密码
命令执行成功说明网络登录权限已恢复，如果仍然失败，再回事件查看器查看最新的1380记录，确认登录类型和账户是否有变化。
四、域环境下的组策略排查与进阶处理
域环境中的处理思路类似，但配置位置不同。需要在域控制器上打开组策略管理控制台，输入gpmc.msc，找到应用到目标计算机的组策略对象，编辑“计算机配置”“Windows设置”“安全设置”“本地策略”“用户权限分配”路径下的对应项。修改之后同样要等待策略自动刷新或手动执行gpupdate。一个实用技巧是在客户端机器上运行命令查看策略实际生效结果：
gpresult /h C:\policy_report.html
生成的HTML报告会列出所有已应用的组策略对象，可以确认策略是否真正下发到了出问题的机器上。如果报告显示策略已应用但问题依旧，要检查是否存在多个组策略对象配置冲突，策略的处理顺序是后应用的胜出，被覆盖的设置不会体现在本地安全策略界面中，这也是域环境排查权限问题最容易出错的环节。
如果事件中的登录类型是4或5，即计划任务和服务登录被拒，除了补齐“作为批处理作业登录”和“作为服务登录”权限外，还要确认账户本身没有过期、没有被禁用。用下面这条命令可以快速导出计划任务及其运行账户，逐一核对是否存在使用低权限账户或已停用账户的任务：
Get-ScheduledTask | Select-Object TaskName, TaskPath, State, @{Name="RunAsUser";Expression={$_.Principal.UserId}} | Format-Table -AutoSize最后还有一种兜底排查手段：如果反复调整策略仍无法定位原因，可以临时启用登录过程的详细审核，在安全策略中开启“审核登录事件”的成功和失败审核，结合4624成功登录事件与1380失败事件交叉对比，观察同一个账户在哪些登录类型上成功、哪些被拒，往往能快速发现策略配置的遗漏点。确认问题解决后，建议把涉及的账户、登录类型和对应的权限项记录下来，形成变更文档，避免后续安全加固时再次误删权限。