SSO breaking OWA font icons
I am investigating an issue where font-based icons are not rendering in OWA 2013 when accessed in Internet Explorer through APM using SSO. IE11: Everywhere else: We originally configured load balancing for CAS / OWA through LTM using the iApp without APM, and later added a portal access link to OWA on a separate APM webtop portal. This link goes through the APM session in order to use form-based SSO, and was configured manually & completely separately from the iApp-based VIP hosting CAS / OWA. The page renders as expected in any browser when accessed directly without APM, or through APM when SSO is disabled (or fails). The page also renders normally when accessed with SSO in any browser except IE11. We have performed a wide range of tests on the app and SSO profile with limited success. Under certain circumstances, IE11 will render the icons; but only when requests are routed through an external proxy (i.e. Fiddler) and even then only under specific SSO settings. We have verified that the fonts are being received intact, and can even get the icons to render if we install them locally and modify the page (through the IE developer console) to load the local copy. We have also applied the client-initiated SSO profile that is created by the exchange 2013 iApp template with the same results. I am now out of ideas and open to any potential explanations or solutions the community has to share. Thank you in advance. apm resource portal-access /Common/OWA { acl-order 8 application-uri https://owa.domain.com/owa/auth/logon.aspx\?replaceCurrent=1 customization-group /Common/OWA_resource_web_app_customization items { item { host owa.domain.com order 1 paths /* port 443 scheme https sso /Common/exchange_2013_sso subnet 0.0.0.0/0 } } path-match-case false publish-on-webtop true scheme-patching true } apm sso form-based /Common/exchange_2013_sso { form-action /owa/auth.owa form-field "destination https://owa.domain.com/owa/ flags 4 forcedownlevel 0 isUtf8 1 trusted 0" form-password password form-username username start-uri /owa/auth/logon.aspx\?replaceCurrent=1 success-match-value path username-source session.qualifiedlogin }
ASM: Failed to convert character
Hello everyone, I have an application protected by ASM using charset UTF-8. What happens is that sometimes I get some false-positives because the user browser is not using the charset informed in the meta tag. For instance, in some tests using Chrome and having as input some strings like “weißbier” or “über” I have no problems, but when I use Internet Explorer 11, ASM blocks the request with this error. There is an article from Microsoft about this saying that IE does not always take the specified charset in the page but it might be overridden by OS settings: https://support.microsoft.com/en-us/help/928847/internet-explorer-uses-the-wrong-character-set-when-it-renders-an-html So my question is, how do you deal with this? I wouldn't like to disable this check in the Security Policy, any possible alternatives?Internet Explorer This page is accessing information that is not under its control
Hello, We recently enabled SSL offloading for an application. Intermittently the users are receiving the warning error shown in the picture by Internet Explorer when accessing certain forms. Do any of you have bumped before with something like this. I have the feeling that the application is calling a different domain name in the back-end to reach information and therefore Internet Explorer is warning about it but I would like to know if there is a way to prevent this by using a URI re-write or any other method. Can I get some recommendations on where to continue looking or maybe a way that you have used to fix this? Thank you.
Cookie Persistence and Internet Explorer Not Working
Hi all, I have a strange issue with our F5 Load Balancer deployment. The issue we are having is with Cookie Persistence types, we are unable to get the F5 or end server to correctly set and save cookies on user’s machines. This is only affecting users who use Internet Explorer, all other web browsers are not affected. I can confirm the F5 load balancer sends a cookie correctly on Google Chrome and we can see this through chrome://settings/cookies or through the sql db file it produces. We have verified that on IE 8 with Privacy set to “Accept All Cookies” and the F5 Load Balancer set to “Always Send Cookies” & Cookie Insert, we can see a Set-Cookie header during a trace but no physical cookie is saved on the end user’s machine. I have tried both session cookies or expiration based cookies and experience the same issue. From what I am aware, we do no Group Policy blocking of cookies. Any ideas or help appreciated as I am now tearing my hair out trying to understand why it does not work.
Can't maximize RDP sessions with internet explorer - APM
I see a few similar posts on here about this but no definitive answer. I have Microsoft Remote Desktop shortcuts on my APM and they connect fine and maximize, but if you exit full screen, then it locks the screen to a small size. You can't resize or even maximize again and the maximize button becomes greyed out. Pretty unusable after that point. I thought this might be a bug when I was running 11.4 but I have upgraded to 11.6 and have the same issue. Anybody had the same issues and know how to fix this? Thanks
F5 BIG-IP APM Support for Older Versions of Microsoft Internet Explorer Ends On January 12, 2016
As of January 12, 2016, BIG-IP Access Policy Manager (APM) will no longer support certain versions of Microsoft Internet Explorer earlier than IE 11 for Microsoft Windows 7 and Window 8.1. BIG-IP APM will no longer support versions of Internet Explorer earlier than IE 9 on Windows Vista SP2. This includes all features currently supported in these earlier IE versions, as statedin the F5 APM Client Compatibility Matrices. This comes asMicrosoft is ending mainstream support for these earlier IE versions on Windows Vista, Windows 7 and Windows 8.1. Please refer toMicrosoft’sannouncementandMicrosoft’s Support Lifecycleweb page. BIG-IP APM’s policy onbrowser support, as stated in the F5 APM Client Compatibility Matrices: "F5 Networks ® supports the listed operating systems and browser releases, with the latest service pack or service pack equivalent for up to 3 years from time of initial release, as long as the listed operating systems and browsers are still supported by the vendor. If an operating system or browser vendor ends mainstream support before the end of that 3 year period for a release or service pack, F5 Networks ® will also end support at the same time. Once an operating system or browser has surpassed the 3 year date from release, F5 Networks ® will continually monitor the user base of this operating systems or browser release. When a release reaches a usage level that cannot justify development, test, and support resources, we will issue an EoL (End of Life) Solution announcing EoL plans at least three months prior to the planned EoDS (End of Development Support).”
