I am trying to install DNN using Web Platform Installer. It tries to connect to .\SQLEXPRESS, which I have installed along with SQL Server, and wants me password for sa. When I provide it
with a password, it says "password invalid or cannot connect to database".
I thought to myself there might be a problem with the sa account. I opened SSMS 2012. There is a red arrow downward sign on the sa account. Whenever I am trying to change login status to Granted it opens up an error message:
error 15151
Cannot alter the login 'sa' because it does not exist or you don't have permission.
Nonetheless I tried it with administrator account and also by disabling UAC. None worked. Screen shot follows:
Details:
SQLEXPRESS version: 10.0.2531
SQL Server version: 11.0.2100
Update: Following some guidelines I tried to change authentication in SQL Server Management Studio from Windows Authentication to Mixed Authentication, but it failed with the following permission error:
Make sure you're connecting with a server login that has the sysadmin server-level role. You'll need that permissions level to do what you're trying.
Check the server authentication mode. If it is or was Windows Auth only, the sa account is automatically disabled. Note that if SQL Authentication was disabled and later turned back on, the sa account will still be disabled.
If you find that nobody is in the sysadmin server-level role, you'll need to stop the server and restart it in single-user mode so you can add at least one login to the sysadmin server-level role. In single-user mode, the Administrators group has sysadmin access, but you'll have a limited subset of commands to manipulate data in tables (single user is for fixing servers, not running applications). NB: Only one connection is allowed in this mode, so if you have a broker or service that's trying to connect you'll need to disable that or it can take the session you were planning to use with SSMS.
Related
I am trying to install TFS on the server but it requires to have the user SYSADMIN role which can only be assigned using the sa user login.
I am using SQL Server 2014 Express. To enable the sa user, I tried enabling the mixed mode authentication but I get this error:
The EXECUTE permission was denied on the object 'xp_instance_regwrite', database 'mssqlsystemresource', schema 'sys'. (Microsoft SQL Server, Error: 229)
How do I fix that?
Update:
The problem is that I am Windows User and logging in with windows authentication. So using that user I am not able to assign any roles to myself or other user.
You can use an existing installation of SQL Server for Azure DevOps Server/TFS. To do so, you need administrative credentials granted by the SQL Server administrator. You must be a member of the sysadmin server role in SQL Server to install and configure Azure DevOps Server/TFS. So you need to contact SQL Server administrator and grant your account appropriate permission to install Azure DevOps Server/TFS.
If you want to start a new installation of SQL Server, you could refer to the following link:
https://learn.microsoft.com/en-us/azure/devops/server/install/sql-server/install-sql-server?view=azure-devops
I'm looking at using SQL LocalDB as the client side database which will replace the current SQL CE 3.5 database inside an in-house application developed in .net 4.
I've come across a problem that I'm not sure how to get around and that's with security setup of the LocalDB instance.
If I setup a script inside .net to create a private LocalDB instance, e.g. (localdb)\T1, then create a new database inside that instance plus add a SQL user account + password (non domain account), how do I stop the local windows users (like my own AD account) with admin level privileges from accessing the 'T1' instance + database using SSMS?
I could see a scenario playing out where we deploy the application, then we have some IT savvy user who goes snooping around and decides to install SSMS and connect to (localdb)\T1 with their windows account, which would give him/her full access to the database, which is exactly what I'm trying to stop from happening.
Some of our staff work remotely with no connection to a domain so we give them local admin rights to their pc so they can install software, so even if I could block their assigned windows login name, there would be nothing stopping them from setting up a new local admin account and logging in with that, opening SSMS then accessing the database.
Any pointers on this would be greatly appreciated!
In fact, it shouldn't be so hard. Install SQL Server on client machine using local admin account. To make you life easier, use Mixed Authentication.
After you have your instance installed, local admin account should have sysadmin server role assigned (that's normal security settings). Now, use the following:
Create new SQL Server user and assign sysadmin server role to that account. Close SSMS and log-in using new credentials. Or simply use sa account (not so good practice but in this case it's OK).
Go to "Security - Logins" and remove sysadmin role from local admin. Also, check in user mappings and take all rights "away" from local admin.
As a test, try to log-in as local admin, I guess you won't be able to log-in into server because there is no "home" database for that user. But even if you can log-in, it has only "public" role.
It's up to you to install your database and secure it - assign permission to user of your choice.
Regarding you fear that local admin can install MSSQL again: he/she can install it, but it would be another instance. That instance knows nothing about users in your instance so you should be safe.
You can also consider usage of application roles in SQL server.
I brought my laptop home from work hoping I could get some tasks done over the weekend. Unfortunately, I couldn't login to SQL Server using Windows Authentication. I've checked the SQL Server Configuration Manager and the instance (MSSQLSERVER) is set to Log On As Local System, which supposedly means that I should be able to login fine using Windows Authentication... or am I missing something here? Note that in the login window, I tried a lot of different combinations and it always keeps telling me that connection failed because the server is not accessible or I'm not authorized to access it.
A little background about how the instance was installed: I installed and configured it myself. I chose the Mixed Authentication mode and gave a password to the default sa user (which isn't working either by the way). The thing I suspect could be the problem is the fact that I installed the SQL SERVER instance when I was logged in as my Domain User at work (DOMAIN\UserName). Now I'm at home and I do not have access to the LAN at the office, so I'm logged in as the {COMPUTERNAME}\Kassem user.
Any thoughts?
A windows account has to be added to SQL Server to have any rights. If you didn't add {COMPUTERNAME}\Kassem, you can't login to SQL Server.
The recovery option here is the SA password, which should always work.
To connect to the default instance, connect to localhost or .. Connecting to .\MSSQLSERVER won't work, even though MSSQLSERVER is the default instance name.
I accidently disabled my Windows Authentication login and I don't have sa login (or other admin login).
How I can login to sql server 2008?
Follow this: Troubleshooting: Connecting to SQL Server When System Administrators Are Locked Out:
Resolution
Start the instance of SQL Server in single-user mode by using either
the -m or -f options. Any member of the computer's local
Administrators group can then connect to the instance of SQL Server as
a member of the sysadmin fixed server role.
I have a timeclock database setup on a Windows 2008 server, SQL Server. It has been working for MONTHS. Today, all of a sudden, it seems like some peoples' logins are working and some peoples' logins are not working.
SQL authentication works fine, however the Windows authentication is not working. I checked the log files and it seems like SQL Server 2008 is just not liking the passwords!
Does anyone know what could be going on here?
Windows auth relies on the SIDs contained in the login token generated when folk log in to Windows: not the actual windows password or even username
If it's failing, then you have issues witg Active Directory or some underpinnings such as Kerberos.
Saying that, there are some common issue I've seen over time:_
password changes: invalidate the login token in some circumstances. If you have a policy for password changes then simply sking folk to lock/unlcok their PCs will cause a "re-login" against AD
use FQDN + port: If you use named instance, the client must query port 1434 to get the actual port of the instance. If you have a lot of firewalls or remote clients then sometimes this handshake fails. IIRC something to do with Kerberos. We found using server.domain.tld\instance, port fixed all our issues (I'm talking USA or Hong Kong to Europe based server)
You may solve this problem by assigning user rights to the user: "NT AUTHORITY\SYSTEM".
Follow these steps:
Open "SQL Server Management Studio".
Open "Security, and then Logins".
Rightclick on user: "NT AUTHORITY\SYSTEM >> Properties".
Select "Server Roles" tab, and check the "sysadmin" server role.
You are done.
u can also try right click on the user u wanna grant the privilegies and click on all of them in server roles