iRule for directing OWA/OA Traffic
Hey! Total beginner at iRules so hoping someone could point me in the right direction. In summary what I want to do is the following: 1) If a Mac Outlook app comes in (using webmail.company.com/ews/exchange.asmx) > Send to a pool 2) If a request comes in directly to webmail.company.com > Redirect to a different URL 3) If any other request come in (ex. autodiscover.company.com) > Continue to default VIP behaviour Since the domain listed is the same for 1+2 (difference is the URI) I want to make sure that if 1 is hit, 2 is not looked at and sent to the wrong place. So far I have: when HTTP_REQUEST { if {[string tolower [HTTP::uri]] equals "/ews/exchange.asmx"} { pool Exchange_2013_proxy_pool } elseif {[string tolower [HTTP::host]] contains "webmail.company.com"} { HTTP::redirect "https://site.company.com" } } Would this work to satisfy the first 2 conditions listed above? What happens when nothing is matched in this irule (ex. condition 3 where autodiscover.company.com is used)? Does it continue on to whatever the default behaviour is for my original VIP? Any info or tips would be amazing!375Views0likes1Commenthaving trouble accessing OWA2010 with Basic authentication
Hi, I cannot get SSO working with Basic authentication on BIG-IP 11.5.1 (LTM+APM). Official iApp supports only HTML Form. I have a Virtual Server with associated Access Profile. Access policy is quite simple - I've got a Logon Page, AD Auth and Credential Mapping. I've created an SSO HTTP Basic configuration and attached it to Access Profile. After logging in to Logon Page it offers me to enter my credentials again (HTTP Basic Auth window appears). I've tested similar configuration (but with simple Apache web server, not one of MS webapps) in my LAB and everything worked fine. When I access OWA through the APM I get the following headers in response: HTTP/1.1 401 Unauthorized Content-Type: text/html WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Basic realm="" X-Powered-By: ASP.NET X-UA-Compatible: IE=EmulateIE7 Date: Mon, 30 Jun 2014 18:36:23 GMT Connection: keep-alive Vary: Accept-Encoding Transfer-Encoding: chunked Proxy-Support: Session-Based-Authentication Dear community, could you please share some working recipes for similar configuration with me? PS Same issue with SharePoint webapp...524Views0likes6CommentsHow to avoid "Access policy evaluation is already in progress"
Hello, I am using the iRule below to close Outlook Web App 2013 sessions. At the first sight it works correctly and shows the F5 logoff page (/vdesk/hangup.php3). However, OWA 2013 has a javascript that performs a hidden POST to the server on the onunload event to close the session on the server side. This happens right after the session is closed by the F5 logoff page. So it automatically creates a new APM session and when the user clicks on "Click here to login again" he/she sees the message below coming from APM: "Access policy evaluation is already in progress" How can I avoid this message? I tried to do ACCESS::session remove on in response to this last hidden POST but it didn't help. I also tried to introduce some delay before redirecting the user to the F5 logout page in order to let it perform the last POST but it did not work either. when HTTP_REQUEST { Set the uri variable set uri [string tolower [HTTP::uri]] Check if the user clicked the OWA signout link and redirect to the F5 logout page if { $uri contains "/logoff.owa" || $uri contains "/logoff.aspx" } { HTTP::redirect "/vdesk/hangup.php3" } }2.2KViews0likes14CommentsAutoDiscover Issue with Exchange 2016 iApp
Hello together, got one big problem: I have deployed successfully the iApp template of Exchange 2016 and the customer wants to use OWA and AutoDiscover Service. The AutoDiscover Service is not working as expected.. so the user cannot authenticate with e-mail or domain\username. My Access Policy: Logon Page (Split Domain from full Username YES) -> AD Query (Cross Domain Support DISABLED) -> AD Auth (Cross Domain Support ENABLED) -> SSO Credential Mapping (default). I used the right Domains and Access Profiles. OWA is a logon possible with E-Mail, User and domain\User. But AutoDiscover is just User and domain\User. E-Mail is NOT working. Does anyone know, how the users could finally authenticate via E-Mail? They're claiming that they're not able to use AutoDiscover Thanks in Advance! Hank446Views0likes1CommentOWA bruteforce protection with ASM
Hi, Have you ever tried to protect MS Outlook Web Access login page with ASM? I'm trying to set up brute force protection but don't have any luck. I made a login page with the following parameters: Login URL Explicit HTTPS /owa/auth.owa Authentication Type HTML Form Username Parameter Name username Password Parameter Name password Expected HTTP response status code 302 With this configuration I can see all requests including usernames in the Event Viewer. I expected that after enabling brute force protection for my login page I will have this page protected. But I don't. Could you please share with me your experience?757Views0likes5CommentsKerberos client auth and Exchange profile
I'd like to do Kerberos auth of clients (where possible) and SSO to Exchange CAS servers. Today it's set up using Basic+NTLM auth. It works, but I would like to swap NTLM for Kerberos while we're setting up new CAS servers. I don't fully understand the purpose of the Exchange profile, what it exactly does and when. Looking though its settings, there is only Basic and NTLM to choose from for various URIs. For OWA as an example, I'd like to do client kerberos auth by creating an AP with a 401 basic+negotiate agent and following negotiate a Kerberos Auth agent. Would I set the owa options in the Exchange profile to "basic" and then the magic of the exchange profile kicks in when APM does a 401 Basic auth with the client, which hopefully never happens? SSO is Kerberos and already set up and works.456Views0likes0CommentsOWA 2016 "Options" Button has no functions
Hey DevCentral, we deployed iApp Exchange 2016. In the last days we changed the expiring Certificate for the Exchange VS. Now its valid again. Since the change, the customers found out, that the "options"-button is not working anymore. If I click the "wheel" at the top right, the menu drops down but its not possible to click "Settings" or "Manage Add-Ins" for example. I guess its an error in the URL-Redirection when changing to /options. It's about this url: /owa/#path=/options/mail Also it's manually not accessible. I get an white page adding this to the url (while logged in) Same iApp, but different corporation works fine. Both running f5.microsoft_exchange_2016.v1.0.2 on same appliance. The OWA where it's working, has also the "Offline Settings" when clicking the wheel. On the broken one there is no "Offline Settings". Does anyone has an idea what could cause that problem? I dont think it has any connection with the change of the ssl-cert. Appreciate any help!293Views0likes0CommentsOWA 2nd Authentication? Exchange Problem?
Hi DevCentral, I deployed iApp Exchange 2010/2013 Template a several times and it was working fine for every customer. On my last customer there's something strange happening. I tried everything to fix it. When I want to authenticate with the test user it gives me after hitting login button a second http-auth prompt where I need to log in with the same data a second time. So after typing 2nd time credentials he forwards me to OWA. On which site is something wrong configured? I tried everything on F5 site. I cannot access customers Exchange so I dont know what I have to tell the customer to change.. Log: Disabled the SSO for this session: no supported WWW-Authenticate header is found482Views0likes3CommentsOWA iApp Exchange 2016 - AutoDiscover not working
Hey since I deployed OWA iApp via F5 for a customer they claim that AutoDiscover is not working anymore. How can that be? OWA was running before on a TMG and now on F5. Since the change of IP/DNS to make it productive, the customers claiming that AutoDiscover is not working. My Access Policiy is like this: Start --> Logon Page --> AD Auth --> SSO Credential Mapping The single configuration parameters are kept basic (like template). Maybe it has something to do with "Cross-Domain Support"? or "Split Username from domain"? Thanks! Would be nice of somebody could help me, this case is pretty urgent..285Views0likes0CommentsOWA Exchange 2016 - Problems with Autodiscover from external access
Hey F5 Community! At the Exchange-Server of the customers, the Login-Syntax from the Outlook-Autodiscovery, like its usually pre-configured from Microsoft, does not work. The customers have an outlook.customer.com OWA Access, and also an autodiscover.customer.com URL. They login with "domain\SamAccountName" or "UserPrincipalName". The Login possibilities at the F5 should have the same Login-Syntax like OWA for AutoDiscover. On the testconnectivity.microsoft.com site belongs to the SamAccountName also the intern domain, which should not be missing. Because without it will not work. At the moment the the Autodiscovery works only with the SamAccountName, without entering the local "domain\" infront of the username. This leads to conflicts with other internal structures at the Outlook-Autodiscovery. I work in public services, this is the case: There are problems with Outlook-Autodiscovery for the "public utility" but with the "townhall" it works fine. Independent from the Windowsdomain, the Exchange-Server have to find the intern domain or? Exchange Server is placed in the Townhall. Public Utility used the old OWA 2013 via TMG from the Townhall. Now Autodiscover does not work for Public Utility but works fine in the Townhall. The Access Policy is pretty basic: Logon Page -> AD Query (with Cross Domain enabled) -> AD Auth (with Cross Domain enabled) -> SSOCredentialMapping (with custom mcget {session.logon.last.logonname}) -nothing else changed Published on F5 BigIP v13.1.1 with Exchange 2016 template.835Views0likes0Comments