Forum Discussion
NimbostratusBlocking iOS 6.1 Devices on Exchange 2010
This is more informative, the last few hours we started experenceing issues with Apple iOS 6.1, essentially malformed meetings on a device cause the device to get into a sync loop which causes excessive transaction log growth on the Exchange mailbox servers which will cause Exchange performance issues and potentially transaction log drives to run out of disk space.
Exchange has a limited ability in blocking options when using the internal blocking features users are presented with "Your password may be incorrect", however this solution provides a simple "The server refused connection" as an alternative, this was added to our previous /microsoft-server-activesync irule.
if {[HTTP::header "User-Agent"] matches_regex {^Apple.*1002.*}} {
reject
}
-Dan
38 Replies
What_Lies_Bene1Cirrostratus
Actually, so should this much more efficient version;when HTTP_REQUEST { switch -glob [string tolower [HTTP::header User-Agent]] { "*1002.14[0-5]*" { if { [HTTP::uri] contains "Cmd=MeetingResponse" } { reject log local0. "Denied iOS 6.1 Device SNAT src=[IP::client_addr] src_port=[TCP::client_port], dst=[IP::local_addr] dst_port=[TCP::local_port], virtual=[virtual name]" } } } }- barakaspeed_114Posted By Goat on 02/19/2013 01:47 PM
Updated to allow iOS 6.1.2 (which is 1002.146). This rule will match versions 1002.1 through 1002.145:
if {[HTTP::header "User-Agent"] matches_regex {^Apple.*1002.([Z1-9]|[Z1-9][Z0-9]|1[Z0-3][Z0-9]|14[Z0-5])$} } { if { [HTTP::uri] contains "Cmd=MeetingResponse" } { reject } }
Can you explain the requirement of using the capital Z in your syntax, which is preceeding either a 1 or 0? 
Chad_103287I implemented What Lies Beneath's iRule last night and it works great. Since my iRules-fu is nowhere as good as yours, I am wondering if it is possible to pull out the username and add that to the logging portion of this rule. I see a ton of hits when these rules block a request, but no real good way to tie it back to a user.
Thanks for posting this very helpful iRule
- What_Lies_Bene1Do you know where the username is? Is it in a header or the payload data?
- Chad_103287
Pretty certain it is in the payload, I am investigating to see if I can confirm.
- What_Lies_Bene1If you find it we can use something like this (untested);
when HTTP_REQUEST { set collectdata 0 switch -glob [string tolower [HTTP::header User-Agent]] { "*1002.14[0-5]*" { if { [HTTP::uri] contains "Cmd=MeetingResponse" } { set collectdata 1 HTTP::collect 0 0 } } } } when HTTP_REQUEST_DATA { if { $collectdata = 1 } { scan [HTTP::payload] {%*s login %s} username reject log local0. "Denied iOS 6.1 Device SNAT src=[IP::client_addr] , virtual=[virtual name], user=$username" HTTP::release return } } - Stefan_Klotz
Cumulonimbus
We used the switch-case method and it's working fine.
The username is visible in our environment in the URI, this is our log-statement:
log local0. "Denied iOS 6.1 Device, User-Agent: [HTTP::header "User-Agent"], URI: [HTTP::uri]"Ciao Stefan 🙂
- Chad_103287
We took a shot that our usernames were exposed in the URI and they are. We simply added that to the log command and now we are set.
Thanks everyone, this was very helpful.
