随着微软基础架构的深入普及和各个企业对信息化建设的重视，在微软产品日益成熟的今天，域环境的应用也越来越广泛。都会接触到很多应用产品。无论是微软系列的产品本身，或者是现在的很多第三方应用，我们都希望能基于员工的域账号做一个统一的身份验证，从而严格控制微软平台上各个应用的访问权限的安全。因此，域账号的验证机制就体现得格外重要。
无论是在甲方公司日常的运维中，还是在乙方公司大大小小的项目中，会有企业的员工反映，自己唯一的域账号时常被锁，或者时常弹出对话框，请求用户输入密码确认。这样就会导致用户无法打开工作应用，工作软件，甚至工作电脑。这样势必对员工的工作产生了极大的影响。员工很想知道为什么自己在没有输错密码的同时，会有这些验证失败的提示。
本文主要讲述是如何通过微软工具和相关操作，查找定位到验证失败的原因。
借助工具：
LockoutStatus
下载地址二：http://down.51cto.com/data/361708
接下来，我们就实际演示一遍如何查询到AD账号被锁的原因
1. 首先将LockoutStatus放到域环境中的任一一台DC上。
2. 使用管理员权限将LockoutStatus打开
3. 点击文件选项File，选择目标Select Target
4. 在目标用户名列写出需要查询的域账号（被锁账号），点击OK
5. 现在开始扫描该账号在所有DC上的被锁记录
6. 扫描完成后，你可以找到很多账号锁定信息，包括DC名，站点，账号状态，错误密码计数器，和最后一次错误密码时间。
7. 找寻到最后一条错误时间记录，找到相应的DC名，远程登录这台域控。
8. 找到这个时间点的日志
9. 用具有权限的管理员账号打开日志文件
10. 选择筛选当前日志来减小日志范围。
11. 在关键词栏中，勾选“审核失败”来作为筛选题目。
12. 筛选完成后，找到该时间点事件日志。我们可以很清晰的看到“源工作站”一栏，意思是该错误密码申请，来自这台客户端 CN1D8DKC。
到这里，我们就已经知道了导致账号被锁的错误密码的发送源是来自这台客户机，但是这样并没有完。如果企业内部资产记录和信息安全做的比较好比较严格的企业，可能通过机器名已经能够查到这台客户端属于哪一个员工在使用，就可以拿着以上的证据去找他“摆聊斋”了。但是在很多企业，客户机名是一个无法定位到员工头上的随机数字或者是编号，更或者是恶作剧或者是“栽赃嫁祸”这个时候怎么办呢？不要着急，我们采用Windows Power Shell来“找出凶手”，接下来我们继续看。
13. 用管理员权限打开Power Shell,然后输入一下命令来查询是哪个账户在登录当前这台终端机。
get-wmiobject -computername CN1D8DKC win32_computersystem | format-list username
系统最终查询出的账号是 cn001\cn1wh0u0
也就是说，目前这台名为CN1D8DKC的客户机是域用户cn1wh0u0正在使用。
14. 用dsa.msc命令打开AD与用户管理控制台。
15. 找到该用户的详细信息。
到此，我们终于找到了“罪魁祸首”！当然了，密码被锁的具体原因还要通过我们查出来的这台源客户端电脑的本机日志才能更准确的查出来，原因也有很多，从我们日常的经验来看，大部分原因是因为A用户曾经使用过B用户的电脑，然后在访问某内部网页或者应用时记住了密码。结果过段时间A用户修改了自己的域账号密码，结果B用户这台电脑还是一直在发送老的密码，悲剧就发生了。对待这样的事情，大家还是心平气和的对待这个问题，也可能是各种各样的原因造成的，相信真正使坏的人也确实是极少数。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
下面在给大家share几个查询用户信息的命令
1. net user /domain username
2. 查询用户帐号的位置
dsquery user –samid username
3. 将第2步查出的全路径通过命令，查出账号更详细信息
repadmin /showobjmeta 域控名 "CN=马骏一,OU=Chengdu,DC=corp,DC=jbhydro,DC=com"
