[MisterGriffiths]

We have recently moved to using Bluecoat Proxy Servers in our environment but believe the Authentication (Credentials) Caching on the Proxy is causing unexpected results when browsing from the handhelds.

Unfortunately, I'm not the technical resource who's responsible for the Proxy environment so please forgive me in advance if I've misunderstood something.

BES environment: BES 4.1.6 MR2 (MDS running on same server as BES), Exchange 2003 SP2 (not really relevant by hey), Windows Server 2003 SP2, BlackBerry 9000 (Bold) - Handheld OS 4.6.0.134 & 4.6.0.162
MDS Config: Support HTTP Authentication = TRUE, Authentication Timeout = 86400000 (the maximum 24 hours), Support HTTP Cookie Storage = TRUE, No Credentials applied to the Proxy Config so uses have to enter their own credentials for browsing.
Proxy environment: Blue Coat SG Appliance Model 810-B, Software Version SGOS 5.2.2.5 Proxy Edition

We want to retain HTTP Authentication on the MDS as some users have elevated access rights to some websites, while others do not.

We currently have the Proxy Server's Credential Caching period set to 15 minutes which I believe means the proxy will not request further authentication from the same originating IP address for that period. As webpage requests for BlackBerrys all originate from the BES/MDS we have found that users are piggybacking off the credentials of other users when browsing from the BlackBerry.

In our tests we gave one test user (BBUserA) access to a certain website and then prohibited access to that site for the second test user (BBUserB).

If the second test user (BBUserB) attempted to browse to the prohibited site, they were prompted to enter their credentials and then given the Block Page (as expected). If within the same 15 minute period, the first test user (BBUserA) then attempts to access the same site (for which they have been granted access) they are not prompted for any login credentials and immediately shown the Block Page.

We then waited 15 minutes. BBUserA attempted to load the page, was prompted for credentials and the page was shown (as expected). Within 15 minutes, BBUserB attempted to load the page, wasn't prompted for credentials and the website loaded (even though this user was prohibited from viewing this website).

We can only assume this is due to the Proxy Server's Authentication Caching. We don't really want to disable that feature on the Proxy, so I suppose the questions here are:

Does anyone else out there have the same configuration as us and know of a way to get the Bluecoat and MDS to work together so we can retain proxy authentication caching?

Is there some way of making the MDS present itself to the Proxy so it believes it is receiving requests from separate unique entities?

[Neo3000]

Hi,

We have a similar setup with BES and BlueCoat but we are not using credential caching.
It is possible to include PIN and/or email in the http header the MDS sends out to the proxy (refer to KB03275). I am not sure, if BlueCoat can take this header field into account when authenticating on the base of the IP.

I thought this feature could be used for enabling the proxy to log access per blackberry PIN - but this does not seem to be possible from the BlueCoat side.

Anyway, I would be interested to know if this helped and how you solved your problem.

Greetings,
Neo3000

[MisterGriffiths]

Originally Posted by Neo3000

Hi,

We have a similar setup with BES and BlueCoat but we are not using credential caching.
It is possible to include PIN and/or email in the http header the MDS sends out to the proxy (refer to KB03275). I am not sure, if BlueCoat can take this header field into account when authenticating on the base of the IP.

I thought this feature could be used for enabling the proxy to log access per blackberry PIN - but this does not seem to be possible from the BlueCoat side.

Anyway, I would be interested to know if this helped and how you solved your problem.

Greetings,
Neo3000

Excellent thanks Neo3000, that's the KB I've been looking for to investigate another issue we have.

I will chat with the guys who look after the Proxies and see if we can use this in anyway to address this problem.

Will update this thread when I have the results.

[MisterGriffiths]

Realise it has been some time since updating this thread.

We did resolve our issue of piggybacking by setting the Bluecoat Proxy Authentication Mode from 'ProxyIP' to 'Proxy' but have found some other issues in the process.

Users with passwords that exceed 14 characters are unable to authenticate through the BlackBerry Browser and any users with a colon ( in their password are also unable to authenticate.

In addition to this, we find that any user who enters their password incorrectly on the first credentials request but then enters their password correctly on the second request, is once again prompted for their credentials a third time, even though on the second request they entered the correct password.

Has anyone else had any issues with passwords and authentication through the BlackBerry Browser?

[bl4gg3r]

hi, i know this is a bit old now, but i have a similar-ish setup / issue:

our bluecoat proxy in transparent mode is set to 'cookie'

blackberry users are presented with an authentication form based on the client address (which is always the BES MDS box)

the BES MDS is set to accept cookies, http auth, sensible timeouts etc

this all works except...

PROBLEM:

when you navigate to a new site on the blackberry it prompts for credentials each time. it's fine so long as you stay within a domain, then it prompts for auth again.

any ideas on how to get around this?

thanks very much

[MisterGriffiths]

Found this explanation of Form-Cookie mode in the Bluecoat KB.

Form-Cookie: A form is presented to collect the user's credentials. The cookies are set on the OCS domain only, and the user is presented with the form for each new domain. This mode is most useful in reverse proxy scenarios where there are a limited number of domains.


Would this not suggest the behaviour you are seeing is as expected. Or have I misunderstood the explanation.

[bl4gg3r]

THANK YOU!!

you have sorted me out, that KB gave me the info i needed - what i have done is set the authentication to Form-Cookie-Redirect and now the auth persists accross domains...

cheers

[MisterGriffiths]

I meant to include a link to the KB, just realised I forgot so sorry about that.

Glad you have it sorted.

As you are in a similar configuration to us, do you know if you have any issues with passwords that are 15 characters or longer? Or if you use a Colon in the password, does this also fail?

[MisterGriffiths]

That will learn me for giving help before getting my own question answered!!