Results 1 to 6 of 6

Thread: failed login auditing

  1. #1
    Join Date
    Mar 2004

    failed login auditing


    I have been recently been given the responsibility of securing our servers (and all computers in general). The prior administrator had little to no documentation on how things were done and what he has done. I want to methodically go thru the servers and see what needs to be done to make them more secure.

    My background is primarily in hardware repair and network troubleshooting.

    Anyway, I glanced over at a thread that Angelic Knight (sorry about the spelling) had posted and I read thru some of the things he has been going thru. I do know that we have no auditing of any failed login attempts and I would like to set that up and then, of course, see what else I need to do and tackle those things.

    About the evil servers: Three win2k servers that use terminal services. We use active directory, which I have some knowledge but not enough to set up auditing properly. I did use Google (the almighty) and found some help, but it does not seem to be auditing failed (or even successful) logins. I have tried to login both remotely and locally to the server and it is not auditing.

    I turned on auditing thru
    Active directory -> right click on the domain and choose properties ->default domain policy ->
    -- Edit -> computer configuration -> windows -> security -> local policies -> audit policy.

    I turned on auditing in Audit account logon events to both failed and success
    I turned on auditing in Audit logon events to both failed and success.

    I then check event viewer after I try to logon with a valid account and bad password and valid account and good password and no events posted.

    I searched around Google some more and found a reference to the msc on the server called
    gpedit.msc. When I go in there to the same place I see that there are three columns for each event. The first column is the policy, the 2nd is Local and the 3rd is Effective. Local is set for Failure and Effective is set for No Auditing.

    According to what I can find, the Effective is based on the domain group policy. I thought I was in the domain group policy thru the Active Directory, but this is incorrect or it would be working.

    Any ideas on where to go from here? Thanks much for any help!


  2. #2
    Join Date
    Mar 2004

    well, I got it working by adding a new policy in the domain policy properties to audit logging. I then had to check the NO OVERRIDE and it works.

    however, I'm scratching my head as to why I had to do it this way instead on editing the current policy... which means the current policy is not the the MAIN policy being applied. Any AD experts care to help me out as to how to find which may be the main policy or backtrack to find where it may be ?

    Thanks much again.


    .: edited because I can't type sometimes.

  3. #3
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    You may have simply been a tad impatient and now believe that the no override was the solution.

    No override is used when you have OU's beneath a domain or sub-OU's beneath an OU and you don't want the policy to be overridden by anyone. It's usually used when you delegate control of an OU to someone other than yourself but there are things you don't want them to be able to change.

    With regard to the policy not taking effect immediately there is a setting for policy refresh which, IIRC, has a default of 30 minutes. Thus machines that were already running with policy A may not have discovered that the policy changed to B for as much as 30 minutes. AD often takes a while for changes to kick in.... You can force an immediate refresh but I think that applies only to the machine you are at. I don't think you can force it down the tree from a controller.

    As an aside, you don't want to go making the policy refresh time something like 2 minutes because it will have a detrimental effect on neywrok performance.... All your machine have to generate all the addidional traffic to see if the policy has changed.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  4. #4
    Join Date
    Mar 2004
    Thanks Tiger,

    I will let it go the way it is for now. Tonight when less users are on I will disable the new policy that was created and see what happens when I set up the auditing and wait a bit. I will try to find out where the refresh time is and see what it is set up. I agree that having a quick refresh time (under 30 minutes) would create needless network traffic.


  5. #5
    Senior Member
    Join Date
    Mar 2004
    Hi if you are new to AD administration and Group Policy in particular, I pass the following books
    around that seem to be helpful.

    1. Mastering Active Directory Visually - ISBN 0-7645-3425-4
    2. Admin 911 - Windows 2000 Group Policy - ISBN 0-07-212948-4

    They are a nice compliment to the Standard Docs, White Papers, and Win2k resource kit.

    Good points Tiger..

    Also make sure you take into consideration what the roll of the DC is.
    Making changes to the Global Catalog can speed up the replication of changes

    To force a sync, you can use the repadimin command with the /sync switch.
    Tool is found in the recource kit IIRC

  6. #6
    Senior Member
    Join Date
    Nov 2001
    after you get all the logging set up the way you want, maybe this will make your like a little easier:

    Bukhari:V3B48N826 “The Prophet said, ‘Isn’t the witness of a woman equal to half of that of a man?’ The women said, ‘Yes.’ He said, ‘This is because of the deficiency of a woman’s mind.’”

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts