An account was locked out...



  • I got this email from our SBS 2003 server this morning:

    <font size="2">Alert on SERVER at 24/11/2008 9:56:24 AM

    An account was locked out due to multiple failed logon attempts that
    occurred in a short period of time. This may occur if an unauthorized user
    attempts to gain access to the network.

    For more information about this event, see the event logs on the server
    computer.

    You can disable this alert by using the Change Alert Notifications task in
    the Server Management Monitoring and Reporting taskpad.</font>

    Why couldn't it tell me which account was locked out? The error the user was getting was "your password has expired" but offered no way to change it: this was the same error both before and after this time. Had to reboot several times and reset password to get him back on.

    Another WTF was when scrolling through the events log (sorted by Event Id, looking for 539) every time it tried to display 539 it would jump to the top of the thousands of id 538 for some reason.



  • Probably because email transport tends to be unencrypted, and they figure you don't want your server spouting out the names of accounts on the box, much the same way you wouldn't send a credit card number or SSN via email.



  • @Zemm said:

    Why couldn't it tell me which account was locked out?

    It could tell you, but then it would have to kill you!


    @Zemm said:

    Another WTF was when scrolling through the events log (sorted by Event Id, looking for 539) every time it tried to display 539 it would jump to the top of the thousands of id 538 for some reason.

    You want event ID 539?  YOU CAN'T HANDLE event ID 539!


  • @DaveK said:

    It could tell you, but then it would have to kill you!
    @DaveK said:
    You want event ID 539?  YOU CAN'T HANDLE event ID 539!

    Did you at least brush the cobwebs off those old jokes before you posted them?



  • SBS 2003 is notorious for those mails. For me the most annoying one (as it's the one I get most) is the NT Backup failed. Why bother attaching the log? At least backup exec will let you mail the log, as long as the customer wants to shell out the couple hundred bucks for it (though we've made it pretty much mandatory nowadays, if they want to buy a server from us, and they want us to be their techsupport)

     Two other gripes I have, though that's probably the same on Server as on SBS:

    - Log in after an unexpected shutdown -> "I've rebooted. Please tell me why?" -> "I wouldn't know. Maybe, if you'd let me log in first I could find out..."

    - More often than not, I want to see every item in eventvwr, except for the one that's in there a gazzillion times drowning out the rest (I fixed that one, what else is there to do?) Wait, I'll filter it out. Hmm, can only filter stuff 'in'...Sigh, sort by ID it is, never mind chronology or root-causes...



  • @db2 said:

    Probably because email transport tends to be unencrypted, and they figure you don't want your server spouting out the names of accounts on the box, much the same way you wouldn't send a credit card number or SSN via email.
     

    It sends me usernames in other emails, like the Server Performance Report. This morning the locked out user's username was in that report. It would have been nice to get the username in the initial email so we can investigate. I was aware of the user's woes but as the boss also gets these notifications he was concerned. (I'm mostly a Linux admin/web dev but have to dabble in the SBS for the email and FileMaker)

    Besides, a username is no where as sensitive as a SSN, TFN or CC number.



  • @Zemm said:

    It sends me usernames in other emails, like the Server Performance Report. This morning the locked out user's username was in that report. It would have been nice to get the username in the initial email so we can investigate. I was aware of the user's woes but as the boss also gets these notifications he was concerned. (I'm mostly a Linux admin/web dev but have to dabble in the SBS for the email and FileMaker)

    Besides, a username is no where as sensitive as a SSN, TFN or CC number.

    Oh, so it's just another case of Microsoft's left hand not knowing what the right one is doing, as per usual. And a username can be fairly useful information, as it greatly increases the chances of password cracking and social engineering. Though whether anybody would be doing anything that sensitive on SBS is probably debatable.



  • @pnieuwkamp said:

    - Log in after an unexpected shutdown -> "I've rebooted. Please tell me why?" -> "I wouldn't know. Maybe, if you'd let me log in first I could find out..."
    Destruction with Sledgehammer (unplanned)



  • @pnieuwkamp said:

    Two other gripes I have, though that's probably the same on Server as on SBS:

    - Log in after an unexpected shutdown -> "I've rebooted. Please tell me why?" -> "I wouldn't know. Maybe, if you'd let me log in first I could find out..."

    Windows Server 2008 fixed that crap...

     



  • Account lockouts happen quite easily if you have the same user name on different domains (or even a local account with the same user name as a domain account) with different passwords. You see, when you double-click on a network resource,Windows will hammer the server with the current credentials until your account is locked out, then ask you for different credentials. Increasing the allowed number of failures before lockout would probably fix that, but it's not my decision.



  • @bstorer said:

    @DaveK said:

    It could tell you, but then it would have to kill you!
    @DaveK said:
    You want event ID 539?  YOU CAN'T HANDLE event ID 539!

    Did you at least brush the cobwebs off those old jokes before you posted them?

    Ahhh, enough with your moaning.  If I hadn't dug those up, it wouldn't have exposed the geological layer below where you got that office/orifice joke from!


  • @DaveK said:

    Ahhh, enough with your moaning.  If I hadn't dug those up, it wouldn't have exposed the geological layer below where you got that office/orifice joke from!
    At least I responded to a related orifice joke.  You just went with references, apropos of nothing, that were last culturally relevant sometime before the Pliocene epoch.  What's the matter, couldn't work in "where's the beef?"  A note for the future: if you're going to drop non sequitors, have the decency not to crib from 15-year-old Jay Leno monologues.



  • @bstorer said:

    @DaveK said:

    Ahhh, enough with your moaning.  If I hadn't dug those up, it wouldn't have exposed the geological layer below where you got that office/orifice joke from!
    At least I responded to a related orifice joke.  You just went with references, apropos of nothing

    So you didn't get that "It could tell you but then ..." was a subtle way of saying - by allusion - "It doesn't want to send security-sensitive information over an insecure channel"?


  • @DaveK said:

    So you didn't get that "It could tell you but then ..." was a subtle way of saying - by allusion - "It doesn't want to send security-sensitive information over an insecure channel"?

    The jokes were rather old and worn out, but still funnier than the constant garbage that morbiuswilters is spewing all over the threads.



    Not by much mind you... but at least a tiny bit.



  • @DaveK said:

    So you didn't get that "It could tell you but then ..." was a subtle way of saying - by allusion - "It doesn't want to send security-sensitive information over an insecure channel"?
    Fine, fine.  I retract the "apropos of nothing" part in response to the tenuous evidence you provide to the contrary.  What say we table this and get to work on some new material?



  • @bstorer said:

    What say we table this and get to work on some new material?

    I have to ask... Are you the humor police, and have you somehow found a way to ignore the more annoying forum members like morbiuswilters?



  • @DaveK said:

    So you didn't get that "It could tell you but then ..." was a subtle way of saying - by allusion - "It doesn't want to send security-sensitive information over an insecure channel"?
     

    And kill everyone else who may have eavesdropped?

    If someone gets into my mailbox I think the server is already r00ted. It's a fricken SBS box: everything on the one server! There's only 6 users so it wasn't hard to track down, but anyway...


Log in to reply