locked
AAM & Search & credential pop-ups RRS feed

  • Question

  • I have a dilemma - If I set up the AAM one way then crawling works but users get annoying pop-ups asking for their credentials; if I set up the AAM differently then the pop-ups go away but crawling doesn't work.

    This is our environment:

    • Server farm with 1 WFE (with SharePoint 2010 Enterprise) and 1 DB server
    • From within our network we can access our SharePoint site using either the local server URL (SPServerName.domain.com) or the public URL (sharepoint.domain.com); DNS directs both to the site through an internal IP address.
    • When on the server I can only access the site through SPServerName.domain.com. 

    The AAM is set up as follows:

    With AAM set up this way crawling does not work.  In order for crawling (and hence search) to work I have to add this entry in the AAM:

    • Internal URL: https://SPServerName.domain.com
    • Public RUL: https://SPServerName.domain.com
    • Zone: (any other)

    However, if I do that then users get the annoying pop-up asking for their credentials, and the pop-up does not accept their credentials.  The pop-up window displays the URL https://SPServerName.domain.com.  (Although I'm not certain, the pop-ups may be coming up from Office apps.)

    If anyone is help I would be much obliged.

    Thank you.


    David

    Thursday, June 28, 2012 7:31 PM

Answers

  • AAM Configuration:

    https://SPServerName.domain.com    Default Zone (Make sure this url is present in your SharePoint Search Content Source)

    https://sharepoint.domain.com          Intranet Zone (Make sure this url is present in your SharePoint Search Content Source)

    So your AAM for the Web Application would look like this:

    URL:                                                               Zone                                                  URL

    https://SPServerName.domain.com                  Default                                     https://SPServerName.domain.com

    https://sharepoint.domain.com                        Intranet                                   https://sharepoint.domain.com

    Login Prompt Issue:

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

    On your WFE try Disable loopback check or BackConnectionHostNames

    Note* While Making any changes in registry make sure you perform export/backup of your registry.

    Also add the site url by which users access the site, add that url in Local intranet zone of your IE Settings.




    • Edited by James-SharePoint Tuesday, July 3, 2012 5:30 AM wanted to add a note.
    • Marked as answer by dgunnlds Tuesday, July 3, 2012 8:23 PM
    Tuesday, July 3, 2012 5:28 AM

All replies

  • Hi David,

    It would be helpful if you can give us some info on what is being reported in your crawl logs.  Are you seeing errors?

    In the meantime, you can try setting the AAM up the first way (where the users do not get prompted), and then use HOST file entries on the SharePoint servers to force sharepoint.domain.com to resolve to 127.0.0.1, and then start up a crawl again.


    Mike Dalton
    SharePoint Engineer
    Rackspace Hosting
    blog: mikedalton.net
    twitter: twitter.com/mikeelliot

    Thursday, June 28, 2012 8:51 PM
  • Mike,

    Thank you for your reply.

    I added the hosts file entry and crawled but it didn't succeed.

    I'm seeing 3 Successes, 0 Warnings, 1 Error, 0 Top Level Errors.  When crawling was successful I was seeing 41K+ successes.

    The successes are:

    sts4s://SPServerName.domain.com/contentdbid=...

    sts4s://SPServerName.domain.com

    https://SPServerName.domain.com

    The error is:

    https://SPServerName.domain.com This item could not be crawled because the repository did not respond within the specified timeout period...


    David

    Thursday, June 28, 2012 10:23 PM
  • Hi David,

    It sounds like your "Local SharePoint Sites" content source in search is still trying to crawl https://SPServerName.domain.com even though you've changed the AAM.  I'd recommend editing the "Local SharePoint Sites" content source and making sure that the entry used for the site is https://sharepoint.domain.com.


    Mike Dalton
    SharePoint Engineer
    Rackspace Hosting
    blog: mikedalton.net
    twitter: twitter.com/mikeelliot

    Friday, June 29, 2012 1:17 PM
  • Thanks Mike but that won't work because crawling only works using https://SPServerName.domain.com.  Our SharePoint site can only be reached from the server by using https://SPServerName.domain.com; hence that is the only URL that the search service app can crawl the site with.  It cannot reach https://sharepoint.domain.com from the server.

    Earlier on in my investigation I tried the change that you suggest and started a crawl.  The result was that the 41K+ results that were in my index got deleted.

    So the big question is....why are users getting prompted for credentials if I include https://SPServerName.domain.com in the AAM?


    David

    Monday, July 2, 2012 10:27 PM
  • AAM Configuration:

    https://SPServerName.domain.com    Default Zone (Make sure this url is present in your SharePoint Search Content Source)

    https://sharepoint.domain.com          Intranet Zone (Make sure this url is present in your SharePoint Search Content Source)

    So your AAM for the Web Application would look like this:

    URL:                                                               Zone                                                  URL

    https://SPServerName.domain.com                  Default                                     https://SPServerName.domain.com

    https://sharepoint.domain.com                        Intranet                                   https://sharepoint.domain.com

    Login Prompt Issue:

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

    On your WFE try Disable loopback check or BackConnectionHostNames

    Note* While Making any changes in registry make sure you perform export/backup of your registry.

    Also add the site url by which users access the site, add that url in Local intranet zone of your IE Settings.




    • Edited by James-SharePoint Tuesday, July 3, 2012 5:30 AM wanted to add a note.
    • Marked as answer by dgunnlds Tuesday, July 3, 2012 8:23 PM
    Tuesday, July 3, 2012 5:28 AM