I have setup ADFS v5 on Windows server 2019.
I am trying to sync users from AD and store them to my application database. During this synchronisation process I am getting following error :-
System.DirectoryServices.DirectoryServicesCOMException (0x8007202C): The server does not support the requested critical extension. at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()
Also I am getting this time out period expired error sometimes
System.Runtime.InteropServices.COMException (0x800705B4): This operation returned because the timeout period expired. at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()
In order to fix this in ADFS management I have setup Web SSO Lifetime value as 480minutes & for one of the relying party configured I have TokenLifeTime set to 480
Do I need to change TokenLifeTime for all the relying parties configured?
Still same time out error is coming. I am new to ADFS I am not sure which configuration is incorrect.
Could you please suggest what all configuration changes I need to tweak in order to fix this.
Related
I'm close to desperate. My ASP NET website keeps crashing and I get 503 service unavailable.
I am using hostgator shared hosting. They say that the 503 error is triggered in IIS by the fact that the app gives more than X errors in a short amount of time.
I don't have direct access to the server logs, but what they've sent me looks like this:
Event code: 4005
Event message: Forms authentication failed for the request.
Event time: 4/11/2018 12:18:30 PM
Event time (UTC): 4/11/2018 5:18:30 PM
Event ID: 15efc898b8054a1e8aef9915b181307e
Event sequence: 6
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /blah blah
Trust level: HG_Full
Application Virtual Path: /
Application Path: [somethingsomething]\httpdocs\
Process information:
Process ID: 50012
Request information:
Request URL: [somethingsomething]/login.aspx
Request path: .../login.aspx
I do use forms login on the website, but it never created any problems. What should I do?
Right now the only solution is that I call them and they reset the application pool which is very frustrating as I have to go through their call center.
I can't make the site give any visible error in the login page, no matter what I do.
I've already read other posts indicating that I can hide the error in the global.asax by clearing the error in application_error, but I have my doubts that this is the way to go
I also had authentication > forms timeout set very high, I now changed it to 30 minutes - not sure if that did anything since I can see that the cookie expiration date generated is 1969
please help!
here's the hosting provider description:
Per the time stamps these errors are occurring in approximately one minute intervals. Please bear in mind that after a website has hard-crashed multiple times in close succession the Rapid Fail Protection feature of IIS will be triggered which monitors your site for hard-crashes, and if a certain number of errors occur in a certain amount of time then the site will be deactivated with a 503 error message in order to protect the stability of the server. If the site hard-errors more than 5 times in 5 minutes then the website is most likely malfunctioning, or exceeding its allocated resources in the shared environment, and will need to be reviewed by a developer to determine what aspect of the site is causing the application pool to crash.
This is an intentional configuration of the server to help ensure that no single user impacts other shared users by causing resource exhaustion issues on the server.
By default, if application pool crashes more than 5 times in 5 minutes, you will receive a 503 service unavailable error.
Now important question here is to find out why the application pool is crashing. There could be multiple reasons for it and Forms authentication is definitely not one of them. Here is what you can do.
Reach out to the service provider and request for "System" logs from Event Viewer during the time of issue. You will find either of the following error messages.
A process serving application pool '%1' suffered a fatal communication error with the Windows Process Activation Service. The process id was '%2'. The data field contains the error number.
A process serving application pool '%1' terminated unexpectedly. The process id was '%2'. The process exit code was '%3'.
Once you identify that application pool is crashing, check with the hosting provider if you could set up a rule to capture a dump of the w3wp process. Analyzing the dump will tell you exactly what went wrong within the application.
More details in setting up a crash rule here
Let me know if you have any follow up questions.
i had bought a web domain online where i am hosting asp.net website's/web-application's.
Many a times I am facing an error:
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster......
After a long research i had found that the error occurs due to "Application Pool Idle Timeout".
By default an app-pool will recycle every 5 minutes. If this recycle happened while a user is busy on the site and send post back to the server, the server no longer recognizes the session/viewstate and rejects what is being posted back.
My "Application Pool Idle Timeout" value is around 5 min. which is too short.
i had contacted the domain person to change the timeout period but they refused to do so saying its same for all and cant be changed.
I had googled for other solutions and found the below solutions:
Setting the EnableViewStateMAC property to false (Not good w.r.t. security reasons).
Provide your own validation and decryption keys "" (Doesn't work).
Please provide me a better solution ASAP.
Or Should I change the domain manager (like godaddy.com).
I have seen and resolved this issue in past. This issue majorly comes when you host application on Web Farm or web Cluster.
When a page is rendered, its view state is encrypted on server and sent to client. When page is posted back, this view state data is decrypted on server to get the state of the page. For Encryption and decryption of viewState server uses some keys, which if not provided in Maching.config files, are generated on the fly by server.
If you are on a single server hosting environment, these keys might get recycled. But on a Web Farm or Web Cluster, if these keys are generated at random then they are different for every server, and a request from one server can be posted back to another server that has different set of key and where it fails.
Solution to this is Adding MachineKey entries to all the server's Machine.Config files, or to your application's web.config files so that each server uses same keys for encryption and decryption of view state.
When a unavailable url is accessed, we internally raise an exception and email to support team. We do this to identify is there is hidden error in our web application. Couple of days back, suddenly there was a huge number of access to unavailable url which added load to server and casued SMTP to queue large exception emails. This attempt has brought IIS completely down and none of the applications are accessible.
How to prevent this? Is there any other option like firewall etc to disallow continues request from same ip. I have seen this behavior in google. How can we achieve that?
I'd suggest caching already sent notifications. Before your application sends email, it can check if this error is already reported.
And you can set the cache validity to, say 1 minute, so you get maximum 1 same email/minute.
It is quite easy to implement in ASP.NET.
(This is a question about a vague problem. I try to present all relevant data, in the hope that someone has helpful information; apologies for the long description.)
Our web app
We have a .NET 4 web application running in IIS 7.5 accessing Active Directory and a SQL Server database.
This web application is running under a virtual 'app pool identity', by setting the Identity of the application's application pool to ApplicationPoolIdentity. A concise description of virtual identities can be found in a StackOverflow answer, and the blog post to which it refers: an app pool identity is just an additional group which is added to the web application's worker processes which is running as 'network service'. However, one source vaguely suggests that "Network Service and ApplicationPoolIdentity do have differences that IIS.net site documents do not publish." So a virtual identity might be more than just an additional group.
We chose to use ApplicationPoolIdentity, as opposed to NetworkService, because it became the default in IIS 7.5 (see, e.g., here), and per Microsoft's recommendation: "This identity allows administrators to specify permissions that pertain only to the identity under which the application pool is running, thereby increasing server security." (from processModel Element for add for applicationPools [IIS 7 Settings Schema]) "Application Pool Identities are a powerful new isolation feature" which "make running IIS applications even more secure and reliable. " (from IIS.net article "Application Pool Identities")
The application uses Integrated Windows Authentication, but with <identity impersonate="false"/>, so that not the end user's identity but the virtual app pool identity is used to run our code.
This application queries Active Directory using the System.DirectoryServices classes, i.e., the ADSI API. In most places this is done without specifying an additional username/password or other credentials.
This application also connects to a SQL Server database using Integrated Security=true in the connection string. If the database is local, then we see that IIS APPPOOL\OurAppPoolName is used to connect to the database; if the database is remote, then the machine account OURDOMAIN\ourwebserver$ is used.
Our problems
We regularly have issues where a working installation starts to fail in one of the following ways.
When the database is on a remote system, then the database connection starts to fail: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors." The previous error is "Error: 18456, Severity: 14, State: 11." So it seems that now OURDOMAIN\ourwebserver$ is not used anymore, but instead anonymous access is attempted. (We have anecdotal evidence that this problem occurred when UAC was switched off, and that it went away after switching on UAC. But note that changing UAC requires a reboot...) A similar problem is reported in IIS.net thread "use ApplicationPoolIdentity to connect to SQL", specifically in one reply.
Active Directory operations through ADSI (System.DirectoryServices) start to fail with error 0x8000500C ("Unknown Error"), 0x80072020 ("An operations error occurred."), or 0x200B ("The specified directory service attribute or value does not exist").
Signing in to the application from Internet Explorer starts to fail, with HTTP 401 errors. But if in IIS we then put NTLM before Negotiate then it works again. (Note that access to AD is needed for Kerberos but not for NTLM.) A similar problem is reported in IIS.net thread "Window Authentication Failing with AppPool Identity".
Our hypothesis and workaround
At least the AD and sign-in problems always seem to go away when switching the application pool from ApplicationPoolIdentity to NetworkService. (We found one report confirming this.)
Page "Troubleshooting Authentication Problems on ASP Pages" has some suggestions related to primary vs. secondary tokens, and what I find encouraging is that it links the first two of our errors: it mentions NT AUTHORITY\ANONYMOUS LOGON access, and AD errors 0x8000500C and "The specified directory service attribute or value does not exist".
(The same page also mentions ADSI schema cache problems, but everything we can find on that topic is old. For now we consider this to be unrelated.)
Based on the above, our current working hypothesis is that, only when running under a virtual app pool identity, our web application (IIS? worker process?) suddenly loses its primary token, so that IIS only has a secondary token, so that all access to Active Directory and SQL Server is done anonymously, leading to all of the above errors.
For now we intend to switch from ApplicationPoolIdentity to NetworkService. Hopefully this makes all of the above problems go away. But we are not sure; and we would like to switch back if possible.
Our question
Is the above hypothesis correct, and if so, is this a bug in IIS/Windows/.NET? Under which circumstances does this primary token loss occur?
Through Microsoft Support I found out that we ran into the issue described in Microsoft Knowledge Base article KB2545850. This only occurs when ApplicationPoolIdentity is used. It occurs very easily, namely, after the machine account password is changed (which by default happens automatically every 30 days), and then IIS is restarted (e.g., through iisreset). Note that the problem goes away after a reboot, according to Microsoft and our observations.
According to Microsoft it is not possible to check if your Windows/IIS has gotten into this state.
Microsoft has a hotfix attached to this KB article. There is no indication when that hotfix will be rolled into an official delivery, and the hotfix is already 10 months old. In our specific case, we decided to switch to NetworkService instead.
See https://serverfault.com/a/403534/126432 for my comments on the same problem/solution.
Using the hotfix you linked to allowed me to get ApplicationPoolIdentity working as the docs say it should. This hotfix doesn't specifically describe a solution for accessing network resources as NT AUTHORITY\ANONYMOUS LOGON, but it's related to the computer password changing. Bottom line is that it worked for me, at least so far.
This is also relevant for Umbraco using Active Directory authentication.
From time-to-time you may get this exception:
Configuration Error
The specified directory service attribute or value does not exist
This is apparently caused by the problem outlined here. A reboot invariably fixes it.
I have an ASP.NET MVC intranet site that uses Windows Authentication (Kerberos) exclusively with pass-through authentication. It is setup to use an app pool (v4/integrated) that uses the Network Service identity. The web site provides a pretty UI on top of a network share that is hosted on another machine (SAMBA NAS box). Occassionally (and usually when someone hasn't accessed the site for a while), clients are getting a 401 authorization error at the point the MVC code is trying to get directory info (System.IO.Directory.GetLastWriteTime) on the remote UNC share. The event log on the IIS machine captures a security audit failure at this same point in time:
+ System
- Provider
[ Name] Microsoft-Windows-Security-Auditing
[ Guid] {54849625-5478-4994-a5ba-3e3b0328c30d}
EventID 4625
Version 0
Level 0
Task 12544
Opcode 0
Keywords 0x8010000000000000
- TimeCreated
[ SystemTime] 2012-03-17T00:43:50.522Z
EventRecordID 398873
Correlation
- Execution
[ ProcessID] 696
[ ThreadID] 792
Channel Security
Computer lvtloweb1.acme.com
Security
- EventData
SubjectUserSid S-1-0-0
SubjectUserName -
SubjectDomainName -
SubjectLogonId 0x0
TargetUserSid S-1-0-0
TargetUserName
TargetDomainName
Status 0xc000006d
FailureReason %%2304
SubStatus 0xc0000133
LogonType 3
LogonProcessName Kerberos
AuthenticationPackageName Kerberos
WorkstationName -
TransmittedServices -
LmPackageName -
KeyLength 0
ProcessId 0x0
ProcessName -
IpAddress -
IpPort -
The weird thing is that if you sit and refresh the page over and over, it usually get's past the 401 error in about a minute. Anybody got any ideas on how to troubleshoot such a problem? Oh yeah, the IIS machine is hosted in a VM. The guest OS is Windows Server 2008 Enterprise 6.0.6002 Service Pack 2.
Keith,
Being that it appears to happen most after the user has been idle, I'm leaning towards some kind event (i.e. a session timeout) that might invalidate the credentials for your server. I'm assuming one server since you didn't mention any web farm.
A part of me thinks you've likely hammered the session timeout angle. Unless you felt safe trusting that the users would 'auto authenticate' and timing out mid operation wouldn't cause it to fail. That said, I'm not sure I'd completely trust that is the case. To at least eliminate this possibility I would add a routine that logs information about the current session/credentials before that operation is started. Even though the user is "always logged in" assuming they are on their computer I've seen weird issues with VPNs, proxy servers, server double hops, IE configurations for 'trusted zones' and 'intranet' settings. Even a computer suddenly having its route to the server changed could cause issues. I'm not sure the network emulation on a VM would play a part, but who knows.
Here is a 'starter' article regarding IE and it's complex approach to authentication and the role it plays as the client application accessing your Intranet MVC app. (It pays to dig deep on how IE auto-magically authenticates in a Windows AD environment.)
http://support.microsoft.com/kb/258063/en-us
Here is a related problem someone had due to a double-hop causing 401s. I've also included a link to another good 'starter page' on investigating these types of issues.
http://social.msdn.microsoft.com/Forums/en/sqlreportingservices/thread/6d1604e5-e739-41e4-89a5-c6681bff2e61
http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx
Sorry if anything above you already knew or for the general nature of my response. It's tough without actually having network access or being able to add logging to your code. I hope I've pointed you in the right direction.