I have a ASP.NET 4.5 application that runs in an application pool with a particular domain user name and password. It's been working fine for months. A few days ago, there was an Active Directory issue whose details remain unknown to me, but my application users reported around the time of the issue that they were unable to use the application.
The AD issue was eventually "resolved," but the users still could not use the application - until I recycled the application pool.
Before the recycle, I was catching this first-chance exception:
System.Runtime.InteropServices.COMException (0x8007052E): The user name or password is incorrect.
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
After the recycle, I stopped seeing this exception.
The exception itself was being generated by a call to PrincipalContext.FindByIdentity that was failing until I recycled the app pool.
Why on Earth would an app pool recycle change the behavior of PrincipalContext if the app pool credentials didn't change?
App Pools using domain accounts work with the AD domain controllers to validate the domain user.
Since we don't know what happened in your Company with AD we can't definitively say why. We can only assume or conjecture that it appears to have caused this to go wrong.
Resetting the pool after AD was happy again reset this magic. Magic - as in I don't actually know under the hood mechanics but the app pool relies on AD to authenticate the domain user.
Your default app pool recycle time of 29 hours would have eventually fixed it as well. You just did this yourself.
Related
I have a web application developed in asp.net
The application has a "logon" portal where I record users logging on. However, I don't really know when they have exited the web application as they could just shut down the browser, rather than using the "logout" option. As IIS keeps track of session variables for a finite period when users logon, I thought a really useful option would be to use my ASP.net application to interrogate IIS for the value of all session variables, thus telling me who is still active via their session variables.
This could be very useful when it comes to dropping in an upgrade to the website and generally looking at the use of the site.
Thanks
session object. But it only tells me about the current user.
We recently had to change a domain admin password due to a security issue. As a result, on our prod web server, we're seeing a large number of Event ID 4625 errors showing up in our security log associated with an IIS App Pool. We're on Windows 2012 R2/IIS 8.5; ASP.NET 2.0 & 4.0 are installed on the system.
The interesting piece is that the App Pool in question never used the domain admin account as its Identity. It has always used the out of the box ApplicationPoolIdentity. I should also note that the server was logged off using that affected user well prior to the password change & a new account is now used to administer the server.
The server itself though was in fact built using the affected domain admin account. All roles/features were added while logged in as the aforementioned account. With this in mind, no services are running as the account, ie World Wide Web Publishing Service/IIS Admin service. They're running as Local System & always have.
No functionality has been compromised, everything is operating normally on the web server. The issue is that our tech services team is receiving constant notifications from their account monitoring software regarding the bad logon attempts & it is impeding their operations. Full disclosure... We haven't had an opportunity to reboot the server yet since its production, we will be doing that tonight.
The problem seems to be relegated to the root of the site, the \wwwroot folder. Segregating only the root app to its own app pool/turning off the pool is not an option since it services file system requests. We've tried explicitly setting the identity on the affected app pool to use Local Service as well as a regular domain user. The issue persists regardless:
So naturally, our hope is that the reboot takes care of it... Perhaps the old password is stuck in a kerberos cache, but it's just strange since this app pool never used the ID as its identity, that it continues to show up.
We had a virtual directory that was using the ID in order to reach out to a CIFS share on the network. Once we changed that, the error ceased.
Our site is an ASP.NET MVC site, hosted on Azure and using Azure cache service as session provider. Below is our sessionstate configuration:
The cache in Azure is configured to use sliding expiration, with expiration period of 2 hours
Recently we have an issue of users suddenly being kicked out of the website. There is no exception during that time, except for SecurityException which we throw if user's not logged in. It seems that suddenly user's session is lost and ASP.NET assigns them a new session
As far as we know, since the site is using distributed session state provider, even if the server application pool is recycled, it should not kick out the user/cause session lost
May I know what are the possible causes for this issue? Is it due to distributed cache session provider or due to IIS or due to our site? How should we debug this issue?
Below is our production server IIS application pool setting
Thank you very much
I have a website in IIS 6.0 using an application pool with a custom service account. When I browse the website, I get an error "service unavailable" and the error in event log says
The identity of application pool 'SampleAppPool' is invalid, so the World Wide Web Publishing Service can not create a worker process to serve the application pool. Therefore, the application pool has been disabled.
I think the utility "Aspnet_regiis" can be used to grant access to an account to IIS metabase according to this article, but is that the right way to fix this issue? Because this utility is used for multiple things and may do more than just granting the permissions to the account, or should I just add the account manually to IIS_WPG group?
When I see this in IIS 6 and the user has a custom app pool identity, the problem typically originates in the entry of credentials in the app pool properties. So there are generally two origins for the issue.
One is a simple typo in the credentials, unfortunately the form validation is not very good in IIS 6, so I often will have users change the identity of the app pool, then immediately check that the credentials "took" and/or check the System event log for W3SVC and related errors.
The second specific cause I see in this scenario is when people enter an Active Directory user, they sometimes forget to add the domain name. (e.g. DOMAIN\Username). Which leads me to the next point, the IIS_WPG is the builtin local group which grants members the required ACLs to run as an app pool identity. The aspnet_regiis.exe -ga grants the same thing to users, but IMO it is best suited for use when the IIS_WPG group is not an option. Also a dedicated app pool user account is generally a good idea. If the AD user password is changed, you'll bring your app to its knees until you again re-enter the credentials in the IIS Manager.
Edit: I added some para breaks to make this chunk more readable.
I had this same problem and I resolved it by starting the application pool. Ours was stopped even though IIS was running.
"The identity of application pool 'SampleAppPool' is invalid..."
Every time I have had that error, it was because the user name and password where not correctly entered in the application pool. This happens also when you import the pool settings from another server. Reentering the password in the application pool identity configuration has always solved the problem.
Once you get that right, you will probably meet the second problem you are describing, but that's an unrelated issue. It can be fixed as you describe, or even manually granting the required access permissions to the application pool identity.
If you are connecting to a remote machine using one or more remote access tools, take note: your keyboard mappings may be getting screwed up somewhere along the way!
In my case, I tried typing out certain letters of the password in a plain text editor on the remote machine (not necessarily in the same order, to retain security). When attempting to type the dollar character, I found that if I used the left shift key I got a "$" but if I used the right shift key I got a "4".
Once I had that figured out, I could enter the correct password for the Application Pool Identity. (Note: when filling out the identity section, IIS does not validate the password you enter against the user identity, only that the two passwords you enter match each other).
My application is running in a shared hosting environment. I do have a dedicated App Pool for my app. I've been doing some testing with 1st visits and precompile performance and have been tracking when my application starts up and shuts down.
In my Global.asax I have some logging code in Application_Start and Application_End. I can see from my logs generally when the application is idle and shuts down, then someone visits and it starts back up.
But, I also see cases where a shutdown is logged and then followed by another shutdown about 13 minutes later; without a startup in the middle.
I also see instances where there are two Startups in a row. I'm guessing these might be a recycle, but why wouldn't there be a shutdown log entry?
What I'd really like to know if there is a better way to track when my application starts, when it shuts down and if it is shutdown due to an idle pool, or from a recycle. I don't have access to the Windows Event Log so I need to do this from my app if possible.
Application_Start and Application_End should only be called once per lifetime in your application, MSDN confirms this.
Without knowing your hosting environment it is possible that your web host is running your website over multiple worker pools or IIS instances. Your application pool could also be unexpectedly crashing due to other apps in the pool.
Without access to the Event Log or anything other than a basic web host control panel your best way of logging is what you're doing now, using Global.ASAX