locked
OWA 2010 behind UAG 2010 and Public vs. Private timeout w/ UAG doing Auth Proxy RRS feed

  • Question

  • I see where this type question was asked before but no real answer was specified, so here goes again:

    When UAG is doing an Auth Proxy to a BE CAS server hosting OWA with NTLM/KCD/Basic authentication support, we are not getting public cookie timeout of 15 minutes, it is defaulted to the 8 hours which is specified in the UAG trunk to support private computer support in OWA.

    Is there a fix or work around for this outside of not having the UAG do a auth proxy, but rather enable FBA on the CAS themselves and pass the initial request straight to the CAS server?

    -Rob

    Monday, October 3, 2011 11:44 AM

Answers

  • Hi Rob,

    when publishing a site through UAG (/w SSO) then the session life time is alway controlled by the UAG trunk settings.

    If you wan't to have a seperated session life time for the applications (in addition to the trunk time outs), then you have to skip the build-in SSO part and authenticate to the published application manually (via Forms!) or through a custom coded SSO forms authentication trampoline.

    But keep in mind that the custom authentication trampoline wouldn't allow you to have a strict session life time, since if the users jumps on the trampoline again he will refresh the timeout values...

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    • Marked as answer by Alexw20006 Thursday, October 6, 2011 11:01 AM
    Thursday, October 6, 2011 7:55 AM

All replies

  • Does UAG identify the client as non-private correctly?

    Have you done anything with the privileged endpoint policy? 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Wednesday, October 5, 2011 8:41 AM
  • No endpoint components are being installed since this is a dedicated trunk for Webmail access.  In theory it should default to all cients being Public....but even then, I dont get a 15 minute time out.  Timeouts are all based on the truck config under Sessions....the public or Private selection on the OWA FBA page does nothing.
    Wednesday, October 5, 2011 10:39 AM
  • Sorry, bit confused by your replies...

    You have disabled endpoint components then?

    Is the CAS configured for FBA then?

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, October 5, 2011 10:47 AM
  • Endpoint components are disabled.  CAS server are set for Integrated authentication since FBA on the CAS servers behind a UAG is not a supported config.  Authentication is done on the UAG and then passed thru to the CAS via KCD.
    Wednesday, October 5, 2011 10:53 AM
  • You say that as if I don't know...just trying to help and understand your setup ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, October 5, 2011 11:09 AM
  • Hi Rob,

    when publishing a site through UAG (/w SSO) then the session life time is alway controlled by the UAG trunk settings.

    If you wan't to have a seperated session life time for the applications (in addition to the trunk time outs), then you have to skip the build-in SSO part and authenticate to the published application manually (via Forms!) or through a custom coded SSO forms authentication trampoline.

    But keep in mind that the custom authentication trampoline wouldn't allow you to have a strict session life time, since if the users jumps on the trampoline again he will refresh the timeout values...

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    • Marked as answer by Alexw20006 Thursday, October 6, 2011 11:01 AM
    Thursday, October 6, 2011 7:55 AM
  • Sorry about that....the joys of emotionless blog responses.  I was rushing out the door for work.  Thanks for taking time to respond to my questions!
    Thursday, October 6, 2011 10:51 AM
  • That is what I was afraid of.  We have been throwing around the idea of not having the UAG doing the auth and enabling the CAS FBA support directly, but this is not ideal since we got our Security Dept's buy-in on using Forefront UAG on its SSO support of multiple apps.  We will be turning on RSA SecurID in the very near future, and doing that on the CAS directly is not as "pretty" and functional as the UAG.

     

    While this is not  a "major" problem (cookie timeouts of public vs private) with the UAG....it is sloopy.  It needs to be documented and removed from the UAG OWA "Look and Feel" the support of public and private option, it should be just one timeout period (15 minutes max).  Staff needing extended sessions of inactivity on OWA need to be at home using Outlook Anywhere, RDP to an internal desktop, or VDI.

     

    -Rob

    Thursday, October 6, 2011 11:01 AM
  • Irrespective of that though, it sounds like you core trunk timeout functionality is broken. If you provide access to a portal, do you get the correct timeout value? I am assuming OWA is published using an application specific name, as opposed to via the portal.

    I have several customers using OWA via UAG and to my knowledge they get the correct public option with an appropraite low timeout. They then configure the OWA Private Computer policy to define what requirements will trigger the Private computer element. With the correct policy and endpoint device, you then get corporate machines who automatically get defined as private computers and get the better timeouts. All machines that don't meet the corporate policy then fallback to the default Public option.

    For this to work though, you need the endpoint components to assess the machine for policy match, which you don't have (or want).

    Let me try and test, to see if I get the same results as you...

    Cheers

    JJ

     


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, October 6, 2011 11:26 AM
  • Hi Rob,

    whats the reason to have the manual Public/Private radio button, when UAG could controll this option for you automatically using the endpoint detection and normal/priviledge trunk settings?

    Its more an improvement that a limitation compared to the build-in OWA options if you ask me^^ :)

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Thursday, October 6, 2011 2:31 PM
  • There are a few aspects to this question:

    First, is the overall security implications of a manual public vs private timeout and trusting the user to select the appropriate option.  This should not even be an option...its 15 minutes of inactivity and thats it.  If users need extended access, they should use other means as state in a post above (RDP, VDI, etc...).

    Second is the mere fact that UAG offers the option, that doesnt even work unless endpoint components are deployed.  Remember, Exchange publishing is done via a built-in wizard and templates.  If End point components are required for UAG to allow public vs private timeouts...then make that a check point for those options to even be displayed.  To put them there and then not have them work, as well as using other timeout values on the trunk is not desirable at all.  UAG is touted as a secure perimiter application, it needs to be documented better that these factors are required, timeouts are defined differently for theses "published" applications, and endpoint component requirements, or simply do better dependenacy checking.

    Lastly,  endpoint component requirements for a simple web application to check email is not ideal.  This is simple, login, check email, logout.  This could be access from any number of locations that probably wouldnt pass, or even if they did, does it warrant a cookie timeout variable?

    Dont get me wrong, UAG is an excellent product, but to allow options that simply dont work and produce different results that are not documented...not good. 

    What seems to best in the interest of security and not confusing end users...is to just use a single 15 minute or less timeout for webmail published via the UAG.  Hopefully Microsoft will removethese options to strengthen the product (UAG) and its abilities.

    Thursday, October 6, 2011 2:58 PM
  • The default Exchange wizard would doesn't disable endpoint components to my knowledge; this has to be done manually on the trunk itself.

    If you are using UAG without endpoint detection for simple web-apps, I think you should save a lot of money and just use TMG instead. The whole point of UAG is to extend standard reverse proxy functionlaity to add feature sets like endpoint assessment, cache cleaning etc. that allow for application functionality tailoring based upon the security state of the client machine.

    Out of the box UAG assumes you will be using endpoint components as this is you get the full feature set. If you disable this feature, of course it will have an impact on UAG functionality...not sure this could be called a failing of the product though...

    I think leaving security decisions like public/private to end users is a recipie for disaster if you ask me; this is why I especially like the UAG approach that bases the decision on a administrator defined policy to determine what "private computer" means to the organisation setting policy.

    Maybe I have misunderstood something along the way though, let me know...

    Cheers

    JJ

     


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, October 6, 2011 3:54 PM
  • I do understand where you are coming from. But remember, TMG is for outbound user access management, UAG is for inbound.  From a security perspective, ANY security product that will assume something has already failed a basic security test...no aasumptions.   Assumptions  =  weakness / exploit.  If we assumed stuff then we wouldnt need end-point component features of the UAG :-).

    just so you know my perspecitive....I am a HUGE fan of the Forefront product line.  I want to see this application used more and more, but we are competing with prodcuts such as F5 ASM, Cisco ASA, etc...that will use any short coming to knock it down. 

    I see the UAG as more then a simple reverse proxy.  URL filtering, HTTP/S traffic inspection, etc....are some of the features that are still used even when endpoint components are not.

    I still recommend that the UAG simply remove Public / Private as a OWA look and feel component UNLESS it detects that the endpoint components are set to be used.  Just closes some gaps in security hardening. Sometimes we have to protect ourselves from ourselves.. :-)

    Thursday, October 6, 2011 4:13 PM
  • ...TMG is for outbound user access management, UAG is for inbound. 

    Strategically, perhaps, but TMG is more than capable of providing protection for both Exchange and SharePoint; UAG is not the ONLY option. In fact if you disable endpoint protection in UAG, there is probably very little between them for reverse proxy duties when publishing OWA...

    I agree there could be some better logic, I guess MS expect people to not disable endpoint components if they have invested in UAG...

    P.S. I know you weren't product bashing; constructive criticism is always a good thing and healthy for the community ;)


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Thursday, October 6, 2011 4:19 PM
  • Jason, if you are going to quote from a post....please do it accurately.  Kindly edit your post above to reflect what was actually said.

    Thanks.

    Your Cut:

    I do understand where you are coming from. But remember, TMG is for outbound user access management, UAG is for inbound.  From a security perspective, just so you know my perspecitive....I am a HUGE fan of the Forefront product line. 

     

    What was actually said:

    I do understand where you are coming from. But remember, TMG is for outbound user access management, UAG is for inbound.  From a security perspective, ANY security product that will assume something has already failed a basic security test...no aasumptions.   Assumptions  =  weakness / exploit.  If we assumed stuff then we wouldnt need end-point component features of the UAG :-).

    just so you know my perspecitive....I am a HUGE fan of the Forefront product line.  I want to see this application used more and more, but we are competing with prodcuts such as F5 ASM, Cisco ASA, etc...that will use any short coming to knock it down. 

    Thursday, October 6, 2011 7:53 PM
  • Ooops, that wasn't intentional, I didn't mean to leave the text after the word "inbound". I have amended it now...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, October 6, 2011 8:51 PM
  • Tuesday, October 18, 2011 8:10 AM