2

I have installed SQL Server 2008 R2 on a Windows 2008 server. I need to set the sa password to blank for some reasons to make an application works; but it seems like the password changes automatically some hours later.

I log in to SQL Server with windows authentication and set sa password to blank and I am able to log into sql with sa and blank password, but another day when I try to log in with sa and blank password and the error is:

no process is on the other end of the pipe
error 233

Improve this question
6
  • 7
    This is horrible securityvise. Ask the application provider for updated a software. Integrated Windows authentication would be the preferred solution.
    – vonPryz
    Commented May 15, 2013 at 10:23
  • 14
    A guardian angel fixes your bad password screw up.
    – Remus Rusanu
    Commented May 15, 2013 at 11:33
  • 3
    That sounds like some kind of networking issue to me, not a changed password (even though I agree that you should go back to the vendor and remind them - with a sharp object, if necessary - that a blank sa password is almost criminally obtuse). Do all other SQL auth connections from the same machine work?
    – Aaron Bertrand
    Commented May 15, 2013 at 11:55
  • 3
    That's a named pipes error. And, I'll stress like those commenting before me: that is a terrible practice to have a blank sa password. That's about as egregious as it gets for security vulnerabilities.
    – Thomas Stringer
    Commented May 15, 2013 at 12:34
  • 2
    See this? Your security situation is worse.
    – Marian
    Commented May 15, 2013 at 15:10

1 Answer 1

Reset to default
5

This error does not sound like a problem with the password at all, but rather a connectivity issue. It could be that some policy is re-establishing firewall rules, or it could be simply that you have flaky DNS, an unreliable connection to the domain controller, or some other network issue.

As @Thomas pointed out, the "pipe" in the error message implies that this is a named pipes error. In most cases I have tended to avoid named pipes altogether. On the server where the SQL Server instance resides, you should go to SQL Server Configuration Manager and experiment with disabling named pipes and making sure TCP/IP is enabled:

enter image description here

Then you'll want to make sure that your app's connection string uses an IP address if feasible or edit the hosts file so that the name resolves to an IP locally, instead of using a physical machine name or FQDN. Doing either of these eliminates your dependency on external name resolution from a domain controller (but obviously won't be a good idea if you are using DHCP for some reason).

Of course you may also want to review network logs (or set up some kind of network monitor) to determine if there is some issue outside of this, and make sure that neither machine has a firewall enabled (or at least ensure that it is open on the right ports and no group policy is coming in and "fixing" that). But these changes will be better for your environment even if they don't solve this immediate issue.

As an aside, you absolutely must fix that application's connection string anyway. A blank sa password is like leaving your wallet at the bus station on purpose.

Improve this answer
1
  • it seems to work! :) tanx Aaron! Ineed to wait couple of hours to be sure of it. I changed the default port 1433 to another one and set a rule in firewall. I am corresponding with the developer to solve this issue. thank you all commenters too.
    – vaheeds
    Commented May 16, 2013 at 8:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.