none
UAG 2010 / Moss 2007. You are not authorized to access this application. RRS feed

  • Question

  • Hi,

    We are publishing a single SharePoint app with UAG 2010.

    Configuration:

    - Moss 2007 SP1 (yeah, upgrading soon). 2 x Windows 2008 WFE (no load balancing) / 1 Windows 2008 / SQL 2005 DB server.
    - UAG 2010 trial.
    - External / internal url's are the same however external access is https. I am using a temporary certificate for https - certificate is trusted by browsers but common name does not match public host name of published app).
    - Trunk url: trunk.somebiz.com App url: app.somebiz.com
    - Windows Authentication. UAG 2010 authenticates users successfully against AD.
    - Sharepoint app is a Site collection based on Collaboration Portal Publishing template with a number of sub-sites. The SharePoint site is fully functional without problems internally and via extended web apps externally (both Windows and Forms authentication)
    - Since internal / external url is same from what I can tell we don't need to configure any special AAM so haven't. Not 100% sure about this...

    Our problem when publishing via UAG is that unless we specify the actual page name when accessing the site we get permission denied errors.

    e.g.

    https://app.somebiz.com does not work. https://app.somebiz.com/pages/default.aspx does work.

    https://app.somebiz.com/site1 does not work. https://app.somebiz.com/site1/default.aspx does work.

    User receives this error:

    You are not authorized to access this application.

    Web monitor error is:
    A request on trunk namex; Secure=1 failed because of an unknown application. The URL is /site1/default.aspx. The source IP address is x.x.x.x.

    Remember, the url that produces the error is https://app.somebiz.com/site1. If I use https://app.somebiz.com/site1/default.aspx then it works.

    Bamboo World Clock & Weather webpart images don't display either. Web monitor error is:

    A request on trunk namex; Secure=1 failed because of an unknown application. The URL is /wpresources/Bamboo.WorldClockAndWeather/Images/34S.png. The source IP address is x.x.x.x.

    I also get the same error uploading files - however going back and refreshing the doc library page and the file is there.

    Any ideas?

    Thanks!!

     

    Tuesday, March 30, 2010 11:37 AM

Answers

  • Hi Andy,

    This is not normal behavior, I can tell you that, but it's also one of those things that can't be solved via this forum. I would suggest you open a support case with Microsoft CSS, and have this investigated by us. Server-side logging would typically be used in this scenario to inspect the communication process between UAG and SharePoint.


    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Wednesday, April 14, 2010 12:16 AM
    Wednesday, April 14, 2010 12:16 AM

All replies

  • I have tried re-installing UAG 2010 and recreated trunk and app but am still getting the same errors.

    I am running UAG on a Windows 2008 R2 VM (host is Windows 2008 R2).

    We are evaluating this for an Australian government department for publishing to up to 4000 users.

    Anyone else seen a similar issue?

    Thanks!

    Thursday, April 8, 2010 12:44 PM
  • Hi Andy,

    This is not normal behavior, I can tell you that, but it's also one of those things that can't be solved via this forum. I would suggest you open a support case with Microsoft CSS, and have this investigated by us. Server-side logging would typically be used in this scenario to inspect the communication process between UAG and SharePoint.


    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Wednesday, April 14, 2010 12:16 AM
    Wednesday, April 14, 2010 12:16 AM
  • Hi Andycal,

    any luck whit this, we are experiencing the same issue when uploading files?

    Sunday, July 18, 2010 10:11 AM
  • Hi,

    Did you resolve this issue? We had a working setup with SharePoint 2007 and IAG SP2, but once we changed the public hostname and AAM we ended up with this same kind of behavior. It seems that all the relative paths that SharePoint sends to IAG are interpreted incorrectly and are not considered as part of the published SharePoint application. And hence we got error 'Unknown Application' at the IAG log and the redirect to site's welcome page is not working, but direct URL does.

    BR,

    Jari

     

     

    Wednesday, December 15, 2010 11:40 AM
  •  

    Exact behavior i'm seeing with publishing SP2010 in my test lab. spext.conuab.com is my external UAG SP2010 site and has the AAM deployed in SharePoint for http://spext.conuab.com (even though I'm using HTTPS!)

    UAG is configured to be both SPTRUNK1.CONUAB.COM (10.26.15.250) and another A record of SPEXT.CONUAB.COM A 10.26.15.250

    If I access spext.conuab.com/default.aspx directly, things work (until you get to something else that expects a 302 redirect to work). 

    IE8/Windows 7

    1. (initial request) User (navigate to HTTPS://spext.conuab.com) -> UAG -> SP2010 (GET / HTTP/1.1 Host: spext.conuab.com )
    2. (UAG proxied request/401) SP2010 -> UAG (HTTP 401 Unauthorized)
    3. (NTLM start) UAG -> SP2010  (GET / Authorization NTLM)
    4. SP2010 -> UAG (HTTP 401 Unauthorized)
    5. (NTLM Success) UAG -> SP2010
    6. SP2010 -> UAG (302 Redirect -> http://spext.conuab.com/default.aspx)
    7. USer -> UAG ("GET /default.aspx)

    That redirect seemed to be my answer, though I'm not 100% on why.  Since spext is the external name for the application, if UAG saw that http://spext.conuab.edu name come through on the 302, it believes the name has already been properly overwritten.  

    The solution:

    Web Server Addresses:  sharepoint.conad.conuab.com (INTERNAL)

    HTTP Port: 80

    Public Host Name:  spext.conuab.com

    I checked "replace host header with the following:" sharepoint.conad.conuab.com

    Portal Link / Application URL:  https://spext.conuab.com

    If I uncheck replacing the host header OR use spext.conuab.com as the host headers, I start getting the error messages like everyone else.

    Tools that I found useful to debug:

     wireshark - ran on SP server, UAG server (UAG gives me a problem where I Can't see traffic UAG originates for some reason)

     livehttpheaders firefox extension

     iehttpheaders ie toolbar

    So the trick seems to be to make UAG access sharepoint by a special internal name (which could be the real site) and present to the client.  I'm not 100% you even need AAM in this configuration but I'm going to end 2010 on a win ;-)

     

     

     

     

     

     

     

     

     

     

     

     

     

    Thursday, December 30, 2010 7:56 PM