Microsoft 365 IP Steering python script
Hello! Hola! I have created a small and rudimentary script that generates a datagroup with MS 365 IPv4 and v6 addresses to be used by an iRule or policy. There are other scripts that solve this same issue but either they were: based on iRulesLX, which forces you to enable iRuleLX only for this, and made me run into issues when upgrading (memory table got filled with nonsense) based on the XML version of the list, which MS changed to a JSON file. This script is a super simple bash script that calls another super simple python file, and a couple of helper files. The biggest To Do are: Add a more secure approach to password usage. Right now, it is stored in a parameters file locked away with permissions. There should be a better way. Add support for URLs. You can find the contents here:https://github.com/teoiovine-novared/fetch-office365/tree/main I appreciate advice, (constructive) criticism and questions all the same! Thank you for your time.65Views1like0CommentsAPM 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 advance419Views0likes0CommentsAPM: 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!567Views0likes3CommentsOffice 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.858Views0likes4CommentsAPM - 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? Thanks352Views0likes1CommentSecure 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, Jari395Views0likes2CommentsOffice 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.963Views0likes9CommentsOffice 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)?739Views0likes9Commentsexchange 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! Alex389Views0likes5CommentsSecuring 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.250Views0likes1Comment