The Plan
Have HR personnel dump an Excel file of payroll Job Titles to a network share, add that file as a Linked Server in SSMS, use those titles in my ASP.Net web forms. Using a Linked Server instead of importing data to allow HR to update the Job Titles file at their discretion.
The Problem
I can create the Linked Server and query it without issue, so long as I'm in SSMS with Windows Authentication. But, if I try to access the linked server using a SQL account, I first get the error:
Access to the remote server is denied because no login-mapping exists (Error 7416)
The SQL account being used is the same account my web forms use for everything else. The fact that this SQL account doesn't have file permissions isn't surprising though, so an adjustment to the Linked Server's security should do the trick.
The Problem (part 2)
To reduce the number of variables, I moved the Excel file so it's on the same machine as my SQL Server. I'm logged into the machine and logged into SSMS with my domain admin account.
I access the Linked Server's security tab and, to try and cast the widest net possible, I leave the local login (top part) blank and head straight to "Be made with this security context:" and proceed to provide my domain admin credentials. I hit OK, and I get the following:
Not a valid account name or password (Error 7399)
I know the account name and password are good, so what gives?
Other Things
Folks who've ran into similar things have been instructed to change the logon account being used for the SQL Server service, which I've done using my domain admin account (for troubleshooting, atm). This did not fix the problem.
This is what the Linked Server code looks like, although I created it via the GUI (included for sake of completeness):
EXEC master.dbo.sp_addlinkedserver #server = N'ADP_TITLES', #srvproduct=N'', #provider=N'Microsoft.ACE.OLEDB.12.0', #datasrc=N'C:\JOB_TITLE_EXPORT.xlsx', #provstr=N'Excel 12.0 Xml'
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'ADP_TITLES',#useself=N'False',#locallogin=NULL,#rmtuser=N'DOMAIN\username',#rmtpassword='########'
The solution appears to be entering "admin" for the remote login, and leave the password blank.
This only works, however, if the file is stored locally. If it's on the network, I still get a 7399 error, but instead of saying the issue is the account name/password, it now says the issue is unspecified.
I can make my project work with a local file though. Since I'll be moving forward with that, I have no need to solicit additional answers.
Related
I have been able to set up an active directory login for my Azure database.
Now I want to add additional active directory logins and set their permissions
I understand that I need to use Management Studio to do this and have installed SSMS v17.8.1
I have been studying docs but I can't find the instructions
[Update]
After reading Conor's answer I was able to create the user
CREATE USER [jobuser#mydomain] FROM EXTERNAL PROVIDER WITH DEFAULT_SCHEMA=[dbo]
However if I try to login using MSSMS with Active Directory - Password authentication I get
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' (MIcrosoft SQL Server, Error 18456)
[Update]
In the Connection Properties Tab
I had to overtype with the database name
That particular page only shows an example using a SQL login/user, so I can understand why you are confused.
Please read through this page:
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql?view=sql-server-2017
Specifically, you want to create a user using the AS EXTERNAL PROVIDER example. This tells SQL Azure (and SQL DW) to use Azure Active Directory instead of creating a SQL user. Please note that this does not (as of today) work in SQL Server. (SQL Server supports integrated authentication against a local Active Directory, but it just does not currently support the Azure Active Directory service).
Also, there is no specific requirement that you use SSMS to do this step. You can do it within SSMS, SQL Operation Studio, through one of the SQL client drivers in a program you write (or some third party program that can invoke SQL over them), sqlcmd, etc. You don't even need to have the latest SSMS to make things work (though it is recommend to get the best experience against SQL Azure including syntax highlighting).
Please give that a try and see if it gets you unblocked.
Best of Luck!
I'm just in the process of trying to properly configure asp.net 4.5 on our IIS servers.
I have been able to navigate and launch an ASPX page that contains no data conenctions sucessfully so I know that the application pool authentication to the local directories is working as it should.
Now though I have a seperate SQL server that is connected to the domain and have a connection string stored in the code that connects the ASPX page to the server using a trusted connection. When running in visual studio debug mode, the connection works fine - but at that point I assume it is using my login credentials.
My question is, when a user calls the aspx page via the browser when hosted on the new IIS7 server, which account is used to call the SQL server when using a trusted connection? - Is it the end users or is it a local account from the IIS server?
When I call a page with data connections embedded I get the error: Login failed for user ADMIN\PCNAME$ ... which is an indication that this is the account that it is using. However this account doesn't exist on the domain that I'm aware of. - Or does it ?!
Thanks in advance,
It will use the account that ASP.NET is running under, as you've worked out. What you usually should do is create a Domain Account (with the right privileges) and run your ASP.NET AppPool under that account. Then a Trusted Connection will use that account for connecting to the database, and as long as you've given it access (which as a Domain Account you can do) it should all work.
Added:
After some back and forth on comments, lets go back to the start: set the new AppPool to run with the domain users account, and recycle the AppPoolo. What is it that says the password is wrong? If it's IIS trying to start the AppPool, then it is extremeny likely that the Password you gave the AppPool IS wrong, or else that the password is set to change on first logon.
If its not IIS, but opening a Database connection, are you sure that the database allows this Domain Account access to the database and the tables within it it will need? What roles have you assigned to this account? Also, what SQL statement is it trying to execute (if it's got far enough to try and execute a statement at all)?
I suggest you put any response in you original question - comments get to be a drag if there are too many of them.
I have an issue with logging a Support user into an Application that has a SQL Server backend.
When configuring the application itself, the SQL set-up asked me to assign whether the Security to access the Application would be Windows Authentication or SQL: server Authentication, I chose Windows Authentication, and as I was using a login called
'LabUser1' I have been able to login to the application fine.
However, when I logon to the server using a different windows login, this time 'Support', SQL keeps giving me the error:
Error accessing the database DSN
Now I know the reason is because the install of SQL happened using the 'Labuser1' profile, but how can I create a script that will allow me to add the 'Support' user to the 'Allowed Logins' so that I can logon to the app server and at least open the Application? (I have seperate logins for when I see the applicatiojn login window, so please don't confuse the matter by thinking it is a simple case of creating a login for Support....I am talking about logging into the server)
The current batch file I am trying to run is:
sqlcmd -S localhost\OCDBB01 -i createSupportlogin.sql
Then I run this batch file after having created the following SQL script:
CREATE LOGIN OCDMW1\Support FROM WINDOWS
GO
Your description of the situation is a bit confusing to me however it appears that the "SQL setup" that is part of the application configuration created a ODBC DSN that uses the credentials of person logging into the machine as the login for SQL Server.
Simply creating a new (correct) login to the SQL instance may not resolve this issue since that does nothing to modify the DSN. If you are tied to using Window Authentication for SQL access it might be necessary to create multiple DSNs for the application to use and find a way to have the correct DSN associated to the right login for the application to use.
I have an SSIS package that transfers some tables to CSV files on a network drive; it runs fine from my computer manually. I store it on the server in the MSDB database and execute it from there and it runs fine, but when I create a job that has one step that runs the SSIS package from MSDB it fails saying it can't find the CSV file name.
I spent all day yesterday figuring out this means a permissions issue with whatever logon credentials are being used through the job. The job owner shows to be domain/myuserid and step properties show they are using windows authentication with my username. The problem is, I know I have access to this folder.
The first line of the error log says: "Executed as user: servername\SYSTEM". So I made sure user "SYSTEM" has access to the network folder I want to load the files on, but I still get the same error.
The command line looks like #command=N'/SQL "\SSIS package name" /SERVER servername /CHECKPOINTING OFF /REPORTING E'
edit: I found SQL Server agent job account issue where someone asks who the job is run under and marc_s says "I can't seem to find any definitive answers on that one, really. Since my Jobs typically select and update stuff in the database, I am lead to assume that the "Owner" account will be used by default, unless you specify some other account on a given step"
Which also leads me to believe it is using my logon information that has access
The best practice that we've been able to come up with here is to make a domain account for SSIS and then set up a Proxy in SQL Server that is used to run the SSIS Package in a SQL Job.
I would say that the servername\SYSTEM account is a local account, and therefore won't have access to network folders on other servers.
You probably want to run this as a domain account of some sort, which does have access.
Typically this will be the SQL Server Agent, so check in the Services list, in the control panel, and see what account is running the agent, and if necessary change it to the appropriate account.
This may have knock on consequences though, so be careful what other jobs are running.
The problem is I have full access to the server where the Sharepoint site is hosted etc, however all i've ever done is maintained the site. I didn't set it up.
There is now an issue where Sharepoint can't connect to the Config or Content databases. I don't know which of our servers run these, so is there anyway I can find out, maybe from a config file or anything which server/database I need to check.
Other websites on the web server are still running fine, I know the database isn't on that same server because i've checked.
Any ideas?
I normally find the easiest way is to look at the site collections settings in Central Administration (which you should be able to access if you have root access to the server WSS 3.0 runs on)
Take the following steps once in the Central Administration site:
Go into Application Management
Go into Content Databases
Select your web application using the selector which is orange in the top right of the main content of the page
Click the name of the database displayed
Once you are at the final point you should see at the top information for Database Server and SQL Server Database Name. Hopefully this should point you in the right direction of where your database is being stored.
If your access to the database content database is cut due to incorrect login details to the SQL server (i.e. the SA account's password has changed), the SQL credentials can be updated here too for the selected content database.
Hope this helps.
Check out the Event Viewer Log. There would be an entry similar like this:
Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Database
Event ID: 3760
Date: 4/16/2009
Time: 11:51:07 AM
User: N/A
Computer: IMIAPP03
Description:
SQL database **'STS_Config'** on SQL Server instance 'np:\\.\pipe\MSSQL$Microsoft##SSEE\sql\query' not found. Additional error information from SQL Server is included below.
Cannot open database "STS_Config" requested by the login. The login failed.
Login failed for user 'NT AUTHORITY\NETWORK SERVICE'.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.