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/
Related
I'm starting an SSIS package from an .aspx using sp_start_job on the SQL-server.
This package is an import-job, where the destination database is on the same server as the job, so the DestinationConnectionOLEDB uses the same SQL-credentials as for running the job.
However, the source is on another server, and the SourceConnectionOLEDB requires a windows domain account for logon. (The package runs fine from Visual Studio, using my windows account).
I seem to have two possible solutions for the account in the SourceConnectionOLEDB.
either to pass the account of the user who is running the .aspx
or specify a fixed windows account and password in the package.
The last seems not possible to do in Visual Studio, as soon as I select Windows Authentication, the UserID and password field is disabled. Or is there a way of saving this info in the SSIS?
And if not, how do I pass the users windows credentials to the sp_start_job?
If I got it right, you have a SQL Server Agent job that runs an SSIS package, with a step of type "SQL Server Integration Services Package".
You cannot save AD user login info in SSIS (afaik), but you can specify which user runs the job step in SQL Server by setting up credentials and proxy to be used in that specific job step.
When you run the job, it gets executed as the SQL Server Agent Account by default, but you can change that by using credentials and proxy.
The credentials (Security - Credentials) allows you to specify a username and pw (even an AD user), to be used later by a proxy
The proxy (SQL Server Agent - Proxies) allows you to specify which credentials are available to different job step types.
Summary:
Create the credentials object (Security - Credentials) for your AD user
Create the proxy object (SQL Server Agent - Proxies)
use the credentials defined in point 1
enable the subsystem "SQL Server Integration Services Package"
Configure the job step
in the "run as" dropdown you should see the proxy you just created
Of course in your package you must have set Windows authentication for the data source
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'm currently implementing a cache mechanisem for our site.
I want to use the SQL Cache dependancy feature.
I am running the following command in management studio and it's not working.
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO "my_server_name\ASPNET"
The error I'm getting is:
Cannot find the user 'my_server_name\ASPNET', because it does not exist or you do not have permission.
I tried signing in with the admin of the specific database I'm setting the notification for, sa, and windows authentication with the machine administrator.
Also tried running management studio as administrator and still not joy.
Can someone please point me in the right direction.
Thank you!
First, it appears you are attempting to grant permissions to the account under which the site is running. In IIS 6 and IIS7 these are control by the account set on the Application Pool. That account used to be ASPNET but no longer by default. Instead, the default (starting with .NET 2.0 I believe) is NETWORK SERVICE. However, if you are using IIS 7, that has changed yet again. By default in IIS7 it uses something called the "ApplicationPoolIdentity" which is its own special credential created for each site. If SQL Server is on a different machine than the web server, you will run into another problem which is the credentials are all local to the machine.
My recommendation would be to do the following depending on your setup:
Both servers are on a domain and you want to use trusted connections:
Create a domain account and drop it into Domain Users.
On the web server, drop this account into the IIS_IUSRS group.
Go into the Application Pool for the site and change the account under which the site is running to this domain account. You will also want to ensure that this account has the proper NTFS permissions to the site files. If this site only writes to the database, you can given the account read-only access the folder(s) with the site files.
Ensure the connection string used by the site is formed to request a trusted connection. (See www.connectionstrings.com for the syntax)
On the database server execute your grant to this account:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO "domain name\MyIISAccount"
There may also be other Kerberos issues related to the fact that both servers on the domain and that might require creating a SPN (Service Principal Name).
Neither server is on a domain (i.e., both are member servers) and you want to use trusted connections:
Create a local account on both the web server and the database server with the same username and password. It is critical that they both have the same username and password. This technique involves using NTLM "pass-through" authentication which matches the hash created by the username and password to determine if the user is authenticated between the two desparate servers. On Windows 2008 R2, you may have to jump through a few local policy hoops to ensure that NTLM is enabled between the two servers.
Do steps #2 to #4 above with this account.
On the SQL Server, ensure that this local account has a Login and that this login maps to a User in the database. Then you would execute something like:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLServerMachineName\AccountUsedBySite'
You want to use SQL accounts instead of a trusted connection:
In this scenario, the connection string used by the site to connect to the database will include a username and password which map to a Login on the SQL Server database which maps to a User in the database (typically put in the db_owner role to make it dbo). This
Assuming the credentials are correct, you need only execute your grant against this user:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLUserAccountUsedBySite'
Both IIS and SQL Server are on the same machine and you want to use trusted connections
Create a local user account and drop it into the Users group.
Drop this account into the local IIS_IUSRS group.
Go into the Application Pool for the site and change the account under which the site is running to this local account. You will also want to ensure that this account has the proper NTFS permissions to the site files. If this site only writes to the database, you can given the account read-only access the folder(s) with the site files.
Ensure the connection string used by the site is formed to request a trusted connection. (See www.connectionstrings.com for the syntax)
In SQL Server, create a login for this account then create a user in the appropriate database for this account dropping it into the appropriate roles.
Now execute your grant to this account:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLServerMachineName\MyIISAccount'
Try this:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO [my_server_name\ASPNET]
I have installed a new web application that access a SQL Server database in a different server. I'm using Windows Authentication and get the error of:
Login Failed for user XXX
When I try to set identity impersonate="true" in the web.config file, it just throws an error
Login Failed for anonymous user
Also, I'm using forms authentication to validate users from my website and using a different application pool.
Update: connection string Basically like this:
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
Update:
My Virtual Directory has Anonymous Authentication and Windows Authentication enabled.
Typically ASP.NET runs as an anonomous account. In order to access a remote SQL Server using integrated authentication (SSPI), you'll need to have a bit more "permenant" presence. Easy way would be to shift the app pool to use the NETWORK SERVICE built-in account. Slightly trickier would be to use a named account. On the SQL server side of the equation you will need to give the same account -- either matching user/pass or NETWORK SERVICE -- proper permissions to your database.
Your DBA should be able to help.
It is difficult to provide you with an exact answer because you have not provided your connection string or info on your SQL Server config. Your best bet is to look at the IIS configuration and work out what user is attempting to access the different SQL Server. You then need to give this account access to the database. This is a common problem and most of the changes need to happen in SQL Server unless you can change the account that the web server is running under.
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'.