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
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 am using Microsoft.SqlServer.Management.IntegrationServices in an ASP.NET web form to access an SSIS project in SSISDB. Testing locally on my own PC I am able to access the package from the test server and it runs fine.
My issue comes up when I try to run the site from the test server. The same test server hosts the site with IIS 7 and hosts the Sql Server database which stores the package with Integration Services. So like I said, the package is hosted on the server and when I run the site locally on my PC, all works fine.
When I run the site on test and try to access the package I get:
System.Data.SqlClient.SqlException (0x80131904): Login failed for user '[DOMAIN]\[PCNAME]$'.
I am using integrated security in my connection string:
SqlConnection connection = new SqlConnection(#"Data Source=[Test_Server];Initial Catalog=master;Integrated Security=True;");
IntegrationServices integrationServices = new IntegrationServices(connection);
My error comes up here when trying to connect.
I've tried adding '[DOMAIN]\[PCNAME]$' as a Sql login using Windows authentication with every permission I can think of. User mapping for database SSISDB has accessadmin, datareader, datawriter, owner, public, and ssis admin. I know not all of these should be needed, but I'm trying everything.
I went to SSISDB under databases, and gave the login permission to Connect, Execute, and Select.
Under Integration Services Catalogs I gave my folder, under SSISDB catalog, permission for the my Windows User ('[DOMAIN]\[PCNAME]$') login to Read, Execute Objects, and Read Objects.
I gave the SSISDataTransfer project permission for the Windows User to Read, Modify, and Execute.
I'm out of ideas and figure it's probably some IIS issue. It has Windows Authentication installed and set.
Anyone have any ideas? I've found posts about how to get the code to work, but nothing on connection specifics. Thanks!
i have had similar problem recently and i have worked with SSIS packages being used with web applications too. in my opinion you should use a custom user account to be used as your app pool account. and you will have to add this account to your database server. when running an app pool as local system or network service, the account being used for connection to a remote database server will be "DomainName\MachineName$" which will be different for every machine which tries to connect to your sql server. so instead of adding all these user names in sql, you will be better off using a custom user account.
Secondly looks like your web application does not run on the same machine as your sql server which i think will not work because you can invoke SSIS package from the same server only.
Another thing to try is to add a credential to sql server - in Security - Credentials in SQL Server management studio. This credential would be the authenitcated user that you are running it successfully under. Then in your SSIS package, in SQL Server agent, go into the job step and in the "Run As"drop down, select the new credential for your user that you created.
I've been trying for just over a month to connect an ASP script here to a SQL Server database
but each time I use this connection string:
Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=SSPI;User ID=domain\usr;Password=pwd;
It ignores the user I specify and takes the machine name to authenticate the connection, which obviously fails.
so I change the Integrated Security value to False, like this:
Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=False;User ID=domain\usr;Password=pwd;
I then get an error: Login Failed for user "domain\usr" which is impossible because it works when we test the connection with it in the odbc admin app.
I asked the help of a senior and he said it's taking the user name as a database user name, but we need to make it use windows authentication, and specify which user to use.
I remember reading about this a month ago and finding that there was no way to specify a user and password when connecting using windows authentication with this version of ASP.NET.
I'm going to kill myself soon If I can't get this script to connect, someone save me please!
You've got at least 2 3 options here:
Create an App Pool on your web server which runs as domain/usr and then assign your app to this app pool, and use integrated security. Your connection string will be Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=SSPI; - i.e. drop the username and password - these are inherent in the AppPool's identity.
or (assuming Mixed Mode security is enabled) ask your DBA's to create a new SQL User (just called usr) with the same permissions as domain/usr and then change your connection string to standard security, with User Id=usr
If you enable impersonation (here and here), you can use the domain credential without changing the app pool identity. Note the point about securing cleartext passwords, and IME this typically also requires additional configuration to avoid the double-hop issue.
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 am having a problem with deploying a ASP.NET V2 web application to our deployment environment and am having trouble with the sql server setup .
When I run the website I get a Login failed for user 'MOETP\MOERSVPWLG$'. error when it tries to connect to the database.
This seems to be the network service user which is the behaviour I want from the application but I don't seem to be able to allow the network service user to access the database.
Some details about the setup. IIS 6 and SQL Server 2005 are both setup on the same server in the deployment environment. The only change from the test setup I made is to point the database connection string to the new live database and of course copy everything over.
My assumption at this point is that there is something that needs to be done to the SQL server setup to allow connections from asp.net. But I can't see what it could be.
Any Ideas?
It sounds like you're able to connect to the database alright and you're using integrated windows authentication.
With integrated windows authentication your connection to your database is going to use whatever your application pool user identity is using. You have to make sure that the user identity that asp.net is using is on the database server.
If it is a fresh install not everything may be setup. Check SQL Server Configuration Manager, http://msdn.microsoft.com/en-us/library/ms174212.aspx. Step by step instructions http://download.pro.parallels.com/10.3.1/docs/windows/Guides/pcpw_upgrade_guide/7351.htm.
The user name you've indicated in your post is what the Network Service account on one machine looks like to other machines, ie "DOMAIN\MACHINENAME$".
If you are connecting from IIS6 on one machine to SQL Server on another machine and you are using Network Service for the application pool's process identity then you need to explicitly add 'MOETP\MOERSVPWLG$' as a login to the SQL Server, and map it to an appropriate database user and role. Type that name in exactly as the login name (minus quotes, of course).
Make sure there is a login created for the user you are trying to log in as on the sql server.
There's a few different things it could be.
Are you using integrated windows authentication? If so, you need to make sure the user ASP.net is running as can talk to the database (or impersonate one that can).
Does the web server have permission to talk to the database? Sometimes a web server is deployed in a DMZ.
If you are using a SQL Server login, does that same login exist on the production server with the same permissions?