Does changing “sa” password require a SQL restart (in mixed mode)?












12















We discovered a SQL "sa" account being used in a way it should not have been, so we are changing sa passwords on all our SQL instances.



(We have SQL 2005 through 2017 servers running in mixed authentication mode. All users and applications should be using either domain accounts or non-sa SQL accounts to connect. I have been monitoring, but have not found any other apps, users, or non-internal spids using the sa account.)



A few questions:



Q1: Does changing the sa password require a SQL restart?



I found a few references that say a SQL service restart is required after changing the sa account password:




  • DBA SE: Changing sa password

  • SQLAuthority: Change Password of SA Login Using Management Studio


Is that true? Or only if I'm changing the authentication mode? Or only if I routinely log on as sa?



This SQL Server Central thread even suggests changing it could impact existing SQL agent jobs and other stuff; is that a concern? Or only if someone has hard-coded the SA account into an SSIS package or something?



(In case it matters, we use domain accounts for the SQL service and SQL agent service, and domain proxy accounts for jobs that call SSIS packages or PowerShell scripts.)



Q2: Can I change the sa password the "normal" way?



Can I reset it like I would any other account? Using SSMS, or more likely via:



ALTER LOGIN sa WITH PASSWORD = 'newpass';


Or would I have to enter single-user mode or something that would require planned downtime? (Note that I'd be running this from a domain account, not while connected as "sa".)



Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?



Is this a recommended "best practice"?










share|improve this question



























    12















    We discovered a SQL "sa" account being used in a way it should not have been, so we are changing sa passwords on all our SQL instances.



    (We have SQL 2005 through 2017 servers running in mixed authentication mode. All users and applications should be using either domain accounts or non-sa SQL accounts to connect. I have been monitoring, but have not found any other apps, users, or non-internal spids using the sa account.)



    A few questions:



    Q1: Does changing the sa password require a SQL restart?



    I found a few references that say a SQL service restart is required after changing the sa account password:




    • DBA SE: Changing sa password

    • SQLAuthority: Change Password of SA Login Using Management Studio


    Is that true? Or only if I'm changing the authentication mode? Or only if I routinely log on as sa?



    This SQL Server Central thread even suggests changing it could impact existing SQL agent jobs and other stuff; is that a concern? Or only if someone has hard-coded the SA account into an SSIS package or something?



    (In case it matters, we use domain accounts for the SQL service and SQL agent service, and domain proxy accounts for jobs that call SSIS packages or PowerShell scripts.)



    Q2: Can I change the sa password the "normal" way?



    Can I reset it like I would any other account? Using SSMS, or more likely via:



    ALTER LOGIN sa WITH PASSWORD = 'newpass';


    Or would I have to enter single-user mode or something that would require planned downtime? (Note that I'd be running this from a domain account, not while connected as "sa".)



    Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?



    Is this a recommended "best practice"?










    share|improve this question

























      12












      12








      12


      3






      We discovered a SQL "sa" account being used in a way it should not have been, so we are changing sa passwords on all our SQL instances.



      (We have SQL 2005 through 2017 servers running in mixed authentication mode. All users and applications should be using either domain accounts or non-sa SQL accounts to connect. I have been monitoring, but have not found any other apps, users, or non-internal spids using the sa account.)



      A few questions:



      Q1: Does changing the sa password require a SQL restart?



      I found a few references that say a SQL service restart is required after changing the sa account password:




      • DBA SE: Changing sa password

      • SQLAuthority: Change Password of SA Login Using Management Studio


      Is that true? Or only if I'm changing the authentication mode? Or only if I routinely log on as sa?



      This SQL Server Central thread even suggests changing it could impact existing SQL agent jobs and other stuff; is that a concern? Or only if someone has hard-coded the SA account into an SSIS package or something?



      (In case it matters, we use domain accounts for the SQL service and SQL agent service, and domain proxy accounts for jobs that call SSIS packages or PowerShell scripts.)



      Q2: Can I change the sa password the "normal" way?



      Can I reset it like I would any other account? Using SSMS, or more likely via:



      ALTER LOGIN sa WITH PASSWORD = 'newpass';


      Or would I have to enter single-user mode or something that would require planned downtime? (Note that I'd be running this from a domain account, not while connected as "sa".)



      Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?



      Is this a recommended "best practice"?










      share|improve this question














      We discovered a SQL "sa" account being used in a way it should not have been, so we are changing sa passwords on all our SQL instances.



      (We have SQL 2005 through 2017 servers running in mixed authentication mode. All users and applications should be using either domain accounts or non-sa SQL accounts to connect. I have been monitoring, but have not found any other apps, users, or non-internal spids using the sa account.)



      A few questions:



      Q1: Does changing the sa password require a SQL restart?



      I found a few references that say a SQL service restart is required after changing the sa account password:




      • DBA SE: Changing sa password

      • SQLAuthority: Change Password of SA Login Using Management Studio


      Is that true? Or only if I'm changing the authentication mode? Or only if I routinely log on as sa?



      This SQL Server Central thread even suggests changing it could impact existing SQL agent jobs and other stuff; is that a concern? Or only if someone has hard-coded the SA account into an SSIS package or something?



      (In case it matters, we use domain accounts for the SQL service and SQL agent service, and domain proxy accounts for jobs that call SSIS packages or PowerShell scripts.)



      Q2: Can I change the sa password the "normal" way?



      Can I reset it like I would any other account? Using SSMS, or more likely via:



      ALTER LOGIN sa WITH PASSWORD = 'newpass';


      Or would I have to enter single-user mode or something that would require planned downtime? (Note that I'd be running this from a domain account, not while connected as "sa".)



      Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?



      Is this a recommended "best practice"?







      sql-server security best-practices






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked yesterday









      BradCBradC

      6,50763461




      6,50763461






















          2 Answers
          2






          active

          oldest

          votes


















          15















          Q1: Does changing the sa password require a SQL restart?




          No, but changing the authentication mode does. Since you're just changing the password and the authentication mode is already set to mixed, you're good to go with just changing the password.




          Q2: Can I change the sa password the "normal" way?




          Yes, it's just another SQL Login account.




          Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?




          To be quite honest, I would disable and rename the SA login. This way it won't be used, at all and if you need a highly privileged login, then you can make one as needed.






          share|improve this answer
























          • Don't rename it but disabling it is a really good idea.

            – Joshua
            yesterday






          • 2





            @Joshua Renaming it is a good idea, especially if you're being audited or as part of other security practices that may be required as part of a compliance effort.

            – Sean Gallardy
            yesterday






          • 2





            I've spent too much time tracking down broken stuff because somebody renamed a built-in account after it got used.

            – Joshua
            yesterday











          • @Joshua if you renamed and disabled it when you built it that would not be a problem. Of course this is only a going forward solution. Renaming months or years later can be problematic.

            – James Jenkins
            9 hours ago











          • @JamesJenkins: Ah good you're catching on.

            – Joshua
            9 hours ago



















          6














          This is a closing the barn door after the horses already ran off question.



          You should have renamed and disabled the sa account when you built the instance.




          Any time you have a well-known account, like administrator on a Windows system or sa for SQL Server, you should take certain steps to secure it. Let's look at specifically what you should do with sa:



          Set a hard to guess password.



          Rename sa.



          Disable sa.



          Ensure that no other accounts exist named sa.




          Source



          If you are keeping the 'sa' account as an emergency way to get SQL access there are safer ways see: Connect to SQL Server When System Administrators Are Locked Out If you don't have network account access, you have bigger problems then not being able to connect to SQL.






          share|improve this answer





















          • 1





            I can see renaming sa, but wouldn't disabling it entirely prevent me from connecting if domain authentication became unavailable in an emergency? (Not that I can recall ever needing to do so, but I'm trying to anticipate all contingencies.)

            – BradC
            yesterday











          • @BradC edited in update addressing your comment

            – James Jenkins
            yesterday











          • Thanks, we'll consider that for a long-term solution.

            – BradC
            yesterday






          • 1





            It's difficult, if not impossible, to have Integrated Authentication completely stop working since the SQL Server service won't run unless it can log in. You don't need to have an Active Directory domain present to use Windows Integrated Authentication; SQL Server can authenticate you against the local security authority.

            – Max Vernon
            10 hours ago











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "182"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f230303%2fdoes-changing-sa-password-require-a-sql-restart-in-mixed-mode%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          15















          Q1: Does changing the sa password require a SQL restart?




          No, but changing the authentication mode does. Since you're just changing the password and the authentication mode is already set to mixed, you're good to go with just changing the password.




          Q2: Can I change the sa password the "normal" way?




          Yes, it's just another SQL Login account.




          Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?




          To be quite honest, I would disable and rename the SA login. This way it won't be used, at all and if you need a highly privileged login, then you can make one as needed.






          share|improve this answer
























          • Don't rename it but disabling it is a really good idea.

            – Joshua
            yesterday






          • 2





            @Joshua Renaming it is a good idea, especially if you're being audited or as part of other security practices that may be required as part of a compliance effort.

            – Sean Gallardy
            yesterday






          • 2





            I've spent too much time tracking down broken stuff because somebody renamed a built-in account after it got used.

            – Joshua
            yesterday











          • @Joshua if you renamed and disabled it when you built it that would not be a problem. Of course this is only a going forward solution. Renaming months or years later can be problematic.

            – James Jenkins
            9 hours ago











          • @JamesJenkins: Ah good you're catching on.

            – Joshua
            9 hours ago
















          15















          Q1: Does changing the sa password require a SQL restart?




          No, but changing the authentication mode does. Since you're just changing the password and the authentication mode is already set to mixed, you're good to go with just changing the password.




          Q2: Can I change the sa password the "normal" way?




          Yes, it's just another SQL Login account.




          Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?




          To be quite honest, I would disable and rename the SA login. This way it won't be used, at all and if you need a highly privileged login, then you can make one as needed.






          share|improve this answer
























          • Don't rename it but disabling it is a really good idea.

            – Joshua
            yesterday






          • 2





            @Joshua Renaming it is a good idea, especially if you're being audited or as part of other security practices that may be required as part of a compliance effort.

            – Sean Gallardy
            yesterday






          • 2





            I've spent too much time tracking down broken stuff because somebody renamed a built-in account after it got used.

            – Joshua
            yesterday











          • @Joshua if you renamed and disabled it when you built it that would not be a problem. Of course this is only a going forward solution. Renaming months or years later can be problematic.

            – James Jenkins
            9 hours ago











          • @JamesJenkins: Ah good you're catching on.

            – Joshua
            9 hours ago














          15












          15








          15








          Q1: Does changing the sa password require a SQL restart?




          No, but changing the authentication mode does. Since you're just changing the password and the authentication mode is already set to mixed, you're good to go with just changing the password.




          Q2: Can I change the sa password the "normal" way?




          Yes, it's just another SQL Login account.




          Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?




          To be quite honest, I would disable and rename the SA login. This way it won't be used, at all and if you need a highly privileged login, then you can make one as needed.






          share|improve this answer














          Q1: Does changing the sa password require a SQL restart?




          No, but changing the authentication mode does. Since you're just changing the password and the authentication mode is already set to mixed, you're good to go with just changing the password.




          Q2: Can I change the sa password the "normal" way?




          Yes, it's just another SQL Login account.




          Q3: Should we try to do this password rotation on a regular basis? Or only when we find an issue?




          To be quite honest, I would disable and rename the SA login. This way it won't be used, at all and if you need a highly privileged login, then you can make one as needed.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered yesterday









          Sean GallardySean Gallardy

          16.2k22649




          16.2k22649













          • Don't rename it but disabling it is a really good idea.

            – Joshua
            yesterday






          • 2





            @Joshua Renaming it is a good idea, especially if you're being audited or as part of other security practices that may be required as part of a compliance effort.

            – Sean Gallardy
            yesterday






          • 2





            I've spent too much time tracking down broken stuff because somebody renamed a built-in account after it got used.

            – Joshua
            yesterday











          • @Joshua if you renamed and disabled it when you built it that would not be a problem. Of course this is only a going forward solution. Renaming months or years later can be problematic.

            – James Jenkins
            9 hours ago











          • @JamesJenkins: Ah good you're catching on.

            – Joshua
            9 hours ago



















          • Don't rename it but disabling it is a really good idea.

            – Joshua
            yesterday






          • 2





            @Joshua Renaming it is a good idea, especially if you're being audited or as part of other security practices that may be required as part of a compliance effort.

            – Sean Gallardy
            yesterday






          • 2





            I've spent too much time tracking down broken stuff because somebody renamed a built-in account after it got used.

            – Joshua
            yesterday











          • @Joshua if you renamed and disabled it when you built it that would not be a problem. Of course this is only a going forward solution. Renaming months or years later can be problematic.

            – James Jenkins
            9 hours ago











          • @JamesJenkins: Ah good you're catching on.

            – Joshua
            9 hours ago

















          Don't rename it but disabling it is a really good idea.

          – Joshua
          yesterday





          Don't rename it but disabling it is a really good idea.

          – Joshua
          yesterday




          2




          2





          @Joshua Renaming it is a good idea, especially if you're being audited or as part of other security practices that may be required as part of a compliance effort.

          – Sean Gallardy
          yesterday





          @Joshua Renaming it is a good idea, especially if you're being audited or as part of other security practices that may be required as part of a compliance effort.

          – Sean Gallardy
          yesterday




          2




          2





          I've spent too much time tracking down broken stuff because somebody renamed a built-in account after it got used.

          – Joshua
          yesterday





          I've spent too much time tracking down broken stuff because somebody renamed a built-in account after it got used.

          – Joshua
          yesterday













          @Joshua if you renamed and disabled it when you built it that would not be a problem. Of course this is only a going forward solution. Renaming months or years later can be problematic.

          – James Jenkins
          9 hours ago





          @Joshua if you renamed and disabled it when you built it that would not be a problem. Of course this is only a going forward solution. Renaming months or years later can be problematic.

          – James Jenkins
          9 hours ago













          @JamesJenkins: Ah good you're catching on.

          – Joshua
          9 hours ago





          @JamesJenkins: Ah good you're catching on.

          – Joshua
          9 hours ago













          6














          This is a closing the barn door after the horses already ran off question.



          You should have renamed and disabled the sa account when you built the instance.




          Any time you have a well-known account, like administrator on a Windows system or sa for SQL Server, you should take certain steps to secure it. Let's look at specifically what you should do with sa:



          Set a hard to guess password.



          Rename sa.



          Disable sa.



          Ensure that no other accounts exist named sa.




          Source



          If you are keeping the 'sa' account as an emergency way to get SQL access there are safer ways see: Connect to SQL Server When System Administrators Are Locked Out If you don't have network account access, you have bigger problems then not being able to connect to SQL.






          share|improve this answer





















          • 1





            I can see renaming sa, but wouldn't disabling it entirely prevent me from connecting if domain authentication became unavailable in an emergency? (Not that I can recall ever needing to do so, but I'm trying to anticipate all contingencies.)

            – BradC
            yesterday











          • @BradC edited in update addressing your comment

            – James Jenkins
            yesterday











          • Thanks, we'll consider that for a long-term solution.

            – BradC
            yesterday






          • 1





            It's difficult, if not impossible, to have Integrated Authentication completely stop working since the SQL Server service won't run unless it can log in. You don't need to have an Active Directory domain present to use Windows Integrated Authentication; SQL Server can authenticate you against the local security authority.

            – Max Vernon
            10 hours ago
















          6














          This is a closing the barn door after the horses already ran off question.



          You should have renamed and disabled the sa account when you built the instance.




          Any time you have a well-known account, like administrator on a Windows system or sa for SQL Server, you should take certain steps to secure it. Let's look at specifically what you should do with sa:



          Set a hard to guess password.



          Rename sa.



          Disable sa.



          Ensure that no other accounts exist named sa.




          Source



          If you are keeping the 'sa' account as an emergency way to get SQL access there are safer ways see: Connect to SQL Server When System Administrators Are Locked Out If you don't have network account access, you have bigger problems then not being able to connect to SQL.






          share|improve this answer





















          • 1





            I can see renaming sa, but wouldn't disabling it entirely prevent me from connecting if domain authentication became unavailable in an emergency? (Not that I can recall ever needing to do so, but I'm trying to anticipate all contingencies.)

            – BradC
            yesterday











          • @BradC edited in update addressing your comment

            – James Jenkins
            yesterday











          • Thanks, we'll consider that for a long-term solution.

            – BradC
            yesterday






          • 1





            It's difficult, if not impossible, to have Integrated Authentication completely stop working since the SQL Server service won't run unless it can log in. You don't need to have an Active Directory domain present to use Windows Integrated Authentication; SQL Server can authenticate you against the local security authority.

            – Max Vernon
            10 hours ago














          6












          6








          6







          This is a closing the barn door after the horses already ran off question.



          You should have renamed and disabled the sa account when you built the instance.




          Any time you have a well-known account, like administrator on a Windows system or sa for SQL Server, you should take certain steps to secure it. Let's look at specifically what you should do with sa:



          Set a hard to guess password.



          Rename sa.



          Disable sa.



          Ensure that no other accounts exist named sa.




          Source



          If you are keeping the 'sa' account as an emergency way to get SQL access there are safer ways see: Connect to SQL Server When System Administrators Are Locked Out If you don't have network account access, you have bigger problems then not being able to connect to SQL.






          share|improve this answer















          This is a closing the barn door after the horses already ran off question.



          You should have renamed and disabled the sa account when you built the instance.




          Any time you have a well-known account, like administrator on a Windows system or sa for SQL Server, you should take certain steps to secure it. Let's look at specifically what you should do with sa:



          Set a hard to guess password.



          Rename sa.



          Disable sa.



          Ensure that no other accounts exist named sa.




          Source



          If you are keeping the 'sa' account as an emergency way to get SQL access there are safer ways see: Connect to SQL Server When System Administrators Are Locked Out If you don't have network account access, you have bigger problems then not being able to connect to SQL.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited yesterday

























          answered yesterday









          James JenkinsJames Jenkins

          1,76821938




          1,76821938








          • 1





            I can see renaming sa, but wouldn't disabling it entirely prevent me from connecting if domain authentication became unavailable in an emergency? (Not that I can recall ever needing to do so, but I'm trying to anticipate all contingencies.)

            – BradC
            yesterday











          • @BradC edited in update addressing your comment

            – James Jenkins
            yesterday











          • Thanks, we'll consider that for a long-term solution.

            – BradC
            yesterday






          • 1





            It's difficult, if not impossible, to have Integrated Authentication completely stop working since the SQL Server service won't run unless it can log in. You don't need to have an Active Directory domain present to use Windows Integrated Authentication; SQL Server can authenticate you against the local security authority.

            – Max Vernon
            10 hours ago














          • 1





            I can see renaming sa, but wouldn't disabling it entirely prevent me from connecting if domain authentication became unavailable in an emergency? (Not that I can recall ever needing to do so, but I'm trying to anticipate all contingencies.)

            – BradC
            yesterday











          • @BradC edited in update addressing your comment

            – James Jenkins
            yesterday











          • Thanks, we'll consider that for a long-term solution.

            – BradC
            yesterday






          • 1





            It's difficult, if not impossible, to have Integrated Authentication completely stop working since the SQL Server service won't run unless it can log in. You don't need to have an Active Directory domain present to use Windows Integrated Authentication; SQL Server can authenticate you against the local security authority.

            – Max Vernon
            10 hours ago








          1




          1





          I can see renaming sa, but wouldn't disabling it entirely prevent me from connecting if domain authentication became unavailable in an emergency? (Not that I can recall ever needing to do so, but I'm trying to anticipate all contingencies.)

          – BradC
          yesterday





          I can see renaming sa, but wouldn't disabling it entirely prevent me from connecting if domain authentication became unavailable in an emergency? (Not that I can recall ever needing to do so, but I'm trying to anticipate all contingencies.)

          – BradC
          yesterday













          @BradC edited in update addressing your comment

          – James Jenkins
          yesterday





          @BradC edited in update addressing your comment

          – James Jenkins
          yesterday













          Thanks, we'll consider that for a long-term solution.

          – BradC
          yesterday





          Thanks, we'll consider that for a long-term solution.

          – BradC
          yesterday




          1




          1





          It's difficult, if not impossible, to have Integrated Authentication completely stop working since the SQL Server service won't run unless it can log in. You don't need to have an Active Directory domain present to use Windows Integrated Authentication; SQL Server can authenticate you against the local security authority.

          – Max Vernon
          10 hours ago





          It's difficult, if not impossible, to have Integrated Authentication completely stop working since the SQL Server service won't run unless it can log in. You don't need to have an Active Directory domain present to use Windows Integrated Authentication; SQL Server can authenticate you against the local security authority.

          – Max Vernon
          10 hours ago


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Database Administrators Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f230303%2fdoes-changing-sa-password-require-a-sql-restart-in-mixed-mode%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          How to label and detect the document text images

          Vallis Paradisi

          Tabula Rosettana