I particularly noted this one because I have been looking for a solution to the firewall popups that appear on our user's devices. Overall of course the firewall is a good thing, but I like to keep the experience of our users seamless whenever possible, and incomprehensible (to the user) firewall popups do not make for a seamless experience.
One example of this is the RSA SecurID software for our BlackBerry devices, which we deploy so our users do not need to carry around a hardware token. The first thing this software does when installed on the device is listen for a software token which is wirelessly pushed to the device via a separate app.
This listening process constitutes a 'server' on the device, so upon installation we see the following firewall popup:
Now if I am pushing this software from the server to a device out in the field, then based on this screen the end user will be confused as to what to do. 80% of the time they may choose correctly and scroll down to click allow, but that other 20% may result in a support call.
So is it possible to:
1) Set the 'Allow' rule in the device's 'Firewall Settings' database in SQL
2) Push the 'Firewall Settings' configuration down to the device
3) Push the application and have it immediately begin listening for a token without user input?
Let's find out!
First we will monitor the SYNC log again to see if anything gets backed up to the server when an option on this firewall prompt is selected.
The first thing I notice is that if I leave the "Don't ask this again for:" box unchecked, then nothing happens... I see no log entries on the server side. If I reset the app and enable the listener again, this time choosing to check the box, however:
... voila! I do see something coming through to the server:
[60000] (02/11 11:50:51.111):{0x1710} [ODBCRecord::DoSetValue] DATA = "DbVersion[0] Data[0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000] UserConfigID[17] DatabaseName[Firewall Options] UID[1] ".
This tells me that my hunch was correct, and that any saved settings are stored in the 'Firewall Options' configuration, and therefore backed up to the server. Good news!
So let's now reset everything and query the 'Firewall Options' configuration to see the default value as compared to the updated settings:
0x1100000005000004000003000002000001000000 (Default)
0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 (RSA Allowed)
It looks like the first numbers were changed from 11 to 27, then a bunch of numbers were inserted, extending the configuration string. I am guessing that this new set of numbers uniquely identifies the SecurID server application and the 'Allow' setting I chose.
If we reset the app, then choose 'Deny' here is what the string becomes:
0x270000010107536563757249440001046874747000060000000005000004000003000002000001000000
Everything is the same except for a single number, the '2' about 2/3 of the way through the string has changed to a '6'. So perhaps a '2' means allow, and a '6' means deny. Let's try clearing everything out, and then pushing the 'allow' string to the device before the software push:
use BESConfig
UPDATE SyncBackupRestore SET Data=0x270000010107536563757249440001046874747000020000000005000004000003000002000001000000 WHERE UserConfigID = 17 AND DatabaseName = 'Firewall Options'
UPDATE SyncConfig set SyncType=1 WHERE UserConfigId = 17 AND SyncDataSourceId=11109
go
Now we reload the application, and...
Bummer.
Guess I'll have to keep digging on this one...
[Update 2/13/08]
I have been gently reminded of the use of application control policies by a fellow blackberryforums.com member, ACJones. By setting a policy on the software configuration for the RSA SecurID software, and modifying the 'Internal Network Connections' option from 'Prompt' to 'Allow', you can avoid the initial firewall prompt completely upon OTA installation!
I have tested this and it works flawlessly. Thanks AC!
