APM OTP not being received
We're investigating an issue where OTP isn't being recieved by users. The logging just seems to to suggest a black hole. User confirms not in junk etc. This doesn't happen all the time, it is quite sporadic. Apr 6 10:46:19 BIGIP1 notice apmd[14867]: 01490010:5: /Common/Citrix_XenDesktop:Common:82caf589: Username '*removed*' Apr 6 10:46:39 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:82caf589: Following rule 'Pass' from item 'Firewall' to terminalout 'Pass' Apr 6 10:52:54 BIGIP1 notice tmm2[22524]: 01490502:5: /Common/Citrix_XenDesktop:Common:82caf589: Session deleted due to user inactivity. A successful one reads as: Apr7 05:03:48 BIGIP1 notice apmd[14867]: 01490010:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Username '*removed*' Apr7 05:04:21 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'Pass' from item 'Firewall' to terminalout 'Pass' Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'Successful' from item 'OTP Verify' to terminalout 'Success' Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490220:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Pool '/Common/Pool_A' assigned Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490005:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'fallback' from item 'Pool Assign ALGCTXA' to ending 'Allow' Is there any additional logging that can be put on to see what is going on with sending the OTP email? Thanks in advance
APM: Office365 Skype for Business On-Premise Authentication
I've spent a few days working on an Office 365 lab hybrid deployment and have been unable to get Skype for business to authenticate or work properly. Is this supported? In my configuration I am attempting to use the F5 as the IDP. Azure AD connect is syncing properly and is not syncing password hashes to Azure. According to this document, Rich client application such as Lync or authenticating an Office subscription are not supported: Azure AD federation compatibility list However I am able to authenticate other thick-clients like Word, Excel, Outlook, etc without issue. A window with the APM login screen is displayed when authenticating--I would expect similar behavior for the Skype client. This makes me believe maybe this document is incorrect? I have gathered SSLdumps and see the authentication request reach the VIP: 1 10 1472838567.6975 (0.0018) C>SV3.3(448) application_data --------------------------------------------------------------- POST /saml/idp/profile/ecp/sso HTTP/1.0 Connection: Keep-Alive Content-Type: application/soap+xml Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 10.0; WOW64; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; MSOIDCR L 7.250.4556.0; App lync.exe, 16.0.7167.2040, {12B07E85-1B47-41C4-A4E2-43XXXXXXXXXX}) Content-Length: 1583 Host: idp.xxxxx.xxx --------------------------------------------------------------- 1 11 1472838567.6975 (0.0000) C>SV3.3(1632) application_data --------------------------------------------------------------- http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issuehttps://idp.xxxxx.xxxx:443/saml/idp/profile/ecp /sso1472838xxx xxxx@xxxx.xxxxxxxxxxxxxx 2016-09-02T17:52:11Z2016-09-02T17:57:11Z http://schemas.xmlsoap.org/ws/2005/02/trust/ Issueurn:federation:MicrosoftOnline http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey --------------------------------- ------------------------------ 1 12 1472838567.7042 (0.0067) S>CV3.3(336) application_data --------------------------------------------------------------- HTTP/1.0 302 Found Server: BigIP Connection: Close Content-Length: 0 Location: /my.policy Set-Cookie: LastMRH_Session=9c7be893;path=/;secure Set-Cookie: MRHSession=xxxxxxxxxxxxxxxxxxxxxxxxxxx;path=/;secure Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/ --------------------------------------------------------------- 1 1472838567.7042 (0.0000) S>C TCP FIN 1 13 1472838567.7046 (0.0003) C>SV3.3(48) Alert I would expect that the APM should be responding to the request rather than closing the connection as seen above. To me the soap envelope looks OK, or maybe I'm missing something simple? I'm running 12.1.1, and have also tried 11.6.1. I have no on-premise Skype/Lync environment and have validated that all DNS entries for Skype are correct. Microsoft's Connectivity Analyzer succeeds on all tests. The Skype client produces a generic failure on login: "Cannot sign in because the server is temporarily unavailable". Any guidance would be appreciated, thanks!SSL Orchestrator Advanced Use Cases: Office 365 URL Management
Introduction F5 BIG-IP is synonymous with "flexibility". You likely have few other devices in your architecture that provide the breadth of capabilities that come native with the BIG-IP platform. And for each and every BIG-IP product module, the opportunities to expand functionality are almost limitless. In this article series we examine the flexibility options of the F5 SSL Orchestrator in a set of "advanced" use cases. If you haven't noticed, the world has been steadily moving toward encrypted communications. Everything from web, email, voice, video, chat, and IoT is now wrapped in TLS, and that's a good thing. The problem is, malware - that thing that creates havoc in your organization, that exfiltrates personnel records to the Dark Web - isn't stopped by encryption. TLS 1.3 and multi-factor authentication don't eradicate malware. The only reasonable way to defend against it is to catch it in the act, and an entire industry of security products are designed for just this task. But ironically, encryption makes this hard. You can't protect against what you can't see. F5 SSL Orchestrator simplifies traffic decryption and malware inspection, and dynamically orchestrates traffic to your security stack. But it does much more than that. SSL Orchestrator is built on top of F5's BIG-IP platform, and as stated earlier, is abound with flexibility. SSL Orchestrator Use Case: Office 365 URL Management If you're reading this article, it's a good bet that your organization relies on Office 365 for your Office productivity, email, and/or collaboration tools. It's also a good bet that you're concerned about encrypted malware, and thus how to deal with malware that sneaks its way into Office 365. Given the shear number of products available to address it, it shouldn't take much to convince you there's a potential threat there. Of course, the service itself is not inherently insecure. But within Office 365, you create, manage and share documents, and send and receive emails with attachments. The issue is that the documents and attachments themselves are malware vectors, and email phishing attacks are hard to catch. Moreover, as the bulk of that traffic is all encrypted, you're faced with a dilemma. Do you rely solely on Microsoft's security to protect your organization, or endpoint security tools? Hopefully your answer is a resounding 'no' to both of these, and that you do indeed decrypt and inspect in active defense against malware and data exfiltration. But therein lies another problem. What and when do you decrypt? What about Office 365 components that don't play well with decryption tools, or where Microsoft recommends to bypass decryption for the sake of performance? At a most recent count, Office 365 encompasses around 350 unique resource URLs, and roughly 160 IPv4 and IPv6 addresses. These URLs represent the different Office 365 services, and are dynamic (i.e. frequently changing). So then I will ask again. What and when do you decrypt and inspect Office 365 traffic based on the revelation that not all Office 365 URLs should be managed the same way, and they're ever-changing. If at this point you're still not completely clear on the complexity of this scenario, that's okay. I'll refer you to a few Microsoft resources that go into great detail on the subject: https://techcommunity.microsoft.com/t5/office-365-blog/announcing-office-365-endpoint-categories-and-office-365-ip/ba-p/177638 https://techcommunity.microsoft.com/t5/office-365-blog/getting-the-best-connectivity-and-performance-in-office-365/ba-p/124694 https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide Microsoft also now tags URLs with an internal category system, as defined here: https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-network-connectivity-principles?view=o365-worldwide#new-office-365-endpoint-categories Those categories are: Optimized URLs - endpoints required for connectivity to every Office 365 service, and the most sensitive to network performance, latency and availability. Allow URLs - endpoints required for specific Office 365 services, but not as sensitive to latency as the Optimized URLs. Default - endpoints that represent Office 365 services that do not require optimization. Fortunately, F5's SSL Orchestrator can provide an elegant solution to this complex problem. Intelligent traffic classification allows you to define rules that can be used to control availability (allow or block), decryption (intercept or bypass), and steering through dynamic sets of security devices (service chaining). Bypassing TLS decryption on an Office 365 resource can be as simple as a single rule that matches on all Office 365 URLs. Or, you can decrypt some and bypass others, as Microsoft recommends. And you can choose to pass traffic through the service chain of security devices irrespective of decryption. Managing Office 365 URLs To make all of this work, you first need the Office 365 data source. As previously illustrated, Office 365 URLs and IP addresses are dynamic, updating roughly every 30 days. This feed isn't built into the BIG-IP, but there's an easy way to add it with a simple Python script: https://github.com/f5devcentral/sslo-o365-update Basically, a Python script is configured to run periodically on your BIG-IP to keep local custom URL categories and/or data groups in sync with the Office 365 URL source. These collections can then be consumed natively by the SSL Orchestrator security policy. You can then use these new URL categories as you would anything else in the security policy, like bypassing decryption for the set of "optimized" Office 365 URLs, or perhaps bypassing a proxy security device in an SSL Orchestrator decrypted service chain. Figure 1: SSL Orchestrator security policy with O365 category rule The Github repo has all of the instructions, but setup is pretty straightforward: Download the Python script - download on both devices in an HA pair: curl -k https://raw.githubusercontent.com/f5devcentral/sslo-o365-update/main/sslo_o365_update.py -o sslo_o365_update.py Install the script with the --install flag, and provide an interval for the script to run: python sslo_o365_update.py --install 3600 When the installation is complete, edit your SSL Orchestrator security policy and add a traffic condition to match on one of the new Office 365 managed URL categories. That's it. In a HA pair, the script runs independently on each unit. If you need to make adjustments to the configuration, jump on a BIG-IP console/SSH session and edit the json config data as described in the repo: tmsh edit sys file ifile o365_config.json If you mess something up or just want to rebuild, run the script again manually with the --install flag (and time interval). You can configure the script to: Create all or some of the URL categories, for different customer endpoints and different service areas Create just data groups and/or just categories Manage just URLs and/or just IPs Include and exclude URLs and IPs. ** Note that you will also need to configure system DNS and a gateway route on the BIG-IP to access this remote Microsoft content. ** And there you have it. In just a few steps you've configured your SSL Orchestrator security policy to identify and take action on the dynamic set of Office 365 URL/IP resources, and along the way you have hopefully recognized some of the immense flexibility at your command.
Office 365's new "Modern Auth"
Hi All, We've just heard a rumor that Microsoft have released a new authentication model for Office 365 which they are using with Exchange Online and Skype for Business to start with. Now we have been told that with this new authentication model that ADFS being fronted by APM for authentication/acting as an ADFS proxy is not and will not be supported due to the change in the way authentication works. From what we can tell, it will only break application clients (ActiveSync/Office/Skype) that aren't just a web page, but we really don't have much detail. Does anyone have any experience with Office 365 off-prem setups and the new Modern Authentication model? Can anyone confirm that it doesn't in fact work? Is there anyone from F5 who has advice on if it's on the road map for being fixed/addressed/investigated? Thanks in advanced.
APM - Azure AD integration with Oauth
Hi, I have a client that wants to centralize authentication to internal services (Intranet, private applications, etc) with Azure AD via APM using the Oauth protocol. When a user tries to access an internal resource, transparently send the credentials to the APM, it will validate the credentials with Azure AD and the APM will allow access if the credentials are correct. The communication between APM and Azure AD, from what I have read, can only be done through Oauth. I have looked for some examples of how this could be done, but it is not entirely clear to me. Has anyone done that? Do you know of a Cookbook that tells you how to do it? ThanksSecure connection via F5 LTM towards Office 365 cloud
We are using Big IP ADC as an HTTPS proxy towards Exchange servers. This is due the fact that our client which needs to fetch calendar information from our customer exchange servers does not support HTTPS protocol. Exchange servers are located in Internet so we need to encrypt the connection This works perfectly well with HTTP VIP and physical exchange server specified behind that VIP with IP address on port 443. However now many of our customers are replacing physical servers with office 365 cloud. Service address to cloud is https://outlook.office365.com/EWS/Exchange.asmx Is there any simple way to build a secure connection to Outlook cloud using F5 LTM? And how should I monitor the connection? We are using F5-BIG-LTM-2000S with software 11.2.1 Build 862.0 Hotfix HF2. Thanks, JariOffice 365 SAML token rejection
I have configured the Office 365 SAML iApp for authentication, and to all intents and purposes it looks as though APM is successfully authenticating a user and issuing a token. However when the token is submitted to Office 365 I receive the response: Sorry but we're having trouble signing you in. We've received a bad response. AADSTS50000 there was an error issuing a token. I'm using a URI as an identified as opposed to a URN. I've investigated as much as I can (but by no means and expert) confirming certificate thumbprints are uploaded to O365, time is in sync. I have dug into the http requests with Fiddler. I can see the SAML request and response. I see it submitted in the header to O365. Verified users are synchronised to Azure AD. Furthermore I've checked for additional proceeding slashes in the configuration between APM & O365. Really struggling to understand the problem. Any suggestions/ help would be greatly appreciated.Office 365 Hybrid "thick" clients, totally replace ADFS (not just ADFS Proxy)
Goal: Hybrid Setup with Office 365, no p/w in cloud. Status. Set up (w/Big IP APM) and works great except for thick clients. Does the most recent iApp for ADFS or iApp for office 365 allow thick clients to authenticate, or is the iApp for ADFS at the point where it can replace ADFS (and not just ADFS proxy) ? Or if must be done manually, is there guidance for what info the big ip needs from O365 and what O365 is looking for from Big IP (and where to enter this config info)?
exchange hybrid deployment (SAML ECP needed) and 12.1
hi referring to that post from 2014. I can't authenticate my users, because the autodiscover process in O365 is blocked at the SAML-ECP stage. I do see the authnrequest from O365 coming properly to my IdP (ECP URL) with an authorization http-header. However, the APM is not authenticating and do a 302-redirect, which the client can't follow. Anyone tested that successfully on 12.1 (or 12.0)? Thanks! AlexSecuring Office 365 with APM as IdP
I'm evaluating using APM as a SAML identity provider for Office 365, but I'm struggling to find ways to effectively secure access as per my specification. Windows/ Mac OS, only permit corporate devices. Mobile, only permit via MDM solution (TBC). I have implemented device based certificate checks with OCSP, which although a little clunky (cert checker service deployed via GPO) works well on Windows. On Mac OS I have the same check working for administrators in Safari; although the Office 2016 clients, I'm guessing implement a cut down browser for modern authentication redirection which seemingly doesn't support plug-ins. User certificates don't seem appropriate here as it's the device I'm looking to validate, not the user. I considered whether anything could be done coupling user certs with client side SSO, to remove the login page, but I'm guessing failing to authenticate (on a non-corp device) with Kerberos would result in the browser prompting for credentials, allowing manual input of credentials? Has anybody got any suggestions, or perhaps any examples? My current policy is getting quite complex. Cheers.
