[d_fisher]

Originally Posted by billyball2

This thread should be a sticky. The inability to remove an IT policy by wiping the unit is a serious flaw in the design of BlackBerry.

I don't agree with that statement. I dont see it as a flaw, I see it as security. If someone steals my BlackBerry, I dont want them to EVER be able to use it. But that is just me, I am a d***head about things like that.

[KonTiki]

Well I just got home from work and tried the new policy to see if it would fix the wireless connection problem and unfortunately, it did not work. The phone is obviously still free of an IT policy but when I went to try the Wireless synch it was the same as before. Dan I still want to thank you inmensely for having taken a crack at it.

[mobile_pheen]

Originally Posted by DaddyRick

I coomend Dan for doing this and he clearly gives a strong statement regarding what KonTiki just posted.

In my case I let a friend borrow my BB, while I used my Palm Treo, he had it connected to his companies BES. His company was of no help neither was Cingular or RIM. My BB was just about rendered useless to me. Now I can use it again.

Thanks Dan!

i read the whole post.. what amazes me is how ur pin matches ur nickname

is that something you made up or is that your real pin?

[dan1e1w]

Hi, okay it seems that the newer Policy.bin (bt-policy.bin) still isn't enabling Bluetooth.

Does anyone know the Policy.inf syntax to enable bluetooth? I guessed at the following:

DisableBluetooth {policy} = false
DisableWirelessBypass {policy} = false
DisableDesktopConnectivity {policy} = false
DisableDiscoverableMode {policy} = false
DisablePairing {policy} = false
DisableBluetooth {policy} = false

... but this doesn't appear to be working. I'd guess that someone with a newer BES could find this out using the ITPolicy tool.

Sorry the last one didn't work, like I said, I can't test this stuff

Dan.

[KonTiki]

Dan no need to be sorry, you singlehandedly are doing for so many here what has been a real issue for a long time. Thank You.

[RemyJ]

Originally Posted by dan1e1w

Hi, okay it seems that the newer Policy.bin (bt-policy.bin) still isn't enabling Bluetooth.

Does anyone know the Policy.inf syntax to enable bluetooth? I guessed at the following:

DisableBluetooth {policy} = false
DisableWirelessBypass {policy} = false
DisableDesktopConnectivity {policy} = false
DisableDiscoverableMode {policy} = false
DisablePairing {policy} = false
DisableBluetooth {policy} = false

... but this doesn't appear to be working. I'd guess that someone with a newer BES could find this out using the ITPolicy tool.

Sorry the last one didn't work, like I said, I can't test this stuff

Dan.

The ITpolicy tool that came with the 4.0.4 trial wouldn't recognize any of the bluetooth settings but the BES itself certainly does.

[dan1e1w]

Interesting...

You can actually "force" the ITPolicy tool to recognize those settings by adding them to the keyword.txt file, that's how I added them in the first place... Just need to know the correct keys names. In the Drop Down of Keys (in the menu bar of the ITPolicy tool), is there anything that resembles:

Disable Wireless Bypass

or

Disable Desktop Connectivity

Apparently these are the killer settings

Dan.

[blackberry7750]

Originally Posted by dan1e1w

Just need to know the correct keys names. In the Drop Down of Keys (in the menu bar of the ITPolicy tool), is there anything that resembles:

Disable Wireless Bypass

or

Disable Desktop Connectivity

Dan,

I just took a look at all the options for an IT Policy on our BES and under the "Bluetooth Policy Group" there is an option "Disable Wireless Bypass"

Hope this helps.

[KonTiki]

Originally Posted by blackberry7750

Dan,

I just took a look at all the options for an IT Policy on our BES and under the "Bluetooth Policy Group" there is an option "Disable Wireless Bypass"

Hope this helps.

If you look at this he already has that as an option unless you mean something else:

DisableBluetooth {policy} = false
DisableWirelessBypass {policy} = false
DisableDesktopConnectivity {policy} = false
DisableDiscoverableMode {policy} = false
DisablePairing {policy} = false
DisableBluetooth {policy} = false

[blackberry7750]

oops - sorry.....than I'm not sure what he's looking for.

(if you already know this then disregard but when going to set either "disable wireless bypass" or "disable desktop connectivity" it says "This rule applies only to Java-based BlackBerry devices version 4.1.0 and higher")

[jibi]

Dan, the IT Policy generator you are using was released with BES 3.x and has continued to live on through 4.x. In other words, no extra options, even by way of 'forcing' it, will be available.

[jibi]

Originally Posted by billyball2

This thread should be a sticky. The inability to remove an IT policy by wiping the unit is a serious flaw in the design of BlackBerry.

I used the original .bin file and it worked like a charm...

This thread will NEVER be a sticky - heck, it might even be deleted by another moderator at some point in time. To those of us who operate within the corporate world of BlackBerry, we take our security quite seriously. With the way some people on here rant about their corporate policies being pushed down on their handheld and they are looking for a policy.bin file to remove the security from it - that kind of crap really pisses me off.

I do have sympathy for those who purchased handhelds from eBay or left a company or something along those lines, though... that's the only reason I won't delete these kind of threads.

[madmarvcr]

if you take security seriously, banning a thread or hiding the obvious from users will not solve the security issue here. Relying on a users ignorance or hiding facts, is not the correct way to impliment security. That's Microsoft's way.

The correct approach should have RIM 1) fixing the security flaw and 2) allow rightful owners to completely wipe the device. If you keep this thread alive, maybe someone at RIM will stumble across it, and maybe it will get fixed.

Also, there is nothing wrong with buying a used item from Ebay. If we use that logic, no one should buy a used car, used computer, used house, or used anything. Everyone should just buy new.

Dan is a hero for providing easy and simple to follow instructions to wiping a blackberry.

[tomryan]

Originally Posted by madmarvcr

if you take security seriously, banning a thread or hiding the obvious from users will not solve the security issue here. Relying on a users ignorance or hiding facts, is not the correct way to impliment security. That's Microsoft's way.

The correct approach should have RIM 1) fixing the security flaw and 2) allow rightful owners to completely wipe the device. If you keep this thread alive, maybe someone at RIM will stumble across it, and maybe it will get fixed.

Also, there is nothing wrong with buying a used item from Ebay. If we use that logic, no one should buy a used car, used computer, used house, or used anything. Everyone should just buy new.

Dan is a hero for providing easy and simple to follow instructions to wiping a blackberry.

There's two sides here and its unfortuante that they (RIM) haven't determined a way to allow a blackberry to be reset (including policy) that is exposed to the user.

My personal opinion is that those of us (myself included) who are BES Admins need to ensure that we remove restrictive policies from BB's as they are decommisioned. If we did that, we would not have an issue, BB's that were showing up on ebay/etc with restrictive policies would be known to be stolen...

of course, I also think as a user who purchases a device (legitimately), should have the ability to remove these restrictions, since they are the purchaser and ultimate owner of the device.

as a bes admin (as recently mentioned in another thread), if a bb was stolen I could send a restrictive policy and then kill it.. it would be useless to the person who "took" it.. if they know how to remove this policy, they can resell it and its up to the carrier(s) to handle the (cross) reporting of stolen devices..

I guess you can't have your cake and eat it too..

[ebgreen]

There is a difference between providing information on a security hole and providing the files to explicitly exploit it. Having said that I can sympathize with people that by a restricted device on Ebay. Even with my sympathy, as an admin in a corporate environment, I would still come down on the side of Caveat Emptor.

[KonTiki]

I made a promise to someone not to post here any further and continue this but I am sorry for breaking it since I do need to addresss this, and it will be my last post on this topic.

Rim does have to address this issue, it is a legitimate one, and yes if admins made sure that when decomissioned or removed from the BEs that policies be removed we would not be here. But neither of this issues has been addressed well enough otherwise we would not be here.

I have a simple solution that Rim might want to look at: If the concern is the wrong person removing the police and circumventing restrictions, I will tell RIM add one more restriction. If someone removes the IT policy then that device will nto work on the BES any longer unless it was brought back to the IT administrator. This would allow for the policy removal and at the same time wiping the BB ala Kill command so it be useless to anyone wanting to break security, yet allowing a legitimate user the benefit of the full device.

Now if you are trying to break security and remove the policy, then lets see you talk your way out of it with your employer. That would deter anyone without legitimate reasons from trying.

[ebgreen]

Except for people selling a stolen device who would still be able to profit from illegal activities.

[CanuckBB]

Removing a device from the BES should automatically wipe it of data and policy. There should also be a way to let RIM know of stolen devices so that they may never be activated again.

[dan1e1w]

Originally Posted by jibi

Dan, the IT Policy generator you are using was released with BES 3.x and has continued to live on through 4.x. In other words, no extra options, even by way of 'forcing' it, will be available.

This isn't true. Keywords.txt lives in the same directory as ITPolicy.exe - essentially a properties bundle that is used by ITPolicy.exe as the master list of valid key names. Adding another key definition to this list enables you to set that property, and it does make it's way into the bin file.

I guess what I'm trying to say is that the actual tool is the same across versions, only the Keywords.txt changes...

Okay, new question, can someone send, or post/email the contents, or post/email the relevant lines of the latest Keyword.txt file?

Ta, D.

[jibi]

What I'm saying is that the keywords.txt has been the same from 3.6 base installation to 4.1 base installation - nothing has changed about this since day one. It was not meant for what you're trying to do (meant for legacy desktop-pushed policies only - I would assume for Redirector configurations who didn't have a BES), and I'd dare to say that it won't be updated again. You may be right, but I personally do not think that it will work with the more recently added policy options (VoIP, WLAN, BBMSGR, BT, etc).

We attempted all of this a few months back (when the 7100i was released) with the guessing games - nothing worked.

http://www.blackberryforums.com/show...uetooth+policy