We are using WSo2 IS 5.0.0 server and have enabled IWA which used windows user object and automatically logs into our application suite. We are seeing a problem where specific set of users are not automatically authenticated using the IWA mechanism. An HTTP 400 response is received for these users. We enabled trace logs on the WSo2 end and were able to track the request to a point after which the request gets terminated for some reason and are unable to see any exception or error in the trace logs.
Below is the link which has the trace for a successful user
http://pastebin.com/Gx3HW6xr
Link for Failed User
http://pastebin.com/3FJ8APkH
We need some pointers which will help us understand what is stopping these users from getting logged in.
According the symptoms you may reach the tomcat's header size limit. The NTLM Negotiation HTTP headers can be pretty large (mainly for users having many groups/roles). In the catalina-server.xml check the maximal header size (maxHttpHeaderSize) on the connector (by default it is 4kB or 8kB). Try to increase it to something more (54kB was ok for us).
Related
I created my azure web-app and created app registration. and connected Azure AD to my web app. I used express security and I also used advance security with client ID and client secret. I know there is a similar question about this error. but it is not clear answer.
Most likely causes:
IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred.
IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly.
IIS was not able to process configuration for the Web site or application.
The authenticated user does not have permission to use this DLL.
The request is mapped to a managed handler but the .NET Extensibility Feature is not installed.
Things you can try:
Ensure that the NTFS permissions for the web.config file are correct and allow access to the Web server's machine account.
Check the event logs to see if any additional information was logged.
Verify the permissions for the DLL.
Install the .NET Extensibility feature if the request is mapped to a managed handler.
Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click here.
From your description, I know that the problem is most likely due to the lack of web.config file.
Solution:
It is recommended to ensure that your project can run normally locally.
Continuous deployment is recommended
At present, the reason for your problem is the lack of web.config, which will be automatically created when using git deployment. As shown below.
For more details, you can check my answer in another post.
Azure Web App getting “You do not have permission to view this directory or page.” when launch app
Having WSO2 IS 5.0.0.SP1 backed by PostgreSQL there is another application reading user information using the SCIM service (filter=userNameEq...)
All works but after certain time the service returns "User is not authorized.." response with a single ERROR level log line. Since that moment all subsequent calls fail with "404 User is not authorized". Even when I log in using the admin account I have no access rights. This state takes for a few minutes and then all seems working again.
We traced the response message to the SCIM service implementation where the authorization is checked. However we are unable to find the root cause of the issue (suspecting some exception is qietly dropped, cache cleanup cleans more than it should, ...)
Any hint / idea is appreciated.
Carpe diem
Gabriel
This seems to be authorization issue. If after trying 3 fail login attempt user locked 0-minutes(Most user used 05 minutes). This is default settings of fresh WSO2 IS pack. After the configured locked-time user unlocked. Then the user have a login with valid credentials. If you need, you can change the login attempt,locked time.Please check [IS_HOME]/repository/conf/security/identity-mgt.properties file. It's having the all configuration.
Issue is resolved (or - reason is identified in another system). In the AD tree one of the domain controllers is external (cloud) and unable to authenticate the technical (wso2) datastore user. When the AD node hostname is resolved to the cloud node, then ldapsearch is unable to return any groups from a sub-domain of the cloud based domain controller (interesting - it doesn't fail).
I have little experience with Windows 8 and our organization does not yet support it but some end users have it.
Users running Windows 8.1 and IE 11 have presumably created a live tile referencing our secure application. We are seeing user requests to /browserconfig.xml with no authentication cookies while the user is currently authenticated in IE. Windows appears to not send existing authentication session cookies in the request but is processing response cookies. This is causing the user to become unauthenticated. One user claims to have removed the tile from their desktop but we are still seeing requests to browserconfig.xml from that user. When that user ran IE developer tools and logged network traffic, we see the transition from authenticated to unauthenticated once our authentication cookie value changed. IE did not log the request that changed the cookie. IE did not log the request to browserconfig.xml at all, presumably because it was in a different thread. Our server did log this additional request. The request to browserconfig.xml consistently occurs between the change from authenticated to unauthenticated.
Questions:
Is the request to browserconfig.xml expected to include cookies (both session and not) in the request? If not, why does Windows appear to process response cookies?
The user claimed to have removed the tile. If this is true, is there a difference between hiding and deleting tiles? We are still seeing requests to browserconfig after the user claimed to have removed it. Unfortunately, I cannot confirm the user claim.
You cannot vote on your own post
0
I saw this exact behaviour debugging our web application. I also saw it once in a request for /favicon.ico not sending the authentication cookie (while in the middle of using the site).
In my case, the requests that didn't send an authentication cookie have user-agent header corresponding to "IE11 on 64-bit Windows 8.1 Update", and all other requests have user-agent header corresponding to "IE11 for the desktop on 64-bit Windows 8.1 Update".
My fix was in global.asax.cs Session_Start(), if requesting /browserconfig.xml or /favicon.ico, then don't set any cookies in the response.
I am using omniauth-saml 1.3.1 with omniauth 1.2.2 in rails 4.2. It works well with my test identity provider set up at openidp.feide.no (a nifty tool for those setting up a SAML service provider). It even works in production.
Now I am trying to get an IdP set up with a client of mine. When the user visits /auth/saml, they are directed to the client's IdP as expected. The user is able to use their email/pw to login.
The IdP then responds to my SP, but omniauth is redirecting to the failure callback.
As seen here, I get an error message "invalid_ticket". However, the error itself isn't getting passed to my failure controller action in env["omniauth.error"], as I read it should somewhere (unfortunately I can't find that documentation right now).
I'm hoping somebody will have some advice as to how I can figure out what is causing the "invalid_ticket" to happen. Is there perhaps a way to see the raw SAML response from the IdP?
I should note that I need to find this information in production because the client's IdP points to our production SP and I can't convince them to point it somewhere I can do some more extensive testing (like my localhost dev machine). I can, however, write in some more logging or Honeybadger exception reporting if that will help.
Currently, I am reporting to Honeybadger all env["omniauth.*"] values and params when omniauth redirects to the failure route, but I am not getting any information further than Omniauth message: invalid_ticket.
A big thank you to anyone who can help me go in the right direction here!
You might want to try adding other environments to failure_raise_out_environments:
OmniAuth.config.failure_raise_out_environments = ['development', 'staging', 'production']
to your initializer. You will get meaningful error messages in your log or Honeybadger.
These errors are by default raised only in development environment.
I have deployed two WSO2IS servers in cluster, the deployment seems to be working fine as the answer to the requests made are consitents and all the policy stuff is working.
But I get the same error for every request I make, which Im unable to find out the real meaning, if this is a normal behaviour or on the contrary, there is something wrong Im missing.
As you can see, first I get the "WARNING: Illegal acces attempt.." followed by a successful login with the default user (ADmin)...
[2014-04-14 12:57:36,293] WARN {org.wso2.carbon.server.admin.module.handler.AuthenticationHandler} - Illegal access attempt at [2014-04-14 12:57:36,0292]
from IP address 10.6.10.11 while trying to authenticate access to service EntitlementService
[2014-04-14 12:57:36,423] INFO {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - 'admin#carbon.super [-1234]' logged in at [2014-04-14 12:5
7:36,423+0200]
I would appreciate your help,
Thanks in advance,
Jorge.
You are accessing the "EntitlementService" which is an admin service. Therefore you need to authenticate to access this service. Basically you need to send user/password in basic authentication header, In basic authentication, client normally sends the basic headers, when server gives an unauthorized responses. This is why, you would see above Illegal access attempt log in every time and after client sends the header, user would be authenticated. But you can avoid it by using Preemptive Authentication mode with basic authentication. If you are using a Httpclient library to send the request, you can enable it. Please refer this