Can anyone explain why the following happens:
My ASP.NET application requires access to Application event log.
When I access web application initially, it returns "Security" exception (which is expected, as I haven't granted permissions to write to Application event log yet).
Then I give read/write permissions to IIS_IUSRS group on the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog. As a result of this action my web application starts working.
Now I remove those permissions I've granted to IIS_IUSRS group. But
my web application keeps working (although I'd expect "Security" exception raised again)
So, why web application keeps working, although permissions to write to Application log
have been removed?
There is a difference between the permissions required to create an event source in the event log, and the permissions required to write to an existing event source. A higher permission is needed to create the event source.
Here's a source re accessing the event log:
Least privileged accounts have
sufficient permissions to be able to
write records to the event log by
using existing event sources. However,
they do not have sufficient
permissions to create new event
sources.
It could be so that the permission to open the event log is caches as long as you do not restart the ASP.NET application and/or IIS. Depends on how you have done in your code.
Related
I have two ASP.NET web applications and in both I use EventLog.WriteEntry with a custom source name to write custom events to the application log.
Both on my programming machine and on the webserver this works in one of the applications, in the other it doesn't - I get a security exception:
[SecurityException: The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.]
I am wondering why this happens, both web applications are identical (as far as I see it). The only difference from a security point of view is the authentication mode: one uses Forms (there Eventlog.WriteEntry works) and one uses Windows (here it doesn't work). Can this be the reason?
Giving "everyone" read access to the application log doesn't change this behavior.
Your problem on Windows authentication mode essentially similar with these problems:
System.Security.SecurityException when writing to Event Log
System.Security.SecurityException: The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.
The exception means that your web app tried to write on event log using a value given to "source" which has not been registered due to insufficent privilege on corresponding account.
When using Windows authentication mode to perform event log tasks, you need to give read permission on NETWORK SERVICE account on eventlog\Security key. Below are these steps to do:
Open Regedit (Registry Editor).
Go to HKLM\SYSTEM\CurrentControlSet\services\eventlog\Security
Right click the branch, select "Permissions".
Click "Add", find RDN named NETWORK SERVICE or type it directly, then add the account.
Under "Permissions for Network Service", check "Read" or "Full Control" to give the read permission, then apply the change.
Restart your application pool on IIS host.
If it still not enough, do actions below:
Open IIS Manager. Check the Identity column on Application Pools section, it should given LocalSystem or NetworkService.
When you need to change Identity, right click the application pool with Windows authentication, choose Advanced Settings.
Under Process Model, change ApplicationPoolIdentity to LocalSystem or NetworkService, apply your edit and restart the application pool.
NB: NetworkService identity is more preferred to LocalSystem due to security vulnerability reasons.
Also you may try setting <trust level="Full" /> in web.config file, depending on security consideration.
If all solutions above still won't work, set Visual Studio on development machine or deployed app on web server to run as administrator privilege, gaining full access to Windows authentication event log. After all, it depends of your choice to ensure proper security measure was applied.
We've created a windows authenticated sub directory on our web server, however, intermittently when we go there (once logged in as an authenticated user - member of a authenticated group) we get the following error:
Module IIS Web Core
Notification BeginRequest
Handler Not yet determined
Error Code 0x80070005
Config Error Cannot read configuration file due to insufficient permissions
Config File \\?\C:\Inetpub\wwwroot\admin\web.config
Requested URL http://testsite.dev:80/admin
Physical Path C:\Inetpub\wwwroot\testsite\admin
Logon Method Not yet determined
Logon User Not yet determined
The odd thing is once we see this error, hit F5 or refresh and the error goes away, only to reappear a short time later. Very frustrating!!
I have done extensive searches online, but can find nothing. We may also create other sub dirs allowing the same "group" to have access, so this needs to work across all these subs without having to relog in.
We are using IIS7. I've found guides that state for IIS7 ( http://kenno.wordpress.com/2008/10/23/iis7-cannot-read-configuration-file-due-to-insufficient-permissions/ ) but when I do this it seems to then make the directory accessible to all which is clearly not required.
Following my own advice and knowing nothing about the problem, I give you an answer to be accepted or improved upon:
Set IIS_IUSRS to have read access on your windows authenticated directory.—user901820
Configure access in IIS Manager | Your Site | Authentication. Make sure you have disabled "Anonymous Auth" for that folder—this should close it for everyone. If you now enable another Auth method for that folder ... then user should only access it if he provides proper login details.—LazyOne
See Configuring Security at IIS.net.
My ASP.NET MVC 2 application runs under built-in local NETWORK SERVICE account. I want to set up access permissions for the folder which resides in another computer, but in the same domain. I located that folder right-clicked to open its properties form, clicked to Security tab and pressed Add button which displayed Add user form with correct domain name in the location field. I referred to the account with following syntax:
<domain name>\<server name>$
because I learned that NETWORK SERVICE account uses machine account when connected to other computers in the domain.
However, the system couldn't find the account, so refuses to add the account. Without the domain name it adds a user, but that user seems to be local user, not web server's NETWORK SERVICE account. What am I doing wrong?
By the way, the above syntax worked when I created login for the sql server which is different computer from the web server.
OK, I will answer my own question. The above syntax \$ was correct. Just make sure to select computers checkbox in the object type, when adding user permissions.
I have been in this same situation before. I don't think I got it to work with the Server/Network Service but this might be worth a try.
Figure out the account network service is using to access the network resource.
Configure windows auditing (on the server the folder is located) to log the failed security events of the folder.
or monitor the folder with something like filemon.exe
.. from here you can try and add the account to the security settings of the forlder. (IIRC I did'nt ever get this to work)
Alternatively you can ensure the action is performed under the context of a domain user. Either by:
Impersonating the user in code and performing the action (my preference)
Setting the impersonation settings in web.config to a named user
setting the application pool to run as a domain user.
I am working on ListView, displaying data from database, when i run my application i am getting this problem "Login failed for user 'IIS APPPOOL\DefaultAppPool' ",
not getting the exact problem.
This means that the account your application pool is running under in IIS does not have any permissions on the SQL Sever.
See here for how to change that account, you need to either set a different account, give the account that it's running under permissions in SQL server, or both.
I have written a web service that reads from a message queue.
This works fine under Cassini.
Now that I have deployed the service under IIS, I receive an error message when the service tries to access the queue:
The queue does not exist or you do not have sufficient permissions to perform the operation.
I have set the anonymous access user on the IIS virtual directory to be my own domain account, which is a member of the administrators group on the local machine. I have granted this same user full permissions on the queue, as well as NETWORK SERVICE and ASPNET.
I still get the same error message.
I have also tried disabling anonymous access on the virtual directory and connecting to the service using my own login details - to no avail.
Any help with this problem will be greatly appreciated!
I have also tried various combinations of:
and
With testUsr having full permissions on the queue. I have added permissions for the user and ASPNET on the MSMQ store folders on C:\
My understanding of the problem is that the process trying to execute the code is running as a different account under IIS than it does under Cassini.
The problem was that regardless of which user I impersonated - I always got the same error message - even when the user was a member of the local and domain administrator groups, and this user had full permissions on the queue. i.e. It is barely possible to assign more rights to a user.
It turns out, that using a FormatName for the queue, rather than a path name (myMachine\queueName) has solved the problem...
FormatName:DIRECT=OS:myMachine\myQueue
I am uncertain as to exactly why this is the case. Reading up has showed that when a path name is used, there is a necessity for an AD lookup, and although I think that the users that I have been testing with should have rights to do this, perhaps there is something missing.
However the immediate problem is solved and that's good enough for me.