I am using PingFederate HTML FormAdapter and ADFS for a simple login page and user authentication. If the user keeps the login page open/idle for 10 or more minutes and enters credentials and clicks login, I am getting the below exception. If the login is before 10 minutes, it is working fine. Is there a timeout in ADFS that I can increase?
Encountered error during federation passive request.
Additional Data
Protocol Name:
Saml
Relying Party:
Exception details:
Microsoft.IdentityServer.Web.CookieManagers.InvalidContextException: MSIS7001: The passive protocol context was not found or not valid. If the context was stored in cookies, the cookies that were presented by the client were not valid. Ensure that the client browser is configured to accept cookies from this website and retry this request.
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.GetOriginalRequestFromResponse(ProtocolContext context, Boolean deleteCookie)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
I have seen this issue before. Some things to try:
Verify that the federation service is operating within its operating capacity.
Verify that it is not experiencing network outages.
Check that the IIS supports federation.
You can check this with:
setspn -L <hostname>
This lists current SPNs.
If it is not there, set the SPN
setspn -a http/adfs <machine name> <service account name>
If there is an issue you can re-run the ADFS Proxy wizard and recreate the IIS sites.
Check that the ADFS app pool is running.
Check the troubleshooting guides:
https://social.technet.microsoft.com/wiki/contents/articles/19057.ad-fs-2-x-troubleshooting-proxy-server-event-id-230-congestion-avoidance-algorithm.aspx
https://www.experts-exchange.com/questions/28657729/ADFS-Error-364-Encountered-error-during-federation-passive-request.html
Related
Hi have not been able to find an answer on stackoverflow or online hoping someone has experience of a similar setup.
We have .NET Core 3.1 user management application which obtains user information from a Windows 2016 Active Directory server (application access is done via the groups defined in AD) fairly rudementary the idea is:
Start application > Redirect to WSO2 (version 5.9.0) IAM Logon page
Attemp to logon with a valid AD user (which has been set to 'user must change password at next logon'..)
WSO2 appears to attempt to authenticate and then logon however fails
Kibana shows logon failed message for this particualr user
The WSO2 logon page shows an error message
However what we were expecting to happen was for a redirect to occur back to the .NET Core application and we customised the logon.jsp related pages as per the WSO2 Customisation guide.
WSO2 does not have an identity providers it uses a service provider with SAML SSO configured.
The custom logon.jsp page has some code that checks the incoming RelyingParty value and performs the appropriate redirect as required.
The issue:
The redirect is not working as expected instead of redirecting back to the .NET Core application that made the initial call to the WSO2 IAM the above occurs i.e. the logon page shows an authentication error.
What we would like for the server to do is redirect back the .NET Core application IF the 'user must change password at next logon' radio button is enabled on their AD account - this needs to happen at the server side i.e. WSO2 (well that's my limited understanding if you know better please do advise).
Ideal scenario:
.NET App startup > WSO2 logon page
SAML SSO flow > LDAP query to AD return user
detect the 'user must change password at next logon' is true and then redirect back to the .NET app where the app will take over query AD display the change password views (nothing special about these standard change-password actions)
.NET App > call WSO2 again perform valid logon return with SAML SSO response back to .NET APP.
Thank you in advance :-)
As per your issue description, I believe that you have made the following configuration in the AD.
I believe you have initiated the Admin Forced Password Reset flow by setting the "User must change password at next login" option in the AD for the user. But unfortunately, it is not possible as once the "change password at next login" is selected in the AD, it marks the password as expired and the WSO2 IS treats it as Authentication Failed (LDAP error code 49). Therefore, it will require API level customization of WSO2 IS basic authenticator and the user store manager to achieve your requirement.
But in the WSO2 IS Admin Forced Password Reset flow, the user will be given an OTP through email to log in to the IS and the password reset flow will be initiated as similar to your requirement without using the AD. Hence, it is recommended to use the Admin Forced Password Reset flow available in the WSO2 IS to reset the password of the user.
I have ASP.NET MVC application that uses windows authentication against remote active directory server. The computer where the app runs is connected via VPN to the AD server. The problem is that after user logs into the PC with domain user and logs into the application it needs to run even while offline as well, but it throws this error:
The trust relationship between workstation and domain failed.
From what I understood there is no cookie and the authorization works on per-request basis. Is there any way to authorize the user name/password against the locally cached credentials? The connection often drops and the application needs to keep running.
Also I can't turn on Anonymous Authentication as we want to sign in users without providing credentials.
Any suggestions appreciated.
Thank you
It was due to calling (while off the network)
User.IsInRole(role)
We have custom role management, so removing base.IsInRole on our custom WindowsPrincipal solved this issue.
After doing research I thought that it actually has to be on the network, but to keep using cached credentials you don't have to be, just do not try to fetch any user related information.
General question. Server admin setup SPNEGO. The LTPA bullet is marked under Global Security in admin console. My understanding is that SPNEGO captures username from an initial sign-on (ie network). Later, if user goes to an app's URL, few of the many things happening is SPNEGO is going through user's ldap groups (admin console-securtity roles) trying to find group that is tied to app's role names. If match is found, user authorized and can go directly into app without having to use login form to enter credentials. But have problem trying to implement this. Checking HttpServletRequest - getUserPrincipal().getName() and getRemoteUser() at front end of app are coming up null. If SPNEGO is in fact setup correctly, should a null ever be found?
You are confusing a few things. SPNEGO is a mechanism to pass user authenticated in the Kerberos realm to the given service without need to pass user password. It has nothing to do with authorization - this part is done by WebSphere security service based on the id retrieved from the request (in short).
Null username usually is effect of not enabling Application Security in the server or not protecting application with Java EE security (security constraints defined in the web.xml).
For some basic information about SPNEGO in WebSphere, check the following page Single sign-on for HTTP requests using SPNEGO web authentication
I have a question that comes forth of a problem I had where the browser of a client shows the wrong username.
All of the docs say that 'current credentials' are used. I have now proof that this is not the case! But what do they mean with 'current credentials'?
Current credentials appears to be the user that started the process requesting the IIS resource. But as you can read in my problem the browser seems to able to pass on another username then the one running this process if it 'wants'.
Also, when the browser cannot identify the user it will request credentials that you can ask to remember.
When will the browser request credentials
Where are these credentials stored?
Current user credentials:
Logging onto your Windows workstation means your log in through Kerberos onto the your Active Directory domain. A Kerberos TGT is held in memory by LSA. All subsequent calls will generate service tickets to services with the help of that TGT and your domain controller (KDC). All calls to that system are routed through SSPI on Windows.
I have a web service running in IIS 6.0 on Windows 2003. It's authentication mode is Integrated Windows security (anonymous disabled), and authorization is done with Authorization Manager and an XML authorization store. My test user is a domain user (admin, actually) with membership in an authorized role.
I am testing this (for now) on the web server (localhost), and using (for now) Internet Explorer to access the web service (.asmx).
I can successfully open the web service (wsdl) page through localhost, like this:
http://localhost:8080/MyService/MyService.asmx
Using this url, integrated windows authentication succeeds (silently), and I am sucessfully authorized by AzMan to access the service. The same goes for the server name:
http://myserver:8080/MyService/MyService.asmx
Now I need to use the external host name (www.mysite.no) to access the service (this in order to get ssl to work with a certificate issued to that sitename). To do this, I add the host name to my HOSTS file, like this:
127.0.0.1 www.mysite.no
...then type this into IE:
http://www.mysite.no:8080/MyService/MyService.asmx
What happens then is that authorization fails. I get the IE/Windows login box and enter my correct credentials three times. Then I get a 401.1:
HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.
Internet Information Services (IIS)
How is authorization through AzMan influenced by the host name?
Edit: I have reason to believe AzMan has nothing to do with it - it seems to be the authentication that fails.
I have reproduced the problem on another server. The essence seems to be that accessing localhost via an entry in the local host file somehow messes up the integrated windows authentication between the browser and IIS.
I have worked around the problem, now my curiosity is all that's left...
Enable audit login failure auditing & check the security event log on the host.
1) On the webserver, go to Control Panel, Administrative Tools, Local Security Policy.
2) Go to local policies, audit policy. Add failure for 'audit logon events'.
3) Close the MMC. Open a command prompt and type gpupdate.
4) browse to http://www.mysite.no. You will get the error again.
5) Launch event viewer (control panel, admin tools, event viewer). Navigate to the security event log and look for the login failure(s).They shoudl tell you something descriptive, like 'the user has not been granted the specified logon type'. Unfortunately the login type itself is not descriptive; logon type 2 is interactive (locally), 3 is 'access this computer over the network', 5 is 'logon as a service' (NT service, not WCF service). The rights required can be granted in the local security policy.
Also, check to see if you have a proxy enabled in IE. If your traffic is being routed to the proxy, it is possible that the proxy does not support NTLM. Add the host as a proxy exception while you test using IE.
My first guess is that it's not the host name.
The first thing to do is narrow down the problem as there are a couple things that could be going wrong.
First set the IIS site to anonymous access, and make sure you can pull up the web service. That will verify that you're accessing the right IIS web site and it's truly narrowed down to an authorization problem.
Also, check the Application Pool credentials, and the security settings on the file folder containing the web service as these could be contributors.