I have already created the program to restart a SQL database but it only works if the client has the rights. This is going to be done on a local network from a client computer when they can't get a person that has the password on the phone. Any thoughts I'm currently using the servicecontroller to start and stop database. When I don't have the rights I get a access denied error, or This operation might require other privileges. Not sure if impersonation would work since I don't have the userid and password.
Setup a service on an account with enough rights to do the restart and write another application that will communicate with that service and tell it to do the restart.
You said in a comment "If we could get connected to the server we wouldn't need to run this program."
There is no solution without some rights on the SQL Server box, be it using a web page, WMI, a local service, whatever.
Related
I'm new to SQL Server. I was a postgres user before. I installed the default SQL Server on my local machine and I'm trying to get an old react with node js application of mine working with a SQL Server. When ever my frontend makes more than 1 call to the backend, if my SQL Server has admin privileges it throws
Error: 17810: Could not connect because the maximum number of '1' dedicated administrator connections already exists.
If not, it throws:
Error 18451: Only administrators may connect at this time.
I checked my database configs and it's set to MULTI_USERS, so I don't understand why I can't login without admin privileges. Can someone help me with this? I wasn't able to find anything online.
My NodeJS backend is using TypeORM to connect to the database
The dedicated administrator connection is a different kind of connection. It's not just "a connection being made by someone with administrative access". You would use the DAC when the SQL instance is having some kind problem, and you can't connect at all because resources are all tied up. SQL will reserve some resources especially for the DAC connection to make sure you can still connect.
A DAC connection can be made by specifying ADMIN: as part of your connection string, which will connect to the assigned DAC port.
You shouldn't use this for "routine" admin work. Just connect using a login with the required administrative server roles (eg, sysadmin). You definitely shouldn't use this as part of a regular application's connection string. You shouldn't be using a SQL Server sysadmin login either. Create a user with the appropriate permissions for your application, and don't use the admin connection.
Regarding your second issue: Make sure the instance wasn't set to start in single user or minimum configuration mode using startup flags. Note that this is for the whole instance, it's not the same as the configuration for an individual database.
I have just finished the development of my application on asp.net mvc connected with SQL server, and I will love to deploy it. I want to use Azure App service, but I got an error "Unable to connect to master or target server 'DATABASE_NAME'. You must have a user with the same password in master or target server 'DATABASE_NAME'". I have tried every thing I found online like modifying the SSDT, but nothing changed.
Please is there any recommendation to fix this issue? If not, Please what are other ways for me to launch the application. The application will be used internally for Sales purpose and I don't need any fancy hosting. Thank you in advance.
Did you setup the sql azure firewall to accept connections from your computer?
Even if you set it up once, it is possible that your internet provider attributed a different IP address to your computer. So you must redo your firewall set up again for your computer to be accepted.
It is important to know that only sql logins/passwords are accepted here. So you must give the login/password of the admin user that you mentioned at the moment of creation of you sql server azure (there is a step that sets it up when you create your azure database), or the login/password of a user you created and granted in this database.
Here is what happened. I run a web application on windows server 2008 R2. The app pool it uses runs under LocalSystem account. The application complained about "NT Authority\SYSTEM" not having access to my database, so i added that user to the database. It all worked fine until yesterday, when the application started complaining about "Development\MyMachineName$" not having access to my database. The app pool still is running under "LocalSystem" account. I am confused why is it now changed the identity.
While playing around i ended up removing my username from sql server security. My sql server 2012 instance is running in windows authentication mode. now i cant connect to the sql instance. to fix this found someone suggested to use "psexec -i -s ssms" to launch management studio under "NT Authority\System" account. when i tried this the management studio tries to log on with "Development\MyMachineName$" as well. i am now wondering what happened to "NT Authority\SYSTEM" identity.
Thanks in advance for the upcoming help :)
EDIT:
My SQL Server instance is on same machine as the web application. i.e. its a dev machine where is have iis and sql server running for development.
Lots of stuff going on here, so hopefully this will clarify things for you.
I run a web application on windows server 2008 R2. The app pool it
uses runs under LocalSystem account. The application complained about
"NT Authority\SYSTEM" not having access to my database, so i added
that user to the database.
If the database server is local to the IIS server, that's fine (though I would still use a domain account to run the app pool). If the database server is remote from the IIS Server then the "local system" pool with attempt to authenticate a network resource which will transition to using the computer account Domain\Computer$ (as would network service).
It all worked fine until yesterday, when the application started
complaining about "Development\MyMachineName$" not having access to my
database. The app pool still is running under "LocalSystem" account.
I can't tell from your question if these are the same server or not, more clarification would be needed.
While playing around i ended up removing my username from sql server
security. My sql server 2012 instance is running in windows
authentication mode. now i cant connect to the sql instance. to fix
this found someone suggested to use "psexec -i -s ssms" to launch
management studio under "NT Authority\System" account. when i tried
this the management studio tries to log on with
"Development\MyMachineName$" as well. i am now wondering what happened
to "NT Authority\SYSTEM" identity.
NT Authority\System is a special built in identity and does not traverse network resources, if it needs to it auths as the computer account Domain\Computer$. I don't know the whole setup from your text but for the psexec to work, it'd have to start ssms on the database server or it will continue to use the computer account. If you need access back, be a member of the server admins windows group and start SQL Server up in single user mode - connect with windows authentication (locally) and add your login back in.
We'd need a infrastructure diagram to get more into it, but the basics are:
Built in identities and accounts can't authenticate on a network unless they use the computer object.
Built in identities and accounts are only good for the server they are on and local to.
Giving permissions to anyone who could access that computer (through the computer object) is grossly over-provisioning permissions.
If you are running an application, the identity if yours so you could have been authenticating with your account the whole time testing. While individual threads can have different identities, most applications inherit the identity that spawned the process and in this case is most likely yours.
I think i figured it out. The reason was that when connection string uses computer name then it forwards "MACHINE$" as identity but when it is using localhost then it forwards "SYSTEM" as identity.
I recently installed Microsoft SQL Server 2012 on a fresh Windows 7 installation, but whenever I want to run the server, I get the following error:
Error 1069: The service did not start due to a logon failure.
The following user is configured to start the service: NT Service\MSSQL$SQLEXPRESS
How can I fix this problem?
The answer to this may be identical to the problem with full blown SQL Server (NTService\MSSQLSERVER) and this is to reset the password. The ironic thing is, there is no password.
Steps are:
Right click on the Service in the Services mmc
Click Properties
Click on the Log On tab
The password fields will appear to have entries in them...
Blank out both Password fields
Click "OK"
This should re-grant access to the service and it should start up again. Weird?
NOTE: if the problem comes back after a few hours or days, then you probably have a group policy which is overriding your settings and it's coming and taking the right away again.
This happened to me. A policy on the domain was taking away the SQL Server user account's "Log on as a service" rights. You can work around this using JLo's solution, but does not address the group policy problem specifically and it will return next time the group policies are refreshed on the machine.
The specific policy causing the issue for me was:
Under, Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignments: Log on as a service
You can see which policies are being applied to your machine by running the command "rsop" from the command line. Follow the path to the policy listed above and you will see its current value as well as which GPO set the value.
While ("run as SYSTEM") works, people should be advised this means going from a minimum-permissions type account to an account which has all permissions in the world. Which is very much not a recommended setup best practices or security-wise.
If you know what you are doing and know your SQL Server will always be run in an isolated environment (i.e. not on hotel or airport wifi) it's probably fine, but this creates a very real attack vector which can completely compromise a machine if on open internets.
This seems to be an error on Microsoft's part and people should be aware of the implications of the workaround posted.
Short answer:
install Remote Server Administration tools on your SQL Server (it's an optional feature of Windows Server), reboot, then run SQL Server configuration manager, access the service settings for each of the services whose logon account starts with "NT Service...", clear out the password fields and restart the service. Under the covers, SQL Server Config manager will assign these virtual accounts the Log On as a Service right, and you'll be on your way.
tl;dr;
There is a catch-22 between default settings for a windows domain and default install of SQL Server 2012.
As mentioned above, default Windows domain setup will indeed prevent you from defining the "log on as a service" right via Group Policy Edit at the local machine (via GUI at least; if you install Powershell ActiveDirectory module (via Remote Server Administration tools download) you can do it by scripting.
And, by default, SQL Server 2012 setup runs services in "virtual accounts" (NT Service\ prefix, e.g, NT Service\MSSQLServer. These are like local machine accounts, not domain accounts, but you still can't assign them log on as service rights if your server is joined to a domain. SQL Server setup attempts to assign the right at install, and the SQL Server Config Management tool likewise attempts to assign the right when you change logon account.
And the beautiful catch-22 is this: SQL Server tools depend on (some component of) RSAT to assign the logon as service right. If you don't happen to have RSAT installed on your member server, SQL Server Config Manager fails silently trying to apply the setting (despite all the gaudy pre-installation verification it runs) and you end up with services that won't start.
The one hint of this requirement that I was able to find in the blizzard of SQL Server and Virtual Account doc was this: https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts, search for RSAT.
I had a similar issue that was resolved with the following:
In Services.MSC click on the Log On tab and add the user with minimum privileges and password (on the service that is throwing the login error)
By Starting Sql Server to run as Administrator
If the user is a domain user use Domain username and password
One possibility is when installed sql server data tools Bi,
while sql server was already set up.
Solution:-
1.Just Repair the sql server with the set up instance
if solution does not work ,
than its worth your time meddling with services.msc
I don't know how good of a solution this is it, but after following some of the other answer to this question without success, i resolved setting the connection user of the service MSSQLSERVER to "Local Service".
N.B: i'm using SQL Server 2017.
Ever since moving to Vista some time ago on my development machine, connecting to SQL Servers in our DMZ active directory domain from client tools like SSMS has not worked like it used to. In XP, as long as I had authenticated in some way on the server (for example directing Explorer to \server.dmzdomain\c$ and entering valid creds into the login prompt), SSMS would use those cached credentials to connect.
However since switching to Vista, when trying to connect SSMS to a server in the DMZ domain I get the message Login failed for user ''. The user is not associated with a trusted SQL Server connection. If I change the connection options to use Named Pipes instead of the default TCP/IP, my cached credentials are sent and everything works fine. This is the case whether Windows Firewall is off or on, and connections to servers in our internal domain (the same domain my dev PC is in) work fine over TCP/IP or named pipes.
I don't mind too much using named pipes for these connections as a workaround, but it seems like TCP/IP is the recommended connection method and I don't like not understanding why it's not working as I'd expect. Any ideas?
"Login Failed for user ' ', the user is not associated with a trusted SQL Server connection".
In this scenario, client may make tcp connetion, plus, running under local admin or non-admin machine account, no matter SPN is registered or not, the client credential is obviously not recognized by SQL Server.
The workaround here is:
Create the same account as the one on the client machine with same password on the target SQL Server machine, and grant appropriate permission to the account.
Let's explain in more detail:
When you create the same NT account (let's call it usr1) on both
workstations, you essentially connect and impersonate the local account of
the connecting station. I.e when you connect from station1 to station2,
you're being authenticated via the station2's account. So, if you set the
startup account for SQL Server (let's assume it's running on station2) to be
station2's usr1, when you connect to SQL from station1 with station1's usr1
login, SQL will authenticate you as station2's usr1.
Now, within SQL, you can definitely access station1's resources. Though, how
much access will depend on station1's usr1 permission.
So far, SQL only deal with an user who is part of the sysadmin role within
SQL Server. To allow other users (non-sysamdin) access to network resources,
you will have to set the proxy account. Take a look at the article for
additional info.
taken from http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
Have you tried running SSMS in elevated mode, and do you have the latest SP installed on the client?
I would assume that this is because Vista runs most applications in isolation from either other.
I would recommend that you either set the DMZ username and password to match the internal domain username and password, or use named pipes to connect.