如何定位持续使用旧账号密码访问AS400数据库的未知进程

DevOps 小满

2026-4-23

这种找不到源头的遗留进程确实挺头疼的，我给你几个实战中验证过的排查方向，按优先级来试试：

1. 用Windows Sysinternals工具精准抓进程

这绝对是最有效的手段之一，推荐两个工具配合使用：

Process Monitor（ProcMon）：打开后设置过滤规则，重点关注包含AS400主机名/IP的网络操作，或者包含旧用户名的字符串（记得勾选「Include」选项）。它会实时记录所有进程的文件、注册表、网络活动，很容易定位到发起连接的进程。
Process Explorer：直接按Ctrl+F搜索旧用户名，它会扫描所有进程的内存空间，找到包含该字符串的进程——哪怕密码是加密的，用户名大概率是明文存在内存里的，这招经常能直接「揪出」罪魁祸首。

你已经改了链接服务器，但SQL Server里还有不少藏凭证的地方：

检查SSIS包：不管是存在文件系统还是msdb数据库里的SSIS包，都可能硬编码了旧的连接信息，可以用SQL Server Data Tools（SSDT）打开包查看，或者用SQL查询扫描msdb里的包内容。
排查代理作业的遗留配置：哪怕禁用了SQL Agent，之前的作业可能有未清理的步骤，或者作业的「步骤属性」里藏着连接字符串，去msdb的sysjobsteps表查一查：
```
SELECT j.name, js.command
FROM msdb.dbo.sysjobs j
JOIN msdb.dbo.sysjobsteps js ON j.job_id = js.job_id
WHERE js.command LIKE '%旧用户名%' OR js.command LIKE '%AS400%'
```
搜索所有数据库的对象定义：跑个查询找包含旧用户名的存储过程、视图、函数等：
```
USE [你的数据库名];
SELECT name, type_desc
FROM sys.all_objects
WHERE OBJECT_DEFINITION(object_id) LIKE '%旧用户名%'
```
记得要遍历所有数据库，包括系统库。

常规的任务和服务可能漏了这些地方：

隐藏的定时任务：用命令行导出所有任务，再搜索关键词：
```
schtasks /query /v /fo list > C:\tasks.txt
```
然后打开tasks.txt搜索旧用户名或AS400相关内容，有些任务会被设置为隐藏，图形界面看不到。
服务的启动参数和运行身份：打开服务管理器，检查每个服务的「登录」标签，看有没有用特定用户运行的服务；或者用命令导出所有服务的配置：
```
sc query type= service > C:\services.txt
```
重点看服务的启动参数里有没有包含连接信息。
事件触发的任务：有些任务不是定时执行，而是当某个系统事件（比如日志报错、服务启动）触发时才运行，去任务计划程序的「事件触发器」里仔细检查。

实时抓连接PID：在AS400日志刚记录到访问的瞬间，立刻在Windows服务器上执行：
```
netstat -ano | findstr "AS400的IP"
```
找到对应的PID后，再用tasklist /fi "PID eq 1234"（替换成实际PID）查看进程名称，这招要快，最好提前准备好命令，一收到报警就执行。
Wireshark过滤DRDA协议：AS400用DRDA协议通信，默认端口446，设置过滤规则drda，捕获完整会话，你能在初始化包中看到用户名（通常是明文或简单加密），结合进程ID就能定位到来源。

别忽略服务器上的其他软件：

备份/监控/ETL工具：比如有些备份软件会跨库备份，监控工具会定期采集数据，这些工具的配置里可能藏着旧的AS400连接信息，去它们的设置界面或配置文件里找找。
开机自启的脚本和程序：检查系统启动文件夹（C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp）和用户启动文件夹，还有注册表的HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run、RunOnce项，看看有没有BAT、PS1、VBS这类脚本。
IIS应用程序池：如果服务器上装了IIS，检查每个网站的web.config文件，或者应用池的运行身份，有些Web应用会在后台连接AS400。

备注：内容来源于stack exchange，提问作者tnk479