I have a simple EF Code First project that has to create a database in my local SQL server if it doesn't exist. However, when I try to debug my application I get the error:
Cannot open database "<Database>" requested by the login. The login failed.
Login failed for user 'MicrosoftAccount\someone#me.com'.'
I somewhat understand that because I login to Windows with my Microsoft account.
So I changed my connection string from using integrated security to username and password.
I made sure the user is created on the SQL server (Login & sysadmin rights) but it still fails when I debug in Visual Studio.
So..... I build the project and ran the application directly via the exe file and everything works. But I want to understand why it doesn't work with the debugger.
Have I missed something obvious here?
So I found the problem.
My local Windows account was paired with my Microsoft account. For some reason Visual Studio sends my Microsoft account to the SQL server to authenticate even when run under specific local credentials.
My solution was to create anew local user on my workstation with NO assosiated MS account.
I made the account member of Administrators and gave it permission to the SQL server then everything was fine...
Please ensure the server and database name are specified correctly in connection string. I had a typo, and got the error.
I guess that the debugger runs with different credentials (or could be set to do so). Especially if your account is not admin.
Maybe this helps: https://blogs.msdn.microsoft.com/greggm/2008/05/15/visual-studio-remote-debugger-service-user-account-requirements/
Related
I've been working to try and connect an ASP.NET application to an IIS Site running in an App Pool using Integrated Security. I was eventually unsuccessful in that attempt until I made the Login I'd created to represent the App Pool a Sysadmin, which I understand is not a good thing to leave in there. It's on localhost, but it still makes me uneasy.
So I decided to try to use a Login/Password combo instead of Integrated Security. To that end, I created a new Login in my SQL Server Management Studio:
And told it to use a password, making sure that I know what the password and username are.
My Default database is master
Server Roles is only 'public'
In User Mapping I added db_owner to one of my databases, and all the others are only 'public'
In Securables, 'Connect SQL' is Granted to the SQLEXPRESS server
I then disconnected from SSMS and tried to reconnect using my newly-created Login.
It didn't allow me to log in:
According to:
https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-login
After creating a login, the login can connect to SQL Server, but does not necessarily have sufficient permission to perform any useful work.
However, that appears to not be the case in this instance. What am I doing wrong?
I did make sure that my Server Authentication was set correctly, per SQL Server 2008 can't login with newly created user
Another data point: when I try (and fail) to log in 10 times in rapid succession and then go back in with Windows authentication, the 'Login is locked out' notification in the Status tab is not checked.
The thing I was missing was going to Windows Services, and restarting SQLEXPRESS to get the change to 'SQL Server and Windows Authentication Mode' to take effect.
After I did that, I was able to log in with my testuser.
I have a .NET MVC project that gets its data from a SQL database.
When I run the project in debug mode on my local machine, it runs without error; however, after I deploy the project to my IIS server (version 6 I believe) using Microsoft's Publish Wizard (create a .zip, move that .zip to the wwwRoot folder the website is pointed at), I encounter an issue: I access the website's main page via URL address, but when I enter the login ID, it produces a built-in error message "Invalid user ID".
The only time this error ever occurs when a valid ID is entered is if the database cannot be reached to check login credentials. So, using SQL Profiler, I tried to see if a query was made to the database - it appears that the answer is "no".
I have verified that the connection strings are configured correctly in the IIS environment, and can safely assume that there are no code-related errors with regards to this issue.
The question: What other troubleshooting methods are available for IIS and SQL interactions to see what the root of this error is, or what suggestions might you have to try and eliminate the problem
Add the user to the database logins and grant this user access to the database. Connection string in your code should have its credentials. Reason why it works on your machine is likely because you are sysadmin or something on the server. Look up a way to enter credentials in your connection string's parameters.
https://www.youtube.com/watch?v=Sp6lR15iWMk
I just installed SQL 2012 Enterprise on a laptop running windows 10 Pro x64.
When I try to execute my SSRS reports from the report manager, I always get the same error:
An error has occurred during report processing. (rsProcessingAborted)
Cannot impersonate user for data source 'DataSource1'. (rsErrorImpersonatingUser)
Log on failed. Ensure the user name and password are correct. (rsLogonFailed)
The user name or password is incorrect
I am using integrated windows authentication with a domain account.
The domain account can log on through SSMS and can access the databases with no issue and run queries.
I have also tried using a local SQL account and password but with the same result - The username or password is incorrect, yet this account works through SSMS and is able to execute queries and such.
When i click the Test Connection button in SSRS datasource configuration, it states the connection was created successfully. (I have included a shot of what I am talking about in the uploaded image)
After googling, people stated that the account that is being used to connect to the database using windows impersonation had to have log on locally permissions, so I added the account through local security Policy, but it made no difference.
Another blog stated the SSRS Service account had to also be granted log on locally permissions - so I granted it the log on locally permission as well. Still to no avail.
I have also tried disabling the windows firewall and connecting to both the machine name and localhost just in case there was some screwy rules regarding localhost - still with the same result.
Other people suggested the execution account in SSRS manager needed be disabled. I didn't set this up initially - but set the account up just in case it had something to do with it - still with the same error then removed it again still with the same error.
Can anyone offer any other suggestions as to what might be the cause and how I might fix this?
Many thanks and Cheers
Rod.
OK - managed to work out the problem and a workaround. But it doesn't actually solve the problem.
Problem is Chrome and IE11 wont update the Reports web site when managing datasources. Even when launched as administrator, the SSRS management interface site does not appear to save the changes. Edge is just a joke so don't even bother with that one.
Now - I figured Microsoft has broken something which SSRS interface needs in windows 10, so I logged onto a Windows 7 machine and using IE11, was able to navigate to report manager site, update the credentials (windows and SQL Server credentials) and the reports run.
Confirmed this by trying to change the credentials back on windows 10 and it immediately broke the reports again. Set the credentials back in Win 7 and it corrected the reports.
So if you are using windows 10 and are having issues configuring credentials for SSRS reports, try logging in from a windows 7 machine and set through IE on that machine.
EDIT: IE11 works on older windows 10 build (enterprise) , latest build (Pro) seems to be broken.
Cheers
Rod.
If you have specified an unattended execution account, SSRS flip-flops between impersonating it and the identity specified in your data source during the rendering process. If you use an unattended execution account, you’ve got to keep the password up-to-date.
You could also choose not to use the unattended execution account at all, which may also solve your problem. For more detail see http://blogs.msdn.com/b/bimusings/archive/2006/08/16/702490.aspx
Simply,
Go to Report Configuration Manager
Go to Excution Account
Enter Domain\UserAccount [User Account is your windows User]
Enter Password [Windows Password]
Save and you are good to go
I have a .Net application that connects to a SQL Server over the network. The user logs in as the Windows user. The SQL Server is set up as Windows Authentication only. From the client machine, the user is not created on the SQL Server as a login yet. On the first startup of the application, the application needs to check if the windows user is a sql server login and if not, the login must be created by the .net application.
My question is with which user do I log in to the SQL Server to check if the login exists. Obviously it cannot be the current windows user, as this user must be created first and on first run does not exist on sql server.
I already know how to proceed once a connection is established, and need help on the correct login to use when the windows user does not exist as a login on SQL server. Keep in mind that the server is set up for Windows Authentication only.
All of this must be done through .net code (vb or c#).
Thanks for the help.
I do not fully understand your question, but answering it upon what I think you are asking:
You need to be logged in as the Administrator in Windows since you are using Windows Authentication Only.
Once you have logged in as Admin, Windows will recognise that and give you all the authentication rights so when you go into your SQL server these rights will automatically be passed on, allowing your to create new user permissions and grant access etc...
Let me know if this answers your question correctly.
I recently installed Microsoft SQL Server 2012 on a fresh Windows 7 installation, but whenever I want to run the server, I get the following error:
Error 1069: The service did not start due to a logon failure.
The following user is configured to start the service: NT Service\MSSQL$SQLEXPRESS
How can I fix this problem?
The answer to this may be identical to the problem with full blown SQL Server (NTService\MSSQLSERVER) and this is to reset the password. The ironic thing is, there is no password.
Steps are:
Right click on the Service in the Services mmc
Click Properties
Click on the Log On tab
The password fields will appear to have entries in them...
Blank out both Password fields
Click "OK"
This should re-grant access to the service and it should start up again. Weird?
NOTE: if the problem comes back after a few hours or days, then you probably have a group policy which is overriding your settings and it's coming and taking the right away again.
This happened to me. A policy on the domain was taking away the SQL Server user account's "Log on as a service" rights. You can work around this using JLo's solution, but does not address the group policy problem specifically and it will return next time the group policies are refreshed on the machine.
The specific policy causing the issue for me was:
Under, Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignments: Log on as a service
You can see which policies are being applied to your machine by running the command "rsop" from the command line. Follow the path to the policy listed above and you will see its current value as well as which GPO set the value.
While ("run as SYSTEM") works, people should be advised this means going from a minimum-permissions type account to an account which has all permissions in the world. Which is very much not a recommended setup best practices or security-wise.
If you know what you are doing and know your SQL Server will always be run in an isolated environment (i.e. not on hotel or airport wifi) it's probably fine, but this creates a very real attack vector which can completely compromise a machine if on open internets.
This seems to be an error on Microsoft's part and people should be aware of the implications of the workaround posted.
Short answer:
install Remote Server Administration tools on your SQL Server (it's an optional feature of Windows Server), reboot, then run SQL Server configuration manager, access the service settings for each of the services whose logon account starts with "NT Service...", clear out the password fields and restart the service. Under the covers, SQL Server Config manager will assign these virtual accounts the Log On as a Service right, and you'll be on your way.
tl;dr;
There is a catch-22 between default settings for a windows domain and default install of SQL Server 2012.
As mentioned above, default Windows domain setup will indeed prevent you from defining the "log on as a service" right via Group Policy Edit at the local machine (via GUI at least; if you install Powershell ActiveDirectory module (via Remote Server Administration tools download) you can do it by scripting.
And, by default, SQL Server 2012 setup runs services in "virtual accounts" (NT Service\ prefix, e.g, NT Service\MSSQLServer. These are like local machine accounts, not domain accounts, but you still can't assign them log on as service rights if your server is joined to a domain. SQL Server setup attempts to assign the right at install, and the SQL Server Config Management tool likewise attempts to assign the right when you change logon account.
And the beautiful catch-22 is this: SQL Server tools depend on (some component of) RSAT to assign the logon as service right. If you don't happen to have RSAT installed on your member server, SQL Server Config Manager fails silently trying to apply the setting (despite all the gaudy pre-installation verification it runs) and you end up with services that won't start.
The one hint of this requirement that I was able to find in the blizzard of SQL Server and Virtual Account doc was this: https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts, search for RSAT.
I had a similar issue that was resolved with the following:
In Services.MSC click on the Log On tab and add the user with minimum privileges and password (on the service that is throwing the login error)
By Starting Sql Server to run as Administrator
If the user is a domain user use Domain username and password
One possibility is when installed sql server data tools Bi,
while sql server was already set up.
Solution:-
1.Just Repair the sql server with the set up instance
if solution does not work ,
than its worth your time meddling with services.msc
I don't know how good of a solution this is it, but after following some of the other answer to this question without success, i resolved setting the connection user of the service MSSQLSERVER to "Local Service".
N.B: i'm using SQL Server 2017.