AD域帐号被锁问题排查

转载于：http://gnaw0725.blog.51cto.com/156601/668123

今天碰到10几个人反映有些软件不好用，登录域后，无法访问共享。当时我比较奇怪，到客户端一一检查意见，共享服务及软件运行服务全部正常。就尝试重启一下客户端，重启后就可以正常使用。但是有的也无法使用。

我就检查AD服务器。发现这些帐号是锁定状态，我就将其“启用”开始使用。过差不多3个小时后又出现相同问题。我就将策略中“用户登录事件”打开来“审核[成功]及[失败]”事件。找到日志如下，请大家帮我分析一下。该如何下手解决该问题：

    User Logoff:                                                            
 event id 538
        User Name:        DSH-60$
        Domain:                xxx
        Logon ID:                (0x0,0xD344B2)
        Logon Type:        3

      Successful Network Logon:                        Event id：540
        User Name:        zjjia
        Domain:                xxx
        Logon ID:                (0x0,0xD28752)
        Logon Type:        3
        Logon Process:        Kerberos
        Authentication Package:        Kerberos
        Workstation Name:       
        Logon GUID:        {1b450639-51e1-689a-5eb6-072db56ed8a8}
        Caller User Name:        -
        Caller Domain:        -
        Caller Logon ID:        -
        Caller Process ID: -
        Transited Services: -
        Source Network Address:        10.2.211.5
        Source Port:        27306

回答：根据您的描述，我对这个问题的理解是：您想了解如何着手解决账户锁定的问题。

如何排查账户锁定
一、 准备工作：您看到的文章来自活动目录seo http://gnaw0725.blog.51cto.com/156601/d-1

1. 域控制器层面：

（1） 确保您已经利用Default Domain Controllers
Policy在您的域控制器上开启了如下图所示的审核策略，如果您是初次设定此策略，请在域控制器上运行"gpupdate /force"以刷新设置：

（2） 确认所有域控制器上的安全日志大小合适（比如150MB），并且配置是“按需要改写日志”：

（3） 确认您已经在您的域控制器上打开了Netlogon.log，此日志有助于您将来排查NTLM验证来源：

Value Path: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value Name: DBFlag
Value Type: REG_SZ
Value Data: 0x2080FFFF

Output: %windir%\debug\netlogon.log您看到的文章来自活动目录seo http://gnaw0725.blog.51cto.com/156601/d-1

参考：KB 109626 Enabling debug logging for the Net Logon service
http://support.microsoft.com/default.aspx?scid=kb;EN-US;109626

二、 排查阶段：

1． 请先确认发生问题的用户账户名，通常情况下，如果此用户不是一直被锁定，对排查来讲可能就没有什么实际的意义。所以请先确认问题是否总是发生，比如连续几次解除锁定后，又总是被再次锁定。

2． 确认完目标用户账户后，请在域中的任何一台工作站上（比如您的工作机），将附件中的LockoutStatus.zip工具放到桌面，运行（注意，如果您的当前登录账户不是域管理员，您需要输入一个有权限的用户凭据来访问目标用户账户的登录失败信息），输入目标账户名，登录失败的信息即显示在输出中（在本例中，testuser是一个被锁定的账户）

3. 从输出中，您可以容易的发现是哪台DC接收到了失败的凭据与一些相关详细信息。对排查来讲，我们需要定位到是哪一台DC接收到了错误的凭据，然后到此DC上进行安全日志的分析。

4. 请前往定位到的DC，保存安全日志为.evt文件，保存Netlogon.log和Netlogon.bak到备份地点，开始分析。

5. 在安全日志中，经过条件过滤，您应该能够发现以下信息：您看到的文章来自活动目录seo http://gnaw0725.blog.51cto.com/156601/d-1

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 675
Date: 6/22/2007
Time: 3:24:13 PM
User: NT AUTHORITY\SYSTEM
Computer: DC2003
Description:
Pre-authentication failed:
User Name: TestUser
User ID: DOMAIN2003\TestUser
Service Name: krbtgt/domain2003
Pre-Authentication Type: 0x2
Failure Code: 0x18
Client Address: 172.16.0.123

Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 644
Date: 6/22/2007
Time: 3:24:16 PM
User: NT AUTHORITY\SYSTEM
Computer: DC2003
Description:
User Account Locked Out:
Target Account Name: TestUser
Target Account ID: DOMAIN2003\TestUser
Caller Machine Name: XP1
Caller User Name: DC2003$
Caller Domain: DOMAIN2003
Caller Logon ID: (0x0,0x3E7)

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 539
Date: 6/22/2007
Time: 3:24:18 PM
User: NT AUTHORITY\SYSTEM
Computer: DC2003
Description:
Logon Failure:
Reason: Account locked out
User Name: testuser
Domain: domain2003
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: XP1
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 172.16.0.123

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 680
Date: 6/22/2007
Time: 3:24:18 PM
User: NT AUTHORITY\SYSTEM
Computer: DC2003
Description:
Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: testuser
Source Workstation: XP1
Error Code: 0xC0000234 （STATUS_ACCOUNT_LOCKED_OUT）

由于在测试的环境中只是一个简单的情况，所以您很容易发现TestUser的无效凭据来源于一台叫XP1的客户机，IP地址是172.16.0.123。现实环境中，您需要仔细分析安全日志，查找无效凭据的来源与尝试的次数，往往用户账户的锁定是由于连续的无效凭据导致。日志分析的过程是无法用任何程序简单代替的。

6. 如果您发现是NTLM验证方式，您可以再次研究Netlogon.log。请将附件中的Nlparse.zip工具释放，用它读取您保存的Netlogon.log：您看到的文章来自活动目录seohttp://gnaw0725.blog.51cto.com/156601/d-1

然后点击“Extract”，会生成Netlogon.log-Out.csv文件，打开此文件，您会发现有如下信息被记录：

06/22 ,15:24:15,SamLogon: Network logon,domain2003\testuser,XP1,0xC000006A
06/22 ,15:24:16,SamLogon: Network logon,domain2003\testuser,XP1,0xC000006A
06/22 ,15:24:17,SamLogon: Network logon,domain2003\testuser,XP1,0xC000006A
06/22 ,15:24:18,SamLogon: Network logon,domain2003\testuser,XP1,0xC0000234

不难看出，无效凭据来自XP1计算机，连续尝试三次无效密码后，账户被锁定。于是，您就能够确定导致TestUser被锁定的原因是XP1在连续尝试无效密码。

三、 目标计算机诊断阶段：

在定位到目标计算机后，要再次深入定位是什么在发送无效凭据往往是相当困难的。如果问题紧急，我们通常直接将定位到的目标计算机离线以防止其将重要账户锁定。当然，您可以检查一下
已知的一些常见原因：

Applications
---------------------------
Many applications will cache credentials or keep active threads with credentials after a change in password resulting in the old password continuing to be used.您看到的文章来自活动目录seohttp://gnaw0725.blog.51cto.com/156601/d-1

Service Accounts
-----------------------------------
Service Account passwords are cached by Service Control Manager (SCM) on member computers and domain controllers in the forest. Resetting the password for a service account without resetting the password in SCM will cause account lockouts of the service account. Look for a pattern in Netlogon and event logs from individual clients as they retry logon authentication using the previous password.

Bad Password Threshold set too low
---------------------------------------------
This is probably the most common configuration issue. Many organizations have the setting at three or five attempts. By keeping this value too low, erroneous lockouts will take place. The recommended value for this policy setting is ten.

User logging on to multiple machines
-----------------------------------------------------
If a user is concurrently logged on to multiple computers, the threads of network applications running on those computers may run in the context of that locally logged on user when accessing resources in the domain. If this user changes his/her password on one of the computers, applications running on the other computers will still use the original password. As those applications authenticate when accessing network resources, the old password is still being used, and the user’s account becomes locked. When changing the password, log off from all consoles including
Terminal Service sessions, change the password from a single console, and log off there as well.您看到的文章来自活动目录seohttp://gnaw0725.blog.51cto.com/156601/d-1

Scheduled Tasks
--------------------------------------
Scheduled processes may have been configured to start using credentials that have since expired.

Persistent Drive mappings
---------------------------------------------
Persistent drives may have been mapped using credentials that have since expired. The simplest way to ensure current credentials are used is to cancel and re-establish the mapping. Persistent Net Use shares are often the cause of users locking themselves out accidentally. When explicit credentials are entered while connecting to a share, the credential is not persistent unless it is explicitly saved in Stored User Names and Passwords, whereas the mapping is consistent. Every time the user logs off, logs on, or reboots, Windows attempts to restore the connection, and the authentication attempt fails because there are no stored credentials. This increments the badPwdCount attribute. To avoid this problem,
configure Net Use not to make connections persistent. To do this, type net use /persistent:no at a command prompt.

Disconnected Terminal Server sessions
-------------------------------------------
Disconnected sessions may be running a process that is using credentials or a mapped drive. A disconnected session can have the exact same effect as a user with multiple interactive logons. The only difference is the source of the lockout comes from a Terminal Server.您看到的文章来自活动目录seo http://gnaw0725.blog.51cto.com/156601/d-1

Service Accounts
-----------------------------------------
By default, many computer services are configured to start/log on using the “Local System” account. However, a service logon account can be manually configured to log on using a specific user account/password. If a service is configured to start with a specific user account and that user later changes his/her password, the service logon property will need to be updated with the new password or that service may lock out that users account.

同时，您也可以检查是否是以下KB文档中提及的已知情况：

KB 841075 Trying to connect to a share via the "Run" command of the Explorer can lead to an account lockout.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;841075

无效凭据的来源相当广泛，并往往不限于Microsoft的产品，所以排查的过程往往也有相当的难度并且也是无法利用程序或脚本来取代的。

详细资料
以上内容为您提供了一个排查的例子，如果您需要Troubleshooting Account Lockout更为详细的资料，请阅读附件中提供的Troubleshooting Account Lockout.zip文档。此文档提供了迄今为止最为详尽的Account Lockout参考资料与排查方法，相信会成为您诊断Account Lockout问题的最佳文档。您看到的文章来自活动目录seohttp://gnaw0725.blog.51cto.com/156601/d-1

其他信息
Account Lockout 不是用来保护用户账户安全性的最佳做法，使用密码复杂性策略或Smart Card等方式才是更为安全，有效的保护用户账户安全性的方法。同时，如果您的账户锁定阀值设定得太低，比如10次以下，那么您有可能面对大量的用户账户锁定问题而被迫在其上花费大量的时间与精力。根据Windows Server 2003 Security Guide，如果您决定使用Account Lockout，请参考以下推荐的设定：

Setting Legacy Client Enterprise Client Specialized Security - Limited Functionality
Account lockout duration 30 minutes 30 minutes 15 minutes
Account lockout threshold 50 invalid login attempts 50 invalid login attempts 10 invalid login attempts
Reset account lockout counter after 30 minutes 30 minutes 15 minutes

参考链接：http://www.microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/s3sgch03.mspx