locked
Non FQDN and IP based access RRS feed

  • Question

  • We have SharePoint 2013 published through UAG and everything works fine using FQDN http://site.company.com.  In addition to this we would like to make http://shortname and http://1.2.3.4 (IP address) available to users as well but this must also run through UAG.

    Is there any way to accomplish this?  I cant seem to figure out how to tell UAG to also respond on other names (or plain IP) for a given trunk.

    Seems like a simple thing, I am clearly missing something?

    Monday, December 9, 2013 7:47 PM

Answers

  • Worked with PSS, they had no answer.

    We ended up making the default UAG error page (that is seen when browsing shortname or IP) be a response.redirect to the FQDN.

    Dirty hack but it worked

    • Marked as answer by jb1677 Friday, January 17, 2014 3:11 AM
    Friday, January 17, 2014 3:11 AM

All replies

  • Hi jb,

    There are several problems with your scenario:

    1. In general, UAG supports only one "Public Host Name" - this is because as part of the authentication phase, the UAG needs to do some redirects and those redirects use absolutes links with the public hostname.

    2. The UAG is most cases use SSL, when using SSL, you need to place a certificate that will match the public hostname, so if the certificate is set for the fqdn and the user type IP address - they will get an SSL warning claiming the site they are trying to access have a certificate for a wrong host name ...

    3. Specifically for SharePoint (and other applications with a public hostname) the UAG require to use a domain cookie. This is well described in the beginning of the following old IAG kb (AAM used to be the name for "Application Specific hostname" in the old IAG):

    http://support.microsoft.com/kb/975491

    Hope this clarify the issue..

    Ophir.

    Wednesday, December 11, 2013 5:45 PM
  • Worked with PSS, they had no answer.

    We ended up making the default UAG error page (that is seen when browsing shortname or IP) be a response.redirect to the FQDN.

    Dirty hack but it worked

    • Marked as answer by jb1677 Friday, January 17, 2014 3:11 AM
    Friday, January 17, 2014 3:11 AM