none
Failed logon attempts to domain are being logged on local workstations but not on Domain Controllers

    Question

  • I have two domain controllers in a single domain environment.  One DC is W2K3 SP2 the other is Windows 2008 R2.  I am attempting to setup a policy that captures failed login attempts to workstations in the domain (bad user name, bad password, etc).  My current default domain controller policy is as follows:

    Computer > Windows Settings > Security Settings> Local Policies> Audit Policy:

    Audit account logon events: Success, Failure

    Audit account management:  Success, Failure

    Audit logon events:  Success, Failure

    When an invalid login attempt occurs on a workstation in the domain I can see Event 529 logged locally on my XP workstations and I can see Event 4625 logged locally on my Windows 7 PCs.  What I cannot see is anything in the security log on the domain controllers.    I am expecting to see these entries in the security log on the DC's.

    Additional research pointed me to the below forum but the end fix in that posting is not my problem:

    http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/9ff2064c-c903-471d-8031-ffcc29a12345

    What am I missing here?




    Tuesday, September 18, 2012 2:28 PM

Answers

  • The audit policies have been applied to the 2003 DC successfully, it should log corresponding events with Account Logon Category:

    675 Failure Audit (Kerberos authentication)

    680 Failure Audit(NTLM authentication)

    672 Success Audit

    Logon and Account Logon are different behavior. Account logon events refers authencation process and are generated only in the authenticating domain controller's Security log, and logon events are generated on the clients where users are logging to. For example, if a user logged to a XP workstation and located the 2003 DC for authentication but failed, event 675 with Account Logon category will be logged on the 2003 DC, but event 529 is the XP workstation's Security log.

    Using "set L" to check logonserver, we can determine which domain controller did authenticate the currently logon user's identity. Make sure to find a workstation and its logon server is the 2003 DC, check if there is 672 in the 2003 DC's security log. Or logoff and intentionally type incorrect password, check if 675 is logged on the 2003 DC.

    Regards

    Diana


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, September 26, 2012 8:23 AM

All replies

  • Are the users logging on to the domain or to the local workstation?
     
    In addition, you might check
     
    regards, Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Tuesday, September 18, 2012 8:01 PM
  • All users are logging on to the domain.

    After following your post and the post below I was able to get the auditing working on my 2008 R2 DC.  

    http://social.technet.microsoft.com/Forums/en/winserverDS/thread/0486c801-8980-4afa-8fee-8cc1409c3ee2

    It appears that once the Advanced Auditing is enabled it breaks the legacy auditing policies.   Following the guidelines in the above reference address it wasn't that painful.  

    However The auditing is still not working on the 2K3 SP2 DC. I ran rsop.msc on the 2K3 SP2 DC and it shows its using the Default Domain Controller Policy.  


    Tuesday, September 18, 2012 9:40 PM
  •  
    > However The auditing is still not working on the 2K3 SP2 DC. I ran
    > rsop.msc on the 2K3 SP2 DC and it shows its using the Default Domain
    > Controller Policy.
     
    What retention method is configured for the security event log?
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Wednesday, September 19, 2012 6:50 AM
  • Hi,

    Have you checked your Windows 2003 DC's event viewer for 529 events? If there are users authenticated by the DC, by default, the event will be logged on the DC.

    Log on events are auditted by default.

    Regards,

    Yan Li

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Yan Li

    TechNet Community Support

    Wednesday, September 19, 2012 9:05 AM
  • The security log maxes out at 19MB and is set to overwrite as needed.
    Friday, September 21, 2012 7:33 PM
  • Event 529 is NOTbeing logged in the DC security event log when a domain client workstation fails log on attempt.

    Event 4625 IS being logged on my 2K8R2 DC but no 529 on the 2003 SP2 DC.

    This all stopped working when I enabled an advanced auditing policy.  See my above post and it shows that I had to back out the changes and that resolved the issue on the 2K8R2 DC but still no 529's on the 2003 DC. 

    I have also verified that I have workstation using the 2003 DC as its logonserver.

    Friday, September 21, 2012 7:35 PM
  •  
    > Event 529 is NOTbeing logged in the DC security event log when a
    > domain client workstation fails log on attempt.
    >
     
    These events are only logged at the one DC that handles the current
    logon request. So if there's more than one DC in the current site, it's
    quite ok to see events on only one of them.
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Friday, September 21, 2012 8:19 PM
  • Am 21.09.2012 21:33, schrieb JoshuaThompson:
    > The security log maxes out at 19MB and is set to overwrite as needed.
     
    That's not really big... We have configured them to 128 megs... And that
    usually lasts for about 2 days at max.
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Friday, September 21, 2012 8:20 PM
  • In my environment this gives me 5 days of history so I do feel that the event is being overwritten.

    Friday, September 21, 2012 8:22 PM
  •  
    > Event 529 is NOTbeing logged in the DC security event log when a
    > domain client workstation fails log on attempt.
    >
     
    These events are only logged at the one DC that handles the current
    logon request. So if there's more than one DC in the current site, it's
    quite ok to see events on only one of them.
     
    By using the %logonserver% environment variable (echo %logonserver%) I can tell who is using which logonserver.  I then test on the appropriate clients.
    Friday, September 21, 2012 9:19 PM
  • Hi,

    Log on events are auditted by default, the event would be logged on DCs, if you users are find your Windows 2003 DC to authenticate, then the log will be found in it.

    If you want to know which DC are the user used to authenticate, we could run below code in CMD:

    set logonserver

    Regards,

    Yan Li

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Yan Li

    TechNet Community Support

    Monday, September 24, 2012 5:51 AM
  • Hi,

    Log on events are auditted by default, the event would be logged on DCs, if you users are find your Windows 2003 DC to authenticate, then the log will be found in it.

    If you want to know which DC are the user used to authenticate, we could run below code in CMD:

    set logonserver

    Regards,

    Yan Li

    Thanks for the reply.   As mentioned before this auditing was working before on both DC's (2K8 R2 and 2003)  before I enabled group policy settings under the Computer > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration.  As soon as I enabled some of these options it broke (did not enforce) all the legacy settings as set in Computer > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy.  

    I was able to back out the Advanced Audit Policy Configuration settings by using the information in the Answer in the below posting.  Once I followed the instructions the events starting logging again on my 2008 R2 Domain Controller.

    http://social.technet.microsoft.com/Forums/en/winserverDS/thread/0486c801-8980-4afa-8fee-8cc1409c3ee2

    But events on the 2003 SP2 DC never started back up again.

      

    Monday, September 24, 2012 6:08 PM
  • Yes, by default Advanced Audit Policy settings overwrite basic audit policies if you enable Advanced Audit Policy setting. On the 2003 SP2 DC, run "gpresult /v >gpresult.txt" and then paste the output here, let's check the audit policy applying result.

    Regards

    Diana 


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, September 25, 2012 9:43 AM
  • Yes, by default Advanced Audit Policy settings overwrite basic audit policies if you enable Advanced Audit Policy setting. On the 2003 SP2 DC, run "gpresult /v >gpresult.txt" and then paste the output here, let's check the audit policy applying result.

    Regards

    Diana 

    Here is a audit policy portion of the output

    Audit Policy
            ------------
                GPO: Default Domain Controllers Policy
                    Policy:            AuditPolicyChange
                    Computer Setting:  Success

                GPO: Default Domain Controllers Policy
                    Policy:            AuditPrivilegeUse
                    Computer Setting:  No Auditing

                GPO: Default Domain Controllers Policy
                    Policy:            AuditDSAccess
                    Computer Setting:  Failure

                GPO: Default Domain Controllers Policy
                    Policy:            AuditAccountLogon
                    Computer Setting:  Success, Failure

                GPO: Default Domain Controllers Policy
                    Policy:            AuditObjectAccess
                    Computer Setting:  Success, Failure

                GPO: Default Domain Controllers Policy
                    Policy:            AuditAccountManage
                    Computer Setting:  Success, Failure

                GPO: Default Domain Controllers Policy
                    Policy:            AuditLogonEvents
                    Computer Setting:  Failure

                GPO: Default Domain Controllers Policy
                    Policy:            AuditProcessTracking
                    Computer Setting:  No Auditing

                GPO: Default Domain Controllers Policy
                    Policy:            AuditSystemEvents
                    Computer Setting:  Success, Failure

    If I force a failed logon attempt locally on the 2003 SP2 Domain Controller the Event 529 is logged.  However failed logon attempts form workstations are not.

    If you need more of the output please let me know. For security reasons I would prefer not to expose too much information.


    Tuesday, September 25, 2012 2:19 PM
  • The audit policies have been applied to the 2003 DC successfully, it should log corresponding events with Account Logon Category:

    675 Failure Audit (Kerberos authentication)

    680 Failure Audit(NTLM authentication)

    672 Success Audit

    Logon and Account Logon are different behavior. Account logon events refers authencation process and are generated only in the authenticating domain controller's Security log, and logon events are generated on the clients where users are logging to. For example, if a user logged to a XP workstation and located the 2003 DC for authentication but failed, event 675 with Account Logon category will be logged on the 2003 DC, but event 529 is the XP workstation's Security log.

    Using "set L" to check logonserver, we can determine which domain controller did authenticate the currently logon user's identity. Make sure to find a workstation and its logon server is the 2003 DC, check if there is 672 in the 2003 DC's security log. Or logoff and intentionally type incorrect password, check if 675 is logged on the 2003 DC.

    Regards

    Diana


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, September 26, 2012 8:23 AM
  • The audit policies have been applied to the 2003 DC successfully, it should log corresponding events with Account Logon Category:

    675 Failure Audit (Kerberos authentication)

    680 Failure Audit(NTLM authentication)

    672 Success Audit

    Logon and Account Logon are different behavior. Account logon events refers authencation process and are generated only in the authenticating domain controller's Security log, and logon events are generated on the clients where users are logging to. For example, if a user logged to a XP workstation and located the 2003 DC for authentication but failed, event 675 with Account Logon category will be logged on the 2003 DC, but event 529 is the XP workstation's Security log.

    Using "set L" to check logonserver, we can determine which domain controller did authenticate the currently logon user's identity. Make sure to find a workstation and its logon server is the 2003 DC, check if there is 672 in the 2003 DC's security log. Or logoff and intentionally type incorrect password, check if 675 is logged on the 2003 DC.

    Regards

    Diana

    Perfect!   Great explanation.    Instead of Unknown username or password it shows PreAuthentication failed, which works for me.

    I verified logonserver then entered wrong passwords from a Locked PC as well as logging on to the PC. Even 675 was recorded each time on the logonserver DC.

    Thanks Diana!  

    Wednesday, September 26, 2012 7:37 PM