Forum Discussion
brepav123_22459
Cirrus
CirrusiRule to Allow Outlook users by Username
Hi All, ive been presented with an interesting request. Currently our users authenticate to outlook (whether by their browser to OWA, mobile active sync, or the outlook application) directly through our F5 then go the Outlook servers. Our mobility team wants to implement an MDM solution so now all mobile users have to authenticate through a separate server, which then points to the F5. That part is working fine. However due to a limitation of the MDM there are some accounts that cant go through it and need to still go directly to the F5.
So that leads me to my question, is there a way to allow or block users based on the username they are trying to authenticate to OWA with? Basically if they are trying to log into user1@company.com they would be blocked. But if they tried with user2@company.com it would pass the traffic?
Thank you for any and all replies!
I think i may have figured it out. After spending some hours looking at packet captures I noticed in the URI active sync always sends the username as part of the string. So using an iRule it searches that URI for the specific user identity and if it matches, it lets it through. Seems to be working so for but have yet to do extensive testing on it. I just wonder how bad the resource usage on the F5s will be having to inspect the URI of every connection. Thanks for the replies!
"/Microsoft-Server-ActiveSync*" { if { [HTTP::uri] contains "username"}{ persist cookie pool POOL } else { discard }
AJ_01_135899Cirrostratus
This is definitely possible. Since you're using Exchange / OWA, your organization presumably is using Active Directory. I'm also assuming you're using APM.
Leaving the MDM solution out of the equation for the moment, here's a straightforward solution:
- create an Active Directory group containing the list of users that you'd like to allow through.
- add an AD Query object to the end of your APM access profile, retrieving the "members" attribute.
- create a success/failure branch on that AD Query object, that ensure that the success branch contains the "User is a member of (the group you just created) ".
The question mark is how the MDM solution comes into play. If the MDM solution does indeed (as you describe), handle authentication then send traffic to the F5 you'll need to figure out a mechanism to pass this traffic (perhaps via source IP, header, or some other mechanism). If the MDM solution interfaces directly with Exchange / OWA, you will probably be fine.
Hope this helps
brepav123_22459Unfortunately no we are not using APM. We only have LTM so are limited to iRules for basically all of our advanced functionality. Perhaps i used the term authentication too loosely. More to say the F5 is the front end for all incoming connections but then it passes the actual connection and authentication piece back to our AD servers. Thanks
- AJ_01_135899
Well, this gets much more complex. At first thought, you'd need to:
- Inspect the OWA logon to determine username. This may not be easy.
- Match the username against a datagroup, OR Create a sideband call in the iRule to your AD's LDAP service to determine if it's a member of the allow group.
- Determine a way to persist the session to ensure this call doesn't occur for every HTTP call, potentially by setting a session cookie from within the iRule. (i.e. put the logic inside an if exist session::cookie block)
APM is very well suited to this, but if you have a way to get the username out of the http payload this is definitely possible in iRules.
- brepav123_22459
I think i may have figured it out. After spending some hours looking at packet captures I noticed in the URI active sync always sends the username as part of the string. So using an iRule it searches that URI for the specific user identity and if it matches, it lets it through. Seems to be working so for but have yet to do extensive testing on it. I just wonder how bad the resource usage on the F5s will be having to inspect the URI of every connection. Thanks for the replies!
"/Microsoft-Server-ActiveSync*" { if { [HTTP::uri] contains "username"}{ persist cookie pool POOL } else { discard }