Why would my ASP.NET application, running as a domain user, require a restart to use PrincipalContext after an Active Directory issue?
up vote
0
down vote
favorite
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?
asp.net application-pool principalcontext applicationpoolidentity
asked Nov 9 at 18:02
tacos_tacos_tacos
5,800755106
add a comment |
up vote
0
down vote
favorite
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?
asp.net application-pool principalcontext applicationpoolidentity
asked Nov 9 at 18:02
tacos_tacos_tacos
5,800755106
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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?
asp.net application-pool principalcontext applicationpoolidentity
asked Nov 9 at 18:02
tacos_tacos_tacos
5,800755106
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?
asp.net application-pool principalcontext applicationpoolidentity
asp.net application-pool principalcontext applicationpoolidentity
asked Nov 9 at 18:02
tacos_tacos_tacos
5,800755106
asked Nov 9 at 18:02
tacos_tacos_tacos
5,800755106
asked Nov 9 at 18:02
tacos_tacos_tacos
5,800755106
asked Nov 9 at 18:02
tacos_tacos_tacos
5,800755106
asked Nov 9 at 18:02
tacos_tacos_tacos
5,800755106
5,800755106
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
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.
answered Nov 9 at 19:23
klabranche
19.1k24473
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
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.
answered Nov 9 at 19:23
klabranche
19.1k24473
add a comment |
up vote
0
down vote
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.
answered Nov 9 at 19:23
klabranche
19.1k24473
add a comment |
up vote
0
down vote
up vote
0
down vote
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.
answered Nov 9 at 19:23
klabranche
19.1k24473
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.
answered Nov 9 at 19:23
klabranche
19.1k24473
answered Nov 9 at 19:23
klabranche
19.1k24473
answered Nov 9 at 19:23
klabranche
19.1k24473
answered Nov 9 at 19:23
klabranche
19.1k24473
19.1k24473
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53231115%2fwhy-would-my-asp-net-application-running-as-a-domain-user-require-a-restart-to%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
