Bad Passwords

  • Tom.Thomson (5/26/2011)


    nigel. (5/26/2011)


    Steve,

    Thanks for that question, I'd was not aware of 'loginproperty' until now.

    One question though. I tried to recreate your scenario but always get '1900-01-01 01:00:00.000' as the result. Anyone have any ideas why?

    Maybe you are not running on Windows Server 2003 (or 2008?), or don't have both CHECK_POLICY and CHECK_EXPIRATION enabled?

    Thanks Tom,

    That'll be it. I'm not running on Windows Server.

  • Typos aside, it was a good question. If you read the BOL entry, you couldn't just read the answer, you had to think about what you were reading and deduce the answer. Hope we get more questions like this one. Thanks!

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

  • I also try the command before (from the time I got SQLserver, I certainly logged once with a bad password!) and after doing a new login with a bad password.

    I got "NULL"...

    I tried an other 'property_name' : SELECT LOGINPROPERTY('sa', 'DefaultLanguage');

    I got the right answer...

    It is like I never got my login password wrong, wich is impossible

    Why do I get NULL for the 'property_name' BadPasswordTime with my SQLserver2008?

    I checked CHECK_POLICY and CHECK_EXPIRATION enabled, wich was not checked. How long do I need to wait or do I need to restart SQLserver to work?

  • Carlo Romagnano (5/26/2011)


    In sql2005, I tried with other logins than sa and I get always the following:

    1900-01-01 02:00:00.000

    Step 1: bad password attempt

    Step 2: correct login

    I run the query: SELECT loginproperty('carlo', 'badpasswordtime')

    The result: 1900-01-01 02:00:00.000

    Note the hour 2

    ?????

    Got the same with SQL 2008 R2 running on Windows 2008 R2 Server.

    I'm assuming you're located in Italy, so you're on Central European Summer Time (CEST) = UTC / GMT + 2 hrs.

    Thanks to Tom Thomson's explanation about setting CHECK_POLICY = ON (this should set CHECK_EXPIRATION = ON automatically), I was able to see the date and time of the bad login attempt.

    Thanks,

    Michael

  • michael.kaufmann (5/26/2011)


    Carlo Romagnano (5/26/2011)


    In sql2005, I tried with other logins than sa and I get always the following:

    1900-01-01 02:00:00.000

    Step 1: bad password attempt

    Step 2: correct login

    I run the query: SELECT loginproperty('carlo', 'badpasswordtime')

    The result: 1900-01-01 02:00:00.000

    Note the hour 2

    ?????

    Got the same with SQL 2008 R2 running on Windows 2008 R2 Server.

    I'm assuming you're located in Italy, so you're on Central European Summer Time (CEST) = UTC / GMT + 2 hrs.

    Thanks to Tom Thomson's explanation about setting CHECK_POLICY = ON (this should set CHECK_EXPIRATION = ON automatically), I was able to see the date and time of the bad login attempt.

    Thanks,

    Michael

    Thank you, that's true.

    But the strange thing is that for sa the query returns effectively the right date and time, for the user Carlo, despite the settings, no. :blink:

  • Nice easy question, from experience.

  • Steve,

    I didn't know you had a SQL Server time machine? 2011, then 2010? Will you please use it to see if the Mayans are right for the end of the world next year? 😛

    Fix minutes is how long it takes someone to fix something. Sometimes I'm asked as to how long it will take to fix something (on the very rare occasion where something needs fixing) and I respond "fix minutes". If it takes 2 hours, I report it as 120 fix minutes. So, I knew exactly what Steve was talking about. :hehe:

  • Didn't know about this property, but the answer made sense. Not an easy question, but a logical one.

    More like that please 🙂

    Peter Trast
    Microsoft Certified ...(insert many literal strings here)
    Microsoft Design Architect with Alexander Open Systems

  • Carlo Romagnano (5/26/2011)


    Thank you, that's true.

    But the strange thing is that for sa the query returns effectively the right date and time, for the user Carlo, despite the settings, no. :blink:

    Do you mean that for SA you get e.g. 2011-05-26 14:15:37 and for CARLO you get 1900-01-01 02:00:00?

    The CHECK_POLICY setting has to be enabled for each individual login.

    Regards,

    Michael

  • Apologies on the year. I've corrected that.

    I should have noted this is OS dependent. My apologies for that. From the explanation URL: NULL if the CHECK_POLICY or CHECK_EXPIRATION is OFF for a login, or if the operating system does not support the password policy.

    My suspicion is that NULL is not returned, but the base SQL Server date of 1900-1-1

  • Nice question. I think the answer is logical.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Do you mean that for SA you get e.g. 2011-05-26 14:15:37 and for CARLO you get 1900-01-01 02:00:00?

    Yes, exactly!

  • Steve Jones - SSC Editor (5/26/2011)


    Apologies on the year. I've corrected that.

    I should have noted this is OS dependent. My apologies for that. From the explanation URL: NULL if the CHECK_POLICY or CHECK_EXPIRATION is OFF for a login, or if the operating system does not support the password policy.

    My suspicion is that NULL is not returned, but the base SQL Server date of 1900-1-1

    Now you see how long this question's been in the queue! :w00t::hehe::laugh:

  • Carlo Romagnano (5/26/2011)


    Do you mean that for SA you get e.g. 2011-05-26 14:15:37 and for CARLO you get 1900-01-01 02:00:00?

    Yes, exactly!

    Then I'd assume that CHECK_POLICY has not been enabled for this account. Did you try adjusting the setting for Carlo?

    Regards,

    Michael

  • While, I knew what it was suppose to do, I tested this out on my own box and somehow it wasn't recording the datetime of the bad password attempt??? Not sure what's going on there.

    Anyone else see this?

    Dennis Parks
    MCSE, MCDBA, MCSD, MCAD, MCTS

Viewing 15 posts - 16 through 30 (of 32 total)

You must be logged in to reply to this topic. Login to reply