Neither of the options you have presented are good OO.  If you are writing if statements around the type of an object, you are most likely doing OO wrong (there are exceptions, this isn't one.)  Here's the simple OO answer to your question (may not be valid C#):

<!-- language: c# -->

    interface IAccount {
      bool CanResetPassword();

      void ResetPassword();

      // Other Account operations as needed
    }

    public class Resetable : IAccount {
      public bool CanResetPassword() {
        return true;
      }

      public void ResetPassword() {
        /* RESET PASSWORD */
      }
    }

    public class NotResetable : IAccount {
      public bool CanResetPassword() {
        return false;
      }

      public void ResetPassword() {
        Print("Not allowed to reset password with this account type!");}
      }

I've modified this example to match what the original code was doing.  Based on some of the comments, it seems people are getting hung up on whether this is the 'right' specific code here.  That is not the point of this example.  The whole Polymorphic overloading is essentially to conditionally execute different implementations of logic based on the type of the object.  What you are doing in both examples is hand-jamming what your language gives you as a feature.  In a nutshell you could get rid of the sub-types and put the ability to reset as a boolean property of the Account type (ignoring other features of the sub-types.)

Without a wider view of the design, it's impossible to tell whether this is a good solution for your particular system.  It's simple and if it works for what you are doing, you will likely never need to think much about it again unless someone fails to check CanResetPassword() prior to calling ResetPassword().  You could also return a boolean or fail silently (not recommended).  It really depends on the specifics of the design.