I have a siteminder protected portal which has links to many applications that are also protected by siteminder. SSO is implemented between the portal and the applications.
The issue is that when we login to the portal and browse through the applications, it happens sometimes that we suddenly get logged off from the portal for no reason ( no time out, it can happen even for as less as 1 minute).
Issue is reported for a small group of users and it happens on IE as well as Firefox browsers and it happens randomly.
1.Local system time on the policy servers, proxy servers and the user's machine are in sync
2. additionally when I check with Fiddler on the cookies are still there , but we still get logged off from the portal.
Any ideas for this?
Are you using a persistent session store? This may happen if the validation period is not setup properly.
This may also happen if one of the policy servers has a different encryption key from the others. If you can enabled the trace logs on the web agent, it should give you a decent idea about the reason the cookie is being rejected.
Related
We're using AppAuth for a macOS application to authenticate Google accounts. This has been working for years, except recently Chrome has started to block all http connections by default. The loopback server in AppAuth is hard-coded to work with http connections only. The following issue also seems to have gone unanswered: https://github.com/openid/AppAuth-iOS/issues/624
What other options do we have for using a https loopback server on macOS for OAuth2 authentication? We need the loopback server to be able to extract parameters Google sends back after authentication. Asking users to switch from Chrome is not desirable.
Interesting - with loopback desktop logins there are two URLs involved:
The URL in the desktop app, which is meant to be HTTP according to OAuth standards, since it runs on end user PCs. Using HTTPS would require the entire user base to host SSL certificates, which is highly impractical. Typically a loopback URL is a value such as http://localhost:8000, where the port number is often calculated at runtime.
The URL used to invoke the system browser is a value such as https://myauthserver/authorize?client_id=xxx&redirect_uri=http://localhost:8000..., and this should be HTTPS of course.
PROBLEM DIAGNOSIS
I'd be very surprised if Google have blocked this if you are using standard desktop logins, since it has been referenced on their Native Apps Page for years.
Are you sure something else is not the cause? One possibility might be lack of a user gesture in the system browser. Is the problem consistent and are there any differences in these cases:
Make Safari Browser the default before login
Make Chrome Browser the default before login
Make Chrome Browser the default before login and clear browser cache
Let me know and I may be able to suggest some next steps ...
I am running two Windows server 2016s with IIS 10.0.14393. One server for staging purposes, and one for production.
The application has one "front-end app" and one "back-end REST api" running on the same IIS server. The front end communicates with the backend (suprise!). The difficulty I am facing is that the staging server works as expected, i.e no "Sign in" box appears when entering the front-end web page (React). However, on the production server this box pops-up.
When the page is loaded, there is javascript that fetches some information from the API, and it seems that this async fetch is causing the pop-up to occur (the request is in pending mode until login).
I have studied the configuration of IIS on the two servers but can't seem to find any obvious differences.
Both instances have both windows authentication and anonymous authentication turned on for both front-end and backe-end. I need this as the API has different types of authentication for the endpoints.
Anyone that has solved a similar issue?
Thanks
If someone experiences a similar issue the following link may help: https://support.microsoft.com/en-us/help/258063/internet-explorer-may-prompt-you-for-a-password
In my case I was sending the request to the api with the full domain url. The problem was fixed by just using the machine name (and port in my case) when sending the request. If the whole domain with punctuation is used, the system believes that the request is meant for the Internet and not the intranet, and will not include any credentials.
Another, and probably more robust solution, is to add the site in question to: Internet properties -> security -> Local intranet -> sites -> advanced.
I am having an workstation specific Kerberos issue and hope anyone here would have additional recommendation.
Our application has an application server and web server and we have kerberos configured on both application layer and web layer.
And for certain users, when we provide the Kerberos link and they are not able to authorize in. And we found out the issue is workstation specific. And on the same problematic workstation, the user could access application server via Kerberos authentication.
And on the web logic we see the following error:
[SpnegoFilter.doFilter] Although user authentication to xxx was successful, Integrated Authentication could not extract the user's credentials because it appears delegation was either not configured or disallowed
I am looking for any of Windows setting could potential lead to this issue? We check that our domain is trusted on both working and nonworking machines on the browser level and GPO settings are the same.
What you're describing is unconstrained delegation, which is the act of a user handing the remote server their TGT so the server can impersonate the user without restriction.
Windows deems this as incredibly dangerous (it is) and is moving towards disabling it outright when certain security services are enabled on the client. Specifically Credential Guard. It will also block it for users that are members of the Protected Users security group, though the fact that it's affecting specific workstations leans towards Credential Guard.
If it is the above issues the correct solution is to switch to constrained delegation.
We have a product which relies on a thin client installed on users machine. We make an ajax get request to a domain pointing to local host which has a real ssl. This fails in edge, works in every other browser including IE11. Note that same works if there is no ssl involved. It also works on Windows 10 Home edition.
Adding a datatype, content-type or request method does not resolve this. Only way to fix this seems to be running following command.
CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"
If this is expected behavior, can someone explain why microsoft would block this on a enterprise version but it works on home edition ?
Microsoft Edge, and Windows 10 apps in general, use AppContainer Isolation:
Isolating the application from network resources beyond those
specifically allocated, AppContainer prevents the application from
'escaping' its environment and maliciously exploiting network
resources. Granular access can be granted for Internet access,
Intranet access, and acting as a server.
Your thin-client is running on win10 enterprise edge against an intranet ssl service (localhost), so access is by default restricted by this mechanism. With the command
CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"
you are disabling network isolation on that host for the loopback network adapter (localhost) for MS Edge so your app client (and any other locally sourced app) can run on it without restriction against any localhost service.
This fails in edge, works in every other browser including IE11.
They clearly wanted to improve the default security policy of previous versions. It's never too late, MS :) There is actually an Enhanced Protected Mode (EPM) that could prevent your app from running on IE too. Chrome has its Google Chrome Sandbox that can also be tuned like this. Safari and Firefox also have sand-boxing features although I am not familiar with their particularities.
Note that same works if there is no ssl involved.
Typically, if you are using ssl is because you are dealing with sensitive data and/or a critical service. If you are not it is ok to be more lax. Again, just a matter of security policy.
It also works on Windows 10 Home edition. If this is expected behavior, can someone explain why microsoft would block this on a enterprise version but it works on home edition?
Enterprise versions of any product are known to be more restrictive since their target users are more security concerned (IT people typically don't want to expose their company's intranet payroll db service to external attackers, and things like that). Also, in this case the default behavior can be easily defined/altered by experts on the IT department (check out domain security policies) so it's better to leave the default settings to "paranoid" mode and let the experts tweak according to the company's needs.
Note there are other mechanisms at work when you are running a thin client on the browser that make this kind of protection redundant (same domain policy, XSS protection and so on). Nevertheless one can never be too safe: There are ways to work around those defenses such as Self-XSS that require isolation between the browser and the local network to avoid compromising the system. In the end, less exposed surface means less attack vectors, so isolation is good if you can afford it :)
I have to rely on an external hosting provider for my school website. If more than 10 students collectively log in with incorrect login details the hosting provider will launch a denial of service attack from where the incorrect loggings originated. i.e. from within the school. So this means the school will be logged out of its own resource.
Students will get their logging in details incorrect sometimes, and they also need to log in at the same time. So I do not know how to get around this problem.
Does anyone have any ideas, as it appears that I cannot get a hosting account which will avoid this from happening, and we do not have the money for an internal webserver where the settings for security can be controlled. We have been quoted £28K for one of these!
It's not clear here if you have hosted your website under shared hosting and what is (may by anti-DDoS software) causing DDoS trigger. If maximum number of concurrent users is known, you can ask web hosting provider to tweak their DDoS prevention software to allow same number of concurrent failed attempts. As an alternative, you can choose other Web Hosting type such VPS. In VPS, you will have full administrative access. So by default there is no anti DDoS software or firewall that can trigger false DDoS alerts. If you wish you can tweak/disable or enable it.