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.
Related
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.
I wanted to read AWS Postgresql from within SQL Server, so
I created a system ODBC connection to Postgresql on the SQL Server machine, tested it, fine.
I then created a Linked Server to connect to postgresql.
In the Security tab (For a login not defined in the list above, connections will), I selected "Be made using the login's current security context".
When using this linked server while connected to SQL Server through windows authentication, it works fine.
If I connect to SQL Server using a SQL Server authenticated account, trying to access postgresql data through that same Linked Server fails authentication.
I fixed that by switching my security setting to "Be made using this security context" and giving the POSTGRESQL login/password (same that I gave at the ODBC level).
Question:
Without repeating the postgresql details at the Linked Server stage, why is it working with Window sauthentication account and not for SQL Server authenticated accounts?
Neither are relevant to Postgresql?...
I made it work but still confused...
I will have to guess a bit to help you, but I hope to give you enough context to understand what is happening so you can debug further.
When you connect to SQL Server using integrated authentication, the domain controller gives out a token to talk to SQL and this is used to authenticate your connection from your client to SQL Server's process. Underneath the covers, Windows can use either NTLM or Kerberos to do this handshake. You can read more about this here in this blog post:
NTLM vs. Kerberos Blog. This protocol choice matters when trying to use linked servers since it has to then authenticate to something else over the network.
At this point, it matters what credentials are used to run SQL Server (usually as a service in the services window to see). If you are running SQL as Local System or Network Service or something else defined by windows (instead of as a specific user on the network), it may or may not have permissions to talk out to your target remote server (whether it be postgres or something else). When you use Kerberos and enable delegation (which the domain admin needs to do), you can have the original integrated auth credentials "flow" over the linked server link to the next connection. NTLM does not do this. Therefore, the usual scenario is to create a map in the local SQL Server of what credentials to use when talking out to a remote linked server.
If you are talking to an ODBC driver, then you are likely using the msdasql (OLEDB to ODBC bridge) provider and then also having to go through its authentication stack. It has been too long for my memory as to whether it even supports integrated auth at all, much less delegation in Kerberos. However, you may be able to debug this problem further if you:
consider which account is running SQL
consider which mechanism is used to do integrated auth to sql and whether that would work with delegation
determine which credentials are used to make the outbound connection to your ODBC target. You should be able to debug much of this through the profiler mechanism as there is a distributed query/linked server set of events IIRC.
I can't speak to your postgres provider specifically, but this should give you some more tools to debug. Hope that helps you get one step further.
When I try to query the linked server outside of IIS, from console application everything works fine without any additional configuration.
When I try to query the linked server from website hosted in IIS, I
get the following error: Login failed for user 'DOMAIN\USER'.
Obviously, I can "fix" this problem by adding that user to SQL
Server, but why is it trying to access the SQL from user account and
not from application's pool account? Why don't I get error Login
failed for user 'IIS AppPool\MyApplicationPool'? Is there a way to
force it to use application pool?
Obviously, I can't access the Linked Server data without giving that user a read permissions on the folder. If I give permissions to Everyone - it works. If I give permissions to Users - it works...but which user is accessing the linked server data? Is it the MSSQL user? Is it the DOMAIN\USER?
Is there a simple way to do the following: Force application in IIS to authenticate with IIS AppPool\MyApplicationPool instead of local account so that I can simply give the read permissions on the folder to that application pool.
If I somehow manage to force it to use the app pool and configure the required permissions, did I bypass the double hop problem? Is there a need for Kerberos delegation?
Thank you in advance.
Here's my connection string
Data Source=PNJK-SERVER;Initial Catalog=PNJKDC;Integrated Security=True
but when I deployed it to another computer this error appears --> http://prntscr.com/atlzdp
Possible cause of the error are:
1) It will cause error if you have different SQL Instance for the other computer which is 99% possible. So your instance for the other computer will also be changed, and make sure that the DB PNJKDC also exist in that computer
2) If you are connected to a network and let's say you configured the whole networking thing e.g.(firewall, ports) the port number might be used by other processes in your computer, you need to change it to different port.
I would suggest creating a new user on the deployed machine's sql server instance, assign the user then necessary permissions to this database instance and specify the use in the connection string: User Id=username;Password=password12 instead of Integrated Security=true;.
Data Source=PNJK-SERVER;Initial Catalog=PNJKDC;User Id=username;Password=password12;
You need to ensure that Mix Mode Sql Server authentication is enabled and not just Windows Authentication for Sql Server.
If it is on a domain then you require to create a domain service account (Windows Authentication) with the necessary permissions to run the application. This will allow Integrated Security=true to work in most cases.
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.