The error I get is:
Cannot open database "DBNAME" requested by the login. The login failed.\r\nLogin failed for user 'IIS APPPOOL\DefaultAppPool'
Initial connection string is as follows, further in the question I'll only be using only a part of it.
Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=DBNAME;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False;
I believe I have tried everything:
My application that is hosted on IIS is using a
'ApplicationPoolIdentity' as identity. I have tried changing the
identity to other, but to no avail. Only to be greeted by a similar
error, but with a changed user. (Havent tried using Custom account)
Tried sharing my localDB instance
with the following command sqllocaldb share mssqllocaldb IIS_DB.
Restarting the instance, changing my connection string data source
to the following (localdb)\\.\\IIS_DB.
Tried plainly using
SQLEXPRESS instance with the following data source .\\SQLEXPRESS.
I have added IIS APPPOOL\\DefaultAppPool user to all possible places, given full access to everything, allowed Everyone to access the folders where the database is located.
One thing I haven't tried is to try and repeat everything from scratch, since I might've messed something up. All help is appreciated.
IIS: version 10.0.19041.1
SSMS: version 18.12.1
Backend: .NET 6 minimal API + DAPPER
Thank you #Lex Li
I used to login to my PC via the microsoft acc and thus I never did use a windows acc. So whoever stumbles, keep in mind that it's easy to create the acc, windows helps you with that.
Other than that, what I was missing was exactly this. Use your own acc and not a DefaultAppPool (even though it should still work.).
Dont forget to check that your SQL instance is running:
Open cmd and write sqllocaldb i (this should show you all of your instances)
to check whether an instance is running. (It is started when you open your local SSMS and connect to your instance or you run it through cmd): Write sqllocaldb i instancename (should see it as running) - (if you want to restart it, write sqllocaldb stop instancename and then sqllocaldb start instancename.
Other than that, feel free to ask for help in the comments, I might remember this stuff even after a year or two. (Literally spent 7 days on this issue)
Related
I've developing an asp.net core application to tun on a web far, and I'm using "AddDataProtection" to protect for key encryption at rest like, the documentation recommends, but when I deploy my application and run directly from IIS with AppPool identity, the key is never created and I get errors on the DpapiNG windows logs.
My code is the following:
services.AddDataProtection(opt => opt.ApplicationDiscriminator = ApplicationConfig.dataProtectionApplicationDiscriminator)
.PersistKeysToFileSystem(new DirectoryInfo(encKeyPath))
.ProtectKeysWithDpapiNG(string.Format("CERTIFICATE=HashId:{0}", ApplicationConfig.dataProtectionCertThumbprint),
flags: DpapiNGProtectionDescriptorFlags.None);
Debugging from visual studio, everything runs fine, but I'm running VS under administrator rights, so permission is not an issue here.
I've tried adding permissions to the AppPool App user to the private key it self directly from MMC, but it did not worked, and even gave permission on the full path to the location were the keys should be created like stated here https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview (check first comment) but also it did not worked.
I was only able to make it work by setting the AppPool to run with the identity of an Administrator, but clearly this is a no go, I just wanted to make sure this was a permission issue somewhere.
Is anybody facing the same issue that is able to help?
Regards,
André
Most likely your issue is you are trying to store your keys somewhere in a folder path that you are cobbling together (or even by using the default path that AddDataProtection provides) that uses an environment path such as %LOCALAPPDATA%. Example: "%LOCALAPPDATA%\ASP.NET\DataProtection-Keys".
Usually, by default IIS DOES NOT set up your app pool accounts with environment path variables such as %LOCALAPPDATA%. The value ends up being blank and your app then tries to write keys to the wrong folder (such as \ASP.NET\DataProtection-Keys instead of %LOCALAPPDATA%\ASP.NET\DataProtection-Keys).
Fix: Within %WINDIR%\System32\inetsrv\config\applicationHost.config set setProfileEnvironment=true. I think you have to restart IIS as well.
Note: I've found several questions similar on here, but the one's that were resolved did not work for me. So I thought I'd open a new question.
I rebooted our server 2012 box, which hosts our new .net applications. After doing so, I started receiving a 503 error. Upon investigation, it seemed like an identity problem.
Before going much further, I should state that this account has worked for several months now. I've rebooted before, and everything started fine.
So I'm getting the (quite common) 5059, 5057, and 5021 errors in the log. They boil down to this:
The identity of application pool SVFileUpload is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.
I thought I would just ensure the password and account were correct, so I go to the application pool, select identity-> custom and ensure it's set up right. I get an error:
There was an error while performing this operation. Details: Keyset does not exist (Exception from HRESULT: 0x80090016)
This was strange to me, so I tried setting the app pool to a built in account, and it worked fine. I get this error anytime I try to set to a custom account. Also, no app pools that are using custom accounts will run.
I googled a bit, unsure which error was the one I needed to track. I have tried:
registering the account on the command line via the aspnet_ tool
Making sure the user was in the IIS_IUSRS group
changing the permissions on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys file(s)
adding a completely new user and trying to set an app pool to that users account
There was a couple other random things I tried from googling but I don't remember.
This error doesn't make sense to me, and it seems random. I need help figuring out 1) why I can't set an app pool to a custom account and 2) why the identity isn't working for my applications anymore
-Edit
I recently removed and re-added the user account I've been working with. I think that solves that problem. The problem remaining is I can't update the application pool because of the "keyset does not exist" error.
I found a couple of links that led me to a solution.
In c:\windows\system32\inetsrv\config\applicationHost.config I removed all the configProtectedData entries.
Then I removed everything in %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys
I ran iissetup.exe /install SharedLibraries from the inetsrv directory, which resulted in a "Failed = 0x80070005"
I then was able to set up my application pools as if nothing happened.
See also https://techcommunity.microsoft.com/t5/IIS-Support-Blog/Keyset-does-not-exist-exception-from-HRESULT-0x8009000D-or-or/ba-p/342955 for a more detailed explanation
I ran the iisreset command and my problem was sovled
I had the same error-message because my user was not member of the "Local Administrators" group.
I was able to connect to the server because I was member of the "Remote Desktop Users" group.
I was able to open IIS Management and to change settings, but when I clicked on the "OK" or "Save" button - I got the "Keyset does not exist" - error message.
So my advice - check if you are an administrator.
I tried to change the Identity of Application Pool on a remote server and it failed with the above error.
I RDP into the remote machine and then tried to update the Identity using local IIS Manager and it worked.
For anyone on Windows server 2008 stumbling into this error:
this may occur when you are managing the IIS instance from another server using the remote management feature ('connect to another computer').
I resolved by managing the IIS instance from the server itself.
https://support.microsoft.com/en-hk/help/977754/-keyset-does-not-exist-error-message-when-you-try-to-change-the-identi
Since I am working on a fresh server I was able to uninstall the IIS Windows Feature and then re-add it.
I was able to change the App Pool Identity after that with no issues.
delete the rsa found here C:\Users\usernamn\AppData\Roaming\Microsoft\Crypto\RSA
MAKE A BACKUP JUST TO BE SURE WORKED FOR ME
I've been following along with the actual MongoDB docs here
as well as several tutorial articles that are getting me absolutely nowhere.
Running a 64bit windows OS (which is a work computer, and my particular windows login is not an administrator login.. so I make sure to open any exe files as administrator). I can't do anything in the terminal beyond "mongo" or "use [db name]".
I cannot save or add anything like db.testData.insert( j ). Even typing "show dbs", I get an error that says
listDatabases failed:{ "ok" :0, "errmsg" : "unauthorized" } at src/mongo/shell/mongo.js:46
With every example I've followed, I can never seem to be "authenticated" to get past point A. Please help me! I have no idea what I'm doing wrong at this point.
UPDATE:
Sorry for the confusion, everyone. The problem turned out to be that I had an old MongoDB service still running in the background that I needed to disable.
The service must have been turned on while I was testing out some node packages or something. Once I disabled the service, everything started working as expected.
So for those of you who are having trouble, make sure you open up services.msc and make sure nothing is running MongoDB
As there isn't a formal installer for Windows, I'd recommend you delete the data folder and restart. Out of the box, there is no security in MongoDb, so you've followed a step which later requires a password. Either retrace your steps, or start over.
You don't need to switch to the admin Database. I'd suggest you instead switch to a test database for example:
> use test
switched to db test
By default, without extra configuration, on Windows you can delete the contents of c:\data\db when MongoDb isn't running (but if you're using a configuration file that specifies the dbpath, delete the contents of that folder).
There are a number of tutorials with details of how to configure users/security with Mongodb that you may want to read after you've resolved this issue.
There's little reason to create users and administrative control with MongoDB until you gain some experience with the platform. In fact, I wouldn't recommend it at all. It just gets in the way as you're seeing for no real gain.
I have a machine [A] running fresh installation of Win2008 R2 which holds a webapp on IIS. I try to use msdeploy command line tool on machine [B] to publish a deployment package to this machine, but i keep on getting error regarding certificate.
I am using -allowuntrusted, but it still keeps on giving the same error.
I've been trying different things (like changing msdeploy port on IIS, installing certificate on the other machine, reinstall iis roles, tons of other) for 2 days now with absolutely no luck.
This is what I run:
msdeploy.exe -verb:sync -source:package="Web.zip" -dest:auto,ComputerName="https://machineA:8173/msdeploy.axd?site=app.com",UserName="AdminUser",Password="SecurePassword",AuthType="Basic" -allowUntrusted
To make things more interesting, this is what I get when I run the same command on the IIS-containing machine (even after changing dest to sync):
Error: A '-dest' argument must be specified with the 'sync' verb.
Error count: 1.
Any ideas?
EDIT:
I tried using the same settings (ip, package, authentication) in Visual Studio 2012 to create a publishing profile which deploys. After hitting "Verify connection", I got a popup asking if I want to accept this untrusted certificate. I clicked yes and went on to publish - that went through just fine.
Is there a way to get this behaviour with msdeploy command line? Using VS2012 is not an option for me, since publishing must be done automatically.
EDIT 2:
The fun continues: it works on another Windows Server 2008 R2 target machine (not a clean install though). So, where's the magic checkbox? :)
So, I managed to figure out 2 solutions:
Get a valid certificate (we had one in company, so playing around with hosts on machine [B] to match IP with company's domain, helped).
Place "-allowUntrusted:true" BEFORE "-dest" instead of at the end. No clue why does it work on one but not another machine.
Hope this helps someone to save some time :)
I see some problems with the command:
Unless you have changed the default port, you should be using 8172 and not 8173.
Secondly there is a double quote before securepassword but I don't see a closing double quote.
Your package most likely has some default parameters for which you must be specifying values during deployment.
msdeploy.exe -verb:sync -source:package="Web.zip" -dest:auto,ComputerName=https://machineA:8172/msdeploy.axd?site=app.com,UserName="AdminUser",Password="SecurePassword",AuthType="Basic" -allowUntrusted -setParam:paramname=value
I now have my Windows Azure environment set up so that I can access my Worker Role with Remote Desktop. However, I'm not sure how to proceed at the moment. After much digging I found a web site that was offline but in Google's cache there was mention of attaching to the Worker Role running in the Azure Cloud from the Visual Studio debugger. But I only have Visual Developer (not studio) 2010 and I have searched all over and as far as I can see there is no such option to attach to a remote server. I am able to publish my project to the Azure Cloud without error and I have a "healthy" instance of my Worker Role showing as active and running.
I did connect with RDP through the Azure Management portal. The login worked fine and up came the remote desktop window. I searched through much of what I could find and was unable to find my Worker Role. I must have the wrong impression of RDP, because I had hoped to see the Worker Role's main display form when I logged in, just like I do when I debug it locally in the Cloud Emulator. But instead all I saw was a blank desktop with some base level server inspection and management routines. I even checked the Event Viewer for Application related messages and saw none.
So now I'm stuck wondering if my Worker Role is actually running or not, despite the seemingly positive status messages from the Management Portal, and I still want to attach to my Worker Role for debugging through Visual Developer, if it's possible, but I am unable to figure out how.
Anyone with experience in this area that can give me some solid tips on what to do next, please respond.
UPDATE: I believe my worker role may be running because I opened a command window and did a Netstat and saw it listening on the correct port. However, that may just be my Worker Role shell class that starts the custom EXE I have it launch as a spawned proces. I still haven't confirmed if my custom EXE is running yet.
UPDATE-2: Just ran TaskList from a command window and the custom EXE is listed.
UPDATE-3: Everything is working as I just ran a remote test of the service so that's not a problem. Still want to know how to attach to the Worker Role from Visual Developer 2010 for remote debugging, and if it's possible to see the custom EXE's display form like I do when doing local debugging in the Cloud Emulator.
-- roschler
There is a set of articles here which goes in length on how to set up for remote debugging in Azure:
http://blogs.u2u.be/peter/post/2011/06/21/Remote-debugging-an-Azure-Worker-role-using-Azure-Connect-Remote-desktop-and-the-remote-debugger.aspx
http://blogs.u2u.be/peter/post/2011/06/24/Remote-debugging-an-Azure-worker-role-using-Azure-Connect-remote-desktop-and-remote-debugger-part-2.aspx
http://blogs.u2u.be/peter/post/2011/06/26/Remote-debugging-a-Windows-Azure-Worker-Role-using-Azure-Connect-Remote-desktop-and-the-remote-debugger-part-3.aspx
The key takeaway is that you don't need to actually install Visual Studio on Azure, you only need to copy the Remote Debugger bits and then use Azure Connect to add your developer machine to the Virtual Network.
You can setup Remote Debugging with Visual Studio 2012
http://code.msdn.microsoft.com/Remote-Debugging-Windows-dedaaec9
When you say:
But instead all I saw was a blank desktop with some base level server inspection and management routines.
this is exactly what you get with an Azure VM. It's a basic OS install, plus the bare minimum of Azure stuff it needs to run and the code you've uploaded. There's no fancy monitoring or health checks available on the machine by default, you're expected to have provided those yourself to have them available without having to RDP into the machine to check on it.
RDP is very good for tracking down certain problems, like checking that a startup task will run, checking which directories items are installed in and just generally being nosey. If you need extra tools to track down a problem, you can just install them while you're connected to the server. For example I have RDPed into a server and installed the Microsoft Debugging Tools, to track down a memory issue.
I suppose you could remote into your VM, install Visual Studio there, and debug the process...
I also suppose it might be possible to enable remote debugging (not sure what's involved there, but such a thing exists, and it works over TCP) and debug from a local instance of Visual Studio.
To my knowledge, neither is commonly done.
Based on other answers, you would be better off writing a log file to a local storage. You can read the file from RDP if you reallyhace to. Keep in mind, debugging on Azure isn't really simple, and rightly so.
What I was thinking though was, maybe you could run the process using the user's credentials. I can't verify at the moment, but you have a better shot of seeing the ui when you rdp.