When using MS SQL Server, I keep trying to create more logins for the server with their own passwords however as soon as the login has been created, I go back to look at the login settings and see that the password has been reset to some mysterious 15 character password.
As you can imagine, this basically makes the login unusable. I've seen other cases similar to this specifically for the "sa" login however nothing on the creation of custom logins.
I've tried unchecking the "User must change password at next login", "Enforce password expiration", and "Enforce password policy" checkboxes but this has no effect. The one thing that does work is using no password at all, but obviously this is a huge security risk.
MS SQL Server never store your password for security reason. MS SQL Server store only the HASH of your password.
Therefore settings form can't shown the password. Instead it shows
some mysterious 15 character.
Related
Is there a way to view the password of non-sysadmin accounts on SQL Server 2016?
I'm a database admin. I can simply change the password for the user, but I'd love to know if there is a way I can retrieve the password without resetting it.
In SQL Server user and login passwords are never stored; they are hashed. When a user logs in by presenting a password, that password is hashed and compared to the stored hash.
I am trying to run a script in powershell. It fails because, when it checks the system admin password in SQL Server 2012, the sa login is not recognised. I've changed the password to the sa account, through SSMS without error, to what it should be (according to the company's instruction). All applications, powershell and SSMS were run as administrator.
So what I want to do is establish that the password has changed to the password I set it to. I realize that this is the system admin password so, in normal practice, this shouldn't be easy to find. Even if there is a query against system tables, I suspect it'll be encrypted anyway.
But I need to see that my change has worked or not to establish that the script is failing because of my change or some other reason.
In short, how do I look up the sa password in sql server without compromising security?
There's no way to look at the password, because that would be horrible security-wise. What you could do is check to see if the password matches the hash by running the PWDCOMPARE function like this:
SELECT case when PWDCOMPARE(N'WhatIThinkThePasswordIs',[password_hash])=1 THEN 'Match' ELSE 'No Match' END
FROM sys.sql_logins
WHERE name='sa'
I have a strange problem. In SQL Server Management Studio 18, I tried to log in with the sa account. It failed.
I know in this case we should check mixed mode auth and sa enable checkbox. I checked them and they were enabled. I saw all the net for other checkboxes or something useful but nothing that not enabled for me.
I logged in with Windows auth and changed the password of sa. after changing, sa login worked. but few minutes later after some tests with my application, I realized that I can't login remotely to sa. I returned and check again in management studio and While it was unbelievable, the sa login failed again.
I changed sa password and the story repeated again. what was happening?
Note, while this doesn't directly resolve a problem experienced with the SA account, which is ultimately unknowable without extensive investigation into the specific host environment, it does form part of best practice which the OP has identified as having resolved their overall problem.
The original comment:
Disable the SA account and create a dedicated application and/or user
login with appropriate permissions. The first thing I do on a new SQL
instance is kill SA as it's a prime attack surface.
I want to connect to SQL Server using SQL Server authentication in connection manager in SSIS. I want that every time when the package runs and connects to server it should use user id and password from the table created in SQL Server at run time.
The reason to get password from table is that every 6 months I need to change the password as per the policy so I don't want to login to each and every SSIS package and change the password there. I want to change the password in table and redirect that password through variable/expression to the connection manager password window.
I will ignore the idea that saving passwords in plain text makes changing them every six months a futile effort. It is a far greater security risk to have them stored in plain text ANYWHERE.
The solution is to NOT use an SQL Login. Have these services run under a specific Windows User and grant that User the necessary access.
An alternative is to explain the problem to the Security admin and get an account setup that does not expire but that can only login locally as a service. Don't use that account for anything else.
HTH,
Sean
I have created a new SQL Server on Azure, and am trying to sign into their web based Management area.
What credentials do I need to provide?
I created the Database using the Quick Create wizard, and was never asked for a password.
I have tried my Windows Live username and password, this doesn't work. I have also tried the username specified in the connection string you get from Azure with and without the #foo you get afterwards, along with my Live ID password, neither of these work either.
I can't see anything in the portal providing a password.
Am I missing something?
Go to the DB tab and select the DB server that was auto-created. Will have some random letters and numbers as a name.
On the dashboard of the server you should be able to reset the administrator password. On that page it should also give you the administrator login username.
Hope that helps,
Henry
edit: one other thing, you need to add your IP address as a management address. You can do this by going to the DB tab and clicking MANAGE at the bottom, should prompt you to add your IP to the firewall
Ok so I have no idea about the database created by the wizard, but if you go through the 'Custom Create' route on Azure, you have the opportunity to supply your own Username and Password, and these do work.