☰

为什么计划任务以匿名形式访问数据库（与配置的帐户相比）？

tag-icon • tag-icon active-directory powershell scheduled-task winrm remoting
为什么计划任务以匿名形式访问数据库（与配置的帐户相比）？

**更新：我添加了一个更短的脚本，它会产生同样的问题。请参阅此端口的底部：

我有一个 PowerShell 脚本，它针对 MSSQL 服务器（不同的服务器）运行 SQL 查询。以交互方式运行时，该脚本按预期运行。当使用相同的凭据作为计划任务运行时，我没有获得查询结果。该任务运行脚本并报告成功，但没有检索到任何数据。从我们在日志中看到的内容来看，与 SQL 服务器的连接是这样的NT AUTHORITY\ANONYMOUS LOGIN。
我尝试为运行任务的机器设置委派。这里有一个身份验证问题，我就是找不到解决方案。

细节：

  • 任务服务器 Win 2019
  • SQL 服务器 Win 2019
  • SQL v.2019 在 Windows 可用性组上运行（如果脚本直接连接到活动节点，我会收到相同的错误）
  • 凭证是 AD 帐户，其密码在任务创建时存储
  • 帐户具有本地管理员权限
  • AD 功能级别 2016
  • 脚本使用Get-SQL模块进行查询
  • 连接字符串用途Integrated Security=true
  • 任务设置为以最高权限运行。

来自成绩单的相关信息：

**********************
Transcript started, output file is C:\Temp\sessionrecord2.txt
WARNING: Error opening connection to 'Server=svr126AGLa.myco.com;Integrated Security=true;Initial Catalog=mydb;ApplicationIntent=ReadOnly'
PS>TerminatingError(): "System error."
>> $global:?
True
**********************

脚本：

# Connects to database and retrieves the first 100k records

$Connect = "Server=svr126AGLa.myco.com;Integrated Security=true;Initial Catalog=mydb;ApplicationIntent=ReadOnly"
$exportDir = "D:\Logs\Events"

function Get-LSEventinfo {
    #Grabs all assets in lansweeper with usernames defined
    #stored in sqlite db
    $recs = $args[0]  #Number of records to request
    $sql = @"
    
    Select Top $recs tblAssets.AssetName,
    tblAssets.Domain,
    tblAssets.IPAddress,
    tblNtlog.Eventcode,
    Case tblNtlog.Eventtype
      When 1 Then 'Error'
      When 2 Then 'Warning'
      When 3 Then 'Information'
      When 4 Then 'Success Audit'
      When 5 Then 'Failure Audit'
    End As Eventtype,
    tblNtlogFile.Logfile,
    tblNtlogMessage.Message,
    tblNtlogSource.Sourcename,
    tblNtlogUser.Loguser,
    tblNtlog.TimeGenerated
  From tblAssets
    Inner Join tblAssetCustom On tblAssets.AssetID = tblAssetCustom.AssetID
    Inner Join tblNtlog On tblAssets.AssetID = tblNtlog.AssetID
    Inner Join tblNtlogFile On tblNtlogFile.LogfileID = tblNtlog.LogfileID
    Inner Join tblNtlogMessage On tblNtlogMessage.MessageID = tblNtlog.MessageID
    Inner Join tblNtlogSource On tblNtlogSource.SourcenameID = tblNtlog.SourcenameID
    Inner Join tblComputersystem On tblAssets.AssetID = tblComputersystem.AssetID
    Left Join tblNtlogUser On tblNtlogUser.LoguserID = tblNtlog.LoguserID
    Inner Join tsysOS On tsysOS.OScode = tblAssets.OScode
  Where tblAssets.Domain = 'DOMAIN' And tblNtlogFile.Logfile = 'Security' And
    tblAssetCustom.State = 1 And tblNtlog.Eventtype != 3 And tblComputersystem.Domainrole < 2
  Order By tblNtlog.TimeGenerated Desc
"@   

#Connect & query
try { $hld = get-sql -MsSQLserver -connection $connect -Session TT   }
catch { "failed real connect"| set-content c:\temp\errcon2.log -force}

# Export
try{  TT $SQL |export-csv "$exportDir\LSEventlog.csv" -notypeinformation; write-host "file exported to $exportdir"} }
Catch {write-output "failed query"}
    TT -close
    $hld = $null
}

# main:
  Start-Transcript -Path C:\Temp\sessionrecord2.txt
  Get-LSEventinfo 100000
  Stop-Transcript

简化脚本 - 错误相同。注意 - 无论我们连接到 AvailGrp 侦听器还是其中一个节点，错误都是相同的

$Connect = "Server=tcp:Svr126SQLb.myco.com;Integrated Security=SSPI;Initial Catalog=mydb;ApplicationIntent=ReadOnly"
#$Connect = "Server=tcp:Svr126AGLa.myco.com;Integrated Security=SSPI;Initial Catalog=mydb;ApplicationIntent=ReadOnly"


Start-Transcript -Path C:\Temp\sessionrecord2.txt
$sql = @"
  Select * from tblAssets.Domain
"@   

 $hld = get-sql -MsSQLserver -connection $connect -Session TT -ForceNew 
 TT -close
 $hld = $null
 Stop-Transcript

答案1

事实证明，这类似于双跳问题。为了解决这个问题，我Enable-WSManCredSSP Client –DelegateComputer <schedTaskHost>在任务服务器和Enable-WSManCredSSP ServerSQL 服务器上运行了该程序。

答案2

该问题似乎与 Kerberos 委派有关。重要事项：正确使用计算机名称、服务帐户和注册的 SPN。
请尝试以下操作：

答案3

这看起来很像是与 Kerberos 相关的问题。

首先，我会检查该任务是否能够从域控制器获取票证。检查所有任务，以查找安全日志中 ID 为 4769 的事件。它应该包括帐户名（运行该任务的用户）和运行 SQL 服务的帐户的用户名。此事件应该与用户的缓存票证相媲美（可以使用清单）

如果不是这种情况，您应该在所有域控制器上查找运行时与 Kerberos 相关的错误。

没有日志很难提供建议，但我可以想象有一些东西阻止任务计划程序到达你的域控制器（Windows 防火墙、策略、防病毒软件）

也许像这会有帮助。

我还要检查的内容（不是特别与 Kerberos 相关）：

  • 检查凭据管理器中有关您的用户会话有权访问但计划任务可能无权访问的 SQL Server 的条目。
  • 用户的 UPN、sAMAccountName 或 CN 是否彼此不同？其中是否有一个被更改过？
  • 这些主机和域控制器之间是否存在网络限制

相关内容