AD域帐号被锁问题排查

今天碰到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-11. 域控制器层面：（1） 确保您已经利用Default Domain Controllers Policy在您的域控制器上开启了如下图所示的审核策略，如果您是初次设定此策略，请在域控制器上运行"gpupdate /force"以刷新设置：（2） 确认所有域控制器上的安全日志大小合适（比如150MB），并且配置是“按需要改写日志”：（3） 确认您已经在您的域控制器上打开了Netlogon.log，此日志有助于您将来排查NTLM验证来源：Value Path: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\ParametersValue Name: DBFlagValue Type: REG_SZValue Data: 0x2080FFFFOutput: %windir%\debug\netlogon.log您看到的文章来自活动目录seo http://gnaw0725.blog.51cto.com/156601/d-1参考：KB 109626 Enabling debug logging for the Net Logon servicehttp://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-1Event Type: Failure AuditEvent Source: SecurityEvent Category: Account Logon Event ID: 675Date: 6/22/2007Time: 3:24:13 PMUser: NT AUTHORITY\SYSTEMComputer: DC2003Description:Pre-authentication failed:User Name: TestUserUser ID: DOMAIN2003\TestUserService Name: krbtgt/domain2003Pre-Authentication Type: 0x2Failure Code: 0x18Client Address: 172.16.0.123Event Type: Success AuditEvent Source: SecurityEvent Category: Account Management Event ID: 644Date: 6/22/2007Time: 3:24:16 PMUser: NT AUTHORITY\SYSTEMComputer: DC2003Description:User Account Locked Out:Target Account Name: TestUserTarget Account ID: DOMAIN2003\TestUserCaller Machine Name: XP1Caller User Name: DC2003$Caller Domain: DOMAIN2003Caller Logon ID: (0x0,0x3E7)Event Type: Failure AuditEvent Source: SecurityEvent Category: Logon/Logoff Event ID: 539Date: 6/22/2007Time: 3:24:18 PMUser: NT AUTHORITY\SYSTEMComputer: DC2003Description:Logon Failure:Reason: Account locked outUser Name: testuserDomain: domain2003Logon Type: 3Logon Process: NtLmSsp Authentication Package: NTLMWorkstation Name: XP1Caller User Name: -Caller Domain: -Caller Logon ID: -Caller Process ID: -Transited Services: -Source Network Address: 172.16.0.123Event Type: Failure AuditEvent Source: SecurityEvent Category: Account Logon Event ID: 680Date: 6/22/2007Time: 3:24:18 PMUser: NT AUTHORITY\SYSTEMComputer: DC2003Description:Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0Logon account: testuserSource Workstation: XP1Error Code: 0xC0000234 （STATUS_ACCOUNT_LOCKED_OUT）由于在测试的环境中只是一个简单的情况，所以您很容易发现TestUser的无效凭据来源于一台叫XP1的客户机，IP地址是172.16.0.123。现实环境中，您需要仔细分析安全日志，查找无效凭据的来源与尝试的次数，往往用户账户的锁定是由于连续的无效凭据导致。日志分析的过程是无法用任何程序简单代替的。6. 如果您发现是NTLM验证方式，您可以再次研究Netlogon.log。请将附件中的Nlparse.zip工具释放，用它读取您保存的Netlogon.log：您看到的文章来自活动目录seo http://gnaw0725.blog.51cto.com/156601/d-1然后点击“Extract”，会生成Netlogon.log-Out.csv文件，打开此文件，您会发现有如下信息被记录：06/22 ,15:24:15,SamLogon: Network logon,domain2003\testuser,XP1,0xC000006A06/22 ,15:24:16,SamLogon: Network logon,domain2003\testuser,XP1,0xC000006A06/22 ,15:24:17,SamLogon: Network logon,domain2003\testuser,XP1,0xC000006A06/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.您看到的文章来自活动目录seo http://gnaw0725.blog.51cto.com/156601/d-1Service 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.您看到的文章来自活动目录seo http://gnaw0725.blog.51cto.com/156601/d-1Scheduled 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-1Service 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问题的最佳文档。您看到的文章来自活动目录seo http://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.mspxJason Hou 侯铮 微软全球技术支持中心AD域帐号被锁问题排查的相关文章请参考大量AD域帐号自动被锁定域账户锁定活动目录账户不断锁定windows AD域帐号锁定组策略AD域帐号被锁问题排查如何批量解锁AD域帐户---gnaw0725本文出自 “gnaw0725博客” 博客，请务必保留此出处http://gnaw0725.blog.51cto.com/156601/668123