I'm able to execute a stored procedure which queries a Linked Server directly, but when I call the same sproc though ASP.NET then I get the following error:
Access to the remote server is denied
because no login-mapping exists.
When I execute it through SSMS, I am connected through my Windows domain account.
The site is ASP.NET with Forms Authentication on IIS 7 and SQL 2008 on my local machine.
The Linked Server is set up to "Be made using this security context" for all logins.
The login that you connect with to your initial database does not have access to the linked database. Why don't you use the account that the application impersonates to connect to the database in Management Studio, and diagnose the issue that way? If you know the login, just create it in the linked database as well with the required permissions.
If creating a new login on the linked server is not an option, create a mapping. If you read the fine print on the wizard, it says "for logins not defined in the list above, connections will be made" using the current security context. Which means that if you don't define a mapping, it will use the current credentials for the link.
There are two login/password pairs required. One is for the SQL server that has the linked server on it. The 2nd is for the 'thing' the linked server is connecting to.
E.g.
There is an ODBC connection on the same machine SQL server is on.
This ODBC connection connects to an ORACLE db. During the ODBC setup a user name and a password were required: UN "XYZ", PWD "123".
When creating the linked server to this ODBC connection its necessary to add the user name "XYZ" and password "123". This is done on the security page of the linked server properties. Click "ADD" and in the 'Local Login' box enter the SQL server user name that the app uses to connect to SQL server. In the 'Remote User' box enter 'XYZ' and in the 'Remote Password' enter '123'. Finally select 'Be made using the login's current security context'.
Related
BACKGROUND
I have created a Linked Server on an Azure Managed Instance and secured it to specific logins only.
I have a SQL Agent job that wants to use the Linked Server.
QUESTION
How do I grant the Azure MI SQL Agent execution account the permission to use the Linked Server?
RESULTS
In on premises SQL Server I would add the service account I assigned to SQL Agent as a linked server login using proc sp_addlinkedsrvlogin. However, my SQL Agent service account appears to be [User Manager\ContainerAdministrator] (REF 1). If I try adding that login using the above proc I get the error 'User Manager\ContainerAdministrator' is not a valid login or you do not have permission.'.
When my SQL Agent jobs tries to use the linked server I get this error as expected : Executed as user: User Manager\ContainerAdministrator. Access to the remote server is denied because no login-mapping exists.
WORK AROUNDS
Remove security on the Linked Server and let every login use it. This is unacceptable from a security stand point.
Move my SQL Agent job off the Managed Instance onto an regular installation of SQL Server where I can grant the SQL Agent execution account permission to use the linked server. Refactor the job to write the results back to the Managed Instance using a second linked server. This is what I think I need to do but it is disappointing as our research on Azure Managed Instance indicated that SQL Agent and Linked servers were supported, just not at the same time apparently.
REF 1 : https://johnmccormack.it/2020/09/how-do-i-find-the-agent-service-account-for-azure-sql-database-managed-instance/
i publish an mvc3 application on a webserver IIS7 and i want to connect my application with a remote SQL server ( different machine)
here is my connection string:
connectionstring="server=server;database=db;user Id=user;password=psw;user instance=false" providername="System.Data.SqlClient"
i m using entityframework.
i also added the user in the connectionstring to security folder under database in sql management studio with dbo rights.
the problem is i get an error : failed to open a session for the user
SQL exception (0x80131904)
Have you checked the user mapping for the login?
You can find the logins under the server folder security -> logins.
Check there is a login mapped to the database user. Select the appropriate login -> properties -> user mapping tab.
The fact that a user exists in a database, does not directly mean that there is a valid login associated with that user. Ensure that a login maps to the database user and that the user has the required database role.
After hours of research i just figure out that adding the whole groupe of computers (Domain\Computers) granted me the access to the database. i changed my connectionstring to use integrated security= sspi. From the beginning it was a Connection problem.
I am using SQL Server 2008 R2 and am facing a problem. The application that I have developed needs to be tested at client's site which is at different locality. So I plan to configure the client's machine once and then for any changes related to application I will just distribute a asp.net mvc deployment package which client can deploy on IIS. For that, I need to provide my asp.net application ability to drop and create database (through codefirst entity framework). In the present configuration, I am facing permission issue related to dropping the database. The Application somehow is unable to drop the database. Here is summary of IIS and SQL Server configuration that I am using.
For IIS, I have set the Application Pool Identity to "Local Service" as per the standard practice. The connection string in asp.net web.config file is given below.
connectionString="Server=.\SQLEXPRESS;Database=SomeDatabase;Trusted_Connection=true;User Id=someuser;Password=somepassword" />
For SQL Server Service, I have provided "Local Service" as log on, again providing the minimum access here for the service. For SQL Server Instance Logins I have defined the user and password and given complete authority ("sysadmin") role.
With this configuration in place I was expecting my IIS application to connect using the user and password created above and have the ability to drop and create the SQL Server database. But I am getting permission denied for Dropping Database. The Exception is given below.
System.Data.SqlClient.SqlException (0x80131904): Cannot drop the database 'SomeDatabase', because it does not exist or you do not have permission.
I have checked that the database exists so it boils down to permissions. Am I missing out some configuration ?
To be clear, your connection string is a bit malformed, and may not be behaving as you expect.
When you specify Integrated Security=true in your connection string, then Windows Authentication occurs. Any user id= attribute in the connection string will be ignored.
Switch to SQL Server authentication mode by dropping your Integrated Security=true attribute.
Server=.\SQLEXPRESS;Database=SomeDatabase;
User Id=someuser;Password=somepassword;
Further, the DROP DATABASE command can be executed by the database owner, a user who's a member of the db_owner role, or a user in a server admin role.
Add the database user someuser to the db_owner role.
EXEC sp_addrolemember 'db_owner', 'SomeUser';
Alternatively, if you determine that the account above should NOT be in this role (i.e. restrictive security environment, policies, etc), consider creating and using another account just for this purpose. This would likely mean maintaining another connection string. If the separation of users/roles is important enough for you, perhaps this second option will work.
I think that the real account being used on the Sql connection is the 'Local Service' because you defined Trusted_Connection=True in the connection string. Try to remove it and see what happens. If I'm not wrong, this parameter will make use of a Windows Integrated Account, the Local Service in your case.
While specifying credentials in the connection string, you either need to omit Trusted_Connection part or set it to False
Data Source =myServerAddress; Initial Catalog =myDataBase; User Id =myUsername; Password =myPassword;
OR
Server =myServerAddress; Database =myDataBase; User ID =myUsername; Password =myPassword; Trusted_Connection =False;
Refer http://connectionstrings.com/sql-server-2008 for more details.
I cannot connect to my SQL Server database when running app on server.
Everything runs fine when debugging but when I run on the server as ASPNET the user is unable to login.
I created the dataabse in a test project then simply connected to this db. My connection string is
Data Source=.\SQLEXPRESS;AttachDbFilename=C:\Temp\Barry\fsr\FSR.mdf;
Integrated Security=True;Connect Timeout=30;User Instance=True
So this asp app runs on IIS 5 and when deployed the initial select works fine as my gridview that I have a binding to shows data but when I run the program (update the db) I hit the following:
[SqlException (0x80131904): Cannot open user default database.
Login failed.
Login failed for user 'hostxxxxx\ASPNET'.]
I am not creating this database programmatically as mentioned previously, simply connecting to an existing database.
The database is located on my c: - but I have added user ASPNET. How can I add this db to the program as a resource rather than reference a copy on c:?
My first question is this: If you have control of the server, why are you using an attached database. From:
AttachDbFilename=C:\Temp\Barry\fsr\FSR.mdf
There is no reason to attach if you can control the server. Attach the database to the actual instance in SQL Server, not with the bastardized version you have above. The bastardized version is useful on an ISP that does not give you access to SQL tools. Beyond that, it is more work than it is worth.
The second problem you have is authentication. There are a couple of ways to handle this. The easiest is set up a SQL user to access the database. If every user will have login credentials, you can keep the Windows Authentication method, but you have to turn off anonymous access, so every user GETS authenticated. As long as anon is a choice in IIS, it will default to anon and you will have issues. The third way is to impersonate a user for database access. I guess the fourth is open your database wide open, but I don't suggest destruction of security to make something "work".
If you have your database on a server, you need to use a server-based connection string - something like:
Data Source=servername\SQLEXPRESS;database=FSR;
Integrated Security=True;Connect Timeout=30;
Your user needs to have a login on the server, and a user in the appropriate database, in order to connect successfully.
See the ConnectionStrings.com web site for a huge list of possible connection strings - and what their settings mean and how you can change those.
You need to get into your database and assign the proper privileges to the account that is trying to access the database, which in this case looks like the built-in ASPNET account. Instead of the ASPNET account, you should use the NETWORK SERVICE account. You can change this through IIS.
For debugging purpose, I backedup one of QA database and restored to local machine. Since it is in my local machine, I just want to connect to it using Integrated Security=True in my asp.net application. But I am getting following error:
Cannot open database "db1" requested
by the login. The login failed. Login
failed for user "DEV-LPTP-1784\ASPNET".
Any thoughts?
Thanks.
Delete and recreate database login you use. After db restore the database user has the same name, but inner SQL Server id is different, so SQL Server thinks that server login "DEV-LPTP-1784\ASPNET" is different than db user "DEV-LPTP-1784\ASPNET"
The user that ASP.NET is running under does not have access to that database. You can either grant that user access via SQL Management Studio, or change your connection string to use a specific username and password.