I'm getting the error on one server in a load-balanced application:
Failed to decrypt using provider 'RsaProtectedConfigurationProvider'.
Error message from the provider: Not enough storage is available to
process this command.
I tried decrypting the web.config using aspnet_regiis on both servers.
The same server where the issue occurred is not allowing me to decrypt the file. The decryption attempt also throws the same error "Not enough storage is available to process this command.".
I've got tens of gigabytes of free space on both drives on the server. How can I solve this error?
A server admin had copied the encrypted web.config from one server to another.
For this reason, the decryption would not work, even manually. After replacing it, it works fine.
The "insufficient storage" error message was misleading.
Related
(Note: I haven't used MariaDB. I'm only doing research at this point.)
I read MariaDB's TDE / data-at-rest encryption support. In its Limitations section it states, "The MariaDB error log is not encrypted. The error log can contain query text and data in some cases..."
I'm assuming that statement implies query errors that might contain a date of birth (DOB) will be plainly written in the error log. If so, what are the workarounds in order to keep the errors logs secure? If the solution is handling encryption in syslog, would you please explain the process?
In addition, are there any other points listed in the Limitations that a new user like myself should be aware of? I am not familiar with MariaDB's intricacies.
Thanks.
Slow query log, general log and error log are not encrypted.
While slow query log and general log (see MDEV-9639) are usually not used in a production environment, the error log can contain in certain cases (like a server crash) SQL statements which might contain confidential data.
A solution would be to redirect the error log to syslog and to enable rsyslogd encrytion, More information can be found here:
Writing the Error Log to Syslog on Unix
My office recently did some migration of servers, and as a result our webpages now use different data sources. For our environment, we typically use SQL Server, though we also have a linked server to an Oracle database. I am having difficulty finding out where I need to update the username and password for one of our web pages.
Generally speaking, the process has been pretty easy: go to Web.Config, find the connection string that the page is using, and update it with the relevant data source, username, and password. This page, however, is different. First, I get this error when visiting the page:
ERROR [28000] [Oracle][ODBC][Ora]ORA-01017: invalid username/password;
logon denied
ERROR [IM006][Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed
ERROR [28000] [Oracle][ODBC][Ora]ORA-01017: invalid username/password;
login failed
Okay, so obviously I need to update the password somewhere. I go to Web.Config, and I don't see any connection strings. This is a first for me, so I start looking around, and the only thing I see (worth mentioning) is this line:
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1; Trusted_Connection=yes" cookieless="false" timeout="20"/>
To me, this indicates that the database is local, or at the very least my problem lies on the webserver itself. So I remote in, and I check both the ODBC connections for Oracle and SQL Server; no issues. Each of them work. I even check the 32-bit and 64-bit connections.
Googling "Driver's SQLSetConnectAttr failed" tells me it's the ODBC issues, but again...I can't find anything.
Does anyone have any ideas on why I keep getting these errors and what I can do to fix it?
I (well, technically my coworker) found the answer. The answer lied within IIS. Basically, we were missing two connection strings. The first one references the driver, and the second one (I believe) contains the username/password that is passed to the ODBC driver through the first connection string. Whereas normally the connection strings are stored in the program (web.config file), in this case it was on the actual server. The program looked for the connection strings there, but couldn't find it.
I'm trying to setup Pentaho connection with my Oracle DataWarehouse (localhost). However, this error "ConnectionServiceImpl.ERROR_0009 - Connection to database [DBNAME] failed" appears when I try to test the connection.
The information about server should be right, and I also added the JDBC to the tomcat folder.
Error capture
Database Connection information
Check your catalina.out log. You should have the cause of the error there. It could be a bad url, bad db name, bad credentials, missing jdbc driver, among many other reasons.
Catalina.out is inside your tomcat/logs folder by default.
I support an application who call a CMD line to decrypt a file.
The application is a .exe file that is called by the Windows Task Scheduler and is execute as the same user who have all right.
The application run every week day in the evening at 6h30pm and sometimes the CMD line return the message: no secret key.
The application failed because the file was not decrypted. But it doesn't failed every evening, just random evening. It looks totally random.
And if I run the application myself after it failed with the same user, it worked.
The secret key is imported in Kleopatra and it work fine with other application that run in the morning. And it work fine when I used it.
What can cause this?
Thank you
We fix the problem. We must not log off the application user.
If we log off the user, one key is not working, but the others are working.
Some ideas to help you run down the problem:
Check the private keys available to the machine on which the application fails
gpg --list-secret-keys
(IIRC Kleopatra runs on top of GnuPG, so I assume your application does as well. I've been wrong before.) You might notice something out of place with your private (decryption) keys. For example, if the key is listed as either
sec#
ssb>
Then it's a (primary or sub respectively) key located on a smart card for storage. If the card, for whatever reason, isn't in the machine when the app runs it'll fail to decrypt.
Check the disk containing the private keyring is attached/inserted/mounted at the time the application ran and failed to decrypt. If the keys are stored on removable (or unreliable) media then that could also result in a failure to decrypt.
Check that the item failing to decrypt was encrypted properly. If there is some secondary recipient necessary for the app to run there may be a required key that you don't know about (I gather from your post you didn't create this app, just maintain it.) It may even be that the app is trying to decrypt a different file erroneously, but that kind of thing can only be found out by stepping through your source code and resident files.
Failing those, pray for #Jens Erat to notice your question.
We were experiencing errors with one of our web methods on a test web server we have. The main error was:
"Access to the path 'E:\websites\Discovery\ProfileService\App_Data' is denied"
Looking further down the stack trace gives a little more info:
"at System.Web.DataAccess.SqlConnectionHelper.CreateMdfFile..."
"at System.Web.DataAccess.SqlConnectionHelper.EnsureSqlExpressDBFile..."
"at System.Web.DataAccess.SqlConnectionHelper.GetConnection..."
"at System.Web.Security.SqlMembershipProvider.GetUser..."
"at System.Web.Security.Membership.GetUser..."
"at System.Web.Security.Membership.GetUser..."
It appeared that the membership provider was trying to find a connection string for a membership call. On failing to find this entry, it tried to create a new local membership database and failed to do this with a permissions error.
We double checked the connection strings and they seemed ok though they were encrypted. We then saved the config with the connection strings section decrypted - the call now worked!
We know that the connection strings were correct because other service methods were working fine. What is even stranger is that some aspects of membership seemed to work with encryption in place.
Has anyone seen this before or know how to make this work with encrypted connection strings?
In your code, before you make a SQL call are you decrypting the connection strings?
The error from the stack trace is likely that your app doesn't have write permission in that directory.