none
AAM and Extending a Web App

    Question

  • Users encountered credential prompts when I created an AAM manually and added a binding in IIS.  I found the following article that states I should delete the manual creation and extend the web application to the zone I want it in:

    http://support.microsoft.com/kb/2624320/en-us

    I started doing this on the Manage Web Applications section in Central Admin to an existing Web Site (Sharepoint - 80), then stopped because I wanted to see the settings of the current web app.

    Now, when I go back to try again, I click the current Web App, click Extend.  When I go to choose "Use an Existing IIS Web Site", the only thing available in the box is "SharePoint Web Services".  Where are the other IIS sites (Web Apps)?

    I've tried iisreset, I've rebooted the SharePoint server, and it still stays that way.  Am I losing my mind here and that's what's supposed to be there? 

    I believe I just wanted to extend the web app on the existing site and create the different host header and Public URL in the different zone...

    Tuesday, July 23, 2013 9:55 PM

All replies

  • You don't need to extend the Web Application in order to leverage multiple Alternate Access Mappings.  You really do just need to add the AAM to the existing Web Application, edit the IIS site binding, then make sure in DNS that the record is pointed correctly.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, July 23, 2013 10:13 PM
    Moderator
  • I thought maybe extending the app would resolve the following issue I have:

    Our main intranet web app is at http://mainapp (Default zone) in our domain (xyz.local).  Users internally go to http://mainapp to get there.

    A company bought ours, and now users in their domain (abc.com) need to access our SharePoint.  We have an MPLS setup between sites, two-way forest trust configured, conditional forwarders in each others domains, and I've added their domain into our SharePoint as an AD Connector and am able to add their users (abc\user) in permissions to our items/sites. 

    The issue was getting them to the site.  I chose to create an AAM called altapp.xyz.local and put it in the Internet zone (as I found out putting it in the intranet zone caused all my internal users to get credential prompts on the new AAM).  Users in the other domain then could go to http://altapp.xyz.local and get prompted for credentials (which I believe is just fixed by adding the URL to the Intranet Zone). 

    However, in my own internal LAN, if I try to go to http://altapp.xzy.local, I'm prompted for credentials, even when I put this URL into the Intranet zone, and I've added "altapp" to DNS with the corresponding IP. 

    Some of the users in the other domain travel between the two sites frequently, and right now, they have to use http://altapp.xyz.local to access our SharePoint when they are in their domain, and when they come on-site, they have to use http://mainapp. I'd like them to be able to have just a universal URL that works on-site here or at their site. I thought the fix would be to correct it somehow so that when in our domain, we are not prompted for credentials going to http://altapp.xyz.local (and thus thought maybe extending the app would be the solution).

    I had another site of the parent company (also MPLS'd, two-way trust, conditional forwarders) test putting a forward zone in DNS of our xyz.local domain and adding an A record for mainapp, so that they may be able to use the normal URL that we use internally, but they said they were prompted (even with it in the Intranet Zone).

    Hopefully none of that was confusing, and maybe you have insight to the proper solution for universal URL access?

    Tuesday, July 23, 2013 11:28 PM
  • Is this Web Application configured using Windows auth with Kerberos, or NTLM?

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, July 24, 2013 1:46 AM
    Moderator
  • It is a Claims-based Web App, configured for Windows Auth with Kerberos
    Wednesday, July 24, 2013 2:17 AM
  • Did you add the spn for the new URL?

    Get the existing SPNs for the service account running the Web Application:

    setspn -L domain\user

    If that account has the original AAM, add the new AAM to it:

    setspn -U -S HTTP/altapp.xyz.local domain\user

    You may have to do further delegation within ADUC, but that would be a start.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by TheMind Wednesday, July 24, 2013 6:57 PM
    • Unmarked as answer by TheMind Saturday, July 27, 2013 8:32 PM
    Wednesday, July 24, 2013 2:19 AM
    Moderator
  • I did not have the SPN set through the Shell nor ADUC...however I have added both, and I still get prompted when browsing to http://altapp.xyz.local.

    I didn't think about the SPN though!

    Wednesday, July 24, 2013 3:14 AM
  • Are you needing to use Kerberos (I'd recommend it, faster and more secure, plus enables double-hop scenarios)?  If not, you could switch to NTLM.

    Do you have the appropriate delegations set in ADUC (unfortunately Kerberos configuration is unique to each environment)?  Did you run an iisreset or make sure the user running the App Pool was completely logged off in order to get a new Kerberos ticket before re-testing?


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, July 24, 2013 3:16 AM
    Moderator
  • I'd prefer to stick with the Kerberos setup.  I'm pretty positive I have the appropriate delegations set in ADUC (had gone over the Kerberos guide several times back when implementing initially, ironically didn't think about delegation or SPN for this new AAM), and I just ran an iisreset and tried again, to get prompted again.

    With that said, I think it is a Kerberos issue, because I ran Fiddler2 and then tried to go to http://altapp.xyz.local and it showed "WWW-Authenticate Header is Present: Negotiate", followed by "WWW-Authenticate Header is Present: NTLM."  When I then browse to http://mainapp, it shows "WWW-Authenticate Header (Negoiate) appears to be a Kerberos reply".


    • Edited by TheMind Wednesday, July 24, 2013 3:48 AM misspoke
    Wednesday, July 24, 2013 3:47 AM
  • Yep, this is definitely a Kerberos issue.

    Kerbtray and Kerberos Event Logging should be your friends for awhile.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, July 24, 2013 3:49 AM
    Moderator
  • Well, I came in this morning to work, and tried browsing for the heck of it to http://altapp.xyz.local, and it worked.  Fiddler2 showed Kerberos reply.  Maybe one of the SharePoint processes that runs overnight restarted and allowed it to work?  I didn't think I had to do anything other than iisreset for it to take effect.

    However, oddly enough, once I browsed in to that http://altapp.xyz.local and opened a document successfully, I then tried going to the site through my normal http://mainapp and I get prompted and Fiddler2 shows Negotiate, NTLM.   Eh?

    If I then go to another computer, the http://mainapp works fine, but if I try "Login as different user" and switch to my account, i get stuck at the prompt repeatedly.

    Do I have to IISReset to clear this?  Any reason why I couldn't traverse both URLs with my same login and be successful with Kerberos?

    Wednesday, July 24, 2013 1:20 PM
  • Does the SPN HTTP/mainapp exist?

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, July 24, 2013 1:30 PM
    Moderator
  • Yes, in both setspn -L and in ADUC.
    Wednesday, July 24, 2013 1:31 PM
  • I'd suggest turning on Kerberos logging on your WFE and see what kind of errors you get in the System Event Log.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, July 24, 2013 1:38 PM
    Moderator
  • Well, it's back to how it was with getting a prompt on http://altapp.xyz.local for me and for a traveling user from one of the other sites.

    I turned Kerberos logging on the WFE, made my computer get prompted going to http://altapp.xyz.local, then looked in the System Event log on the WFE and the entry that happens is this:

    A Kerberos Error Message was received:

    on logon session

    Client Time:

    Server Time: 16:36:34.0000 7/25/2013 Z

    Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP

    Extended Error:

    Client Realm:

    Client Name:

    Server Realm: XYZ.LOCAL

    Server Name: krbtgt/XYZ.LOCAL

    Target Name: krbtgt/XYZ.LOCAL@XYZ.LOCAL

    Error Text:

    File: 9

    Line: f09

    I'll research this, but any insight you might be able to share Trevor?

    Thursday, July 25, 2013 4:39 PM
  • Yes, the client is unable to get a key that supports the encryption type.  What version of OS are the domain controllers as well as client computers?

    You may have to downgrade the encryption type via Group Policy.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, July 25, 2013 5:11 PM
    Moderator
  • The DC's are 2012, and the clients are Windows 7.  I was previously on 2003 DC's about 8 months ago.
    Thursday, July 25, 2013 5:17 PM
  • This is for both forests?

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, July 25, 2013 5:19 PM
    Moderator
  • No, sorry, that's for my forest (as I tested getting the prompts with my own user account).  The other forest has 2003 DC's, and their clients I believe are a blend of 7 and XP.
    Thursday, July 25, 2013 5:21 PM
  • I had let the logging run for a little while and the only other Kerberos events were three of these (two showed the App Pool service accounts for MainApp and MySiteApp in the ServerName and TargetName lines, the other showed the actual server name and $ in those lines):

    A Kerberos Error Message was received:

    on logon session

    Client Time:

    Server Time: 16:41:51.0000 7/25/2013 Z

    Error Code: 0xd KDC_ERR_BADOPTION

    Extended Error: 0xc0000272 KLIN(0)

    Client Realm:

    Client Name:

    Server Realm: XYZ.LOCAL

    Server Name: (mainapp_app_pool_serviceaccount)@XYZ.LOCAL

    Target Name: (mainapp_app_pool_serviceaccount)@XYZ.LOCAL@XYZ.LOCAL

    Error Text:

    File: 9

    Line: f09

    Thursday, July 25, 2013 5:42 PM
  • For Bad Option: http://blogs.technet.com/b/tristank/archive/2007/06/18/kdc-err-badoption-when-attempting-constrained-delegation.aspx

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, July 25, 2013 5:49 PM
    Moderator
  • I'm still trying to figure out what's going on with the Kerberos.  I've had unsuccessful attempts at getting DelegConfig.v2.beta to even run.  I got it running when I configured it as an application under the default website, but running the report just shows information about "localhost", and when trying to do the wizard to point it to altapp.xyz.local, it keeps asking for more and more tiers.  Configuring it as an application called deleg under the mainapp site doesn't even let the default.aspx page load (SessionStateModule is missing?), and if I try to go to http://mainapp/deleg (without /default.aspx), I just get prompted for password like I usually do on the altapp link.

    I noticed that from the second http://altapp.xyz.local starts working fine, http://mainapp starts giving prompts that I can't get through.  An iisreset fixes this so that http://mainapp works, but http://altapp.xyz.local goes back to prompts.

    Blah.

    Friday, July 26, 2013 2:19 AM
  • Is (useAppPoolCredentials="true") needed in the ApplicationHost.config file?  I'm reading this fixed Kerberos issues, but I also read that it was only needed if Kernel Mode was enabled, and I have it disabled (best practice). 

    I got the DelegConfig to give me the default.aspx page through http://altapp.xyz.local/deleg, but clicking the Report button just says Please Wait.

    Still trying.

    Friday, July 26, 2013 5:10 PM
  • I'm back to wondering if it's Kerberos or authentication issues.

    I have the http://altapp.xyz.local in Intranet Zone sites, I have it in the AuthForwardServerList reg key, the DNS entry exists for "altapp" in the xyz.local DNS zone, the AAM and IIS binding is created, yet I still get prompted for credentials internally.

    Why is it that I cannot go to both http://mainapp and http://altapp.xyz.local to access the mainapp Web App without prompts? 

    Saturday, July 27, 2013 8:38 PM
  • From a client, you should be able to without getting prompted, given Kerberos is properly configured.  I would go back to the Kernel debug log/kerb tray, and also leverage NetMon which may give you more information.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, July 28, 2013 3:59 PM
    Moderator
  • I'm running NetMon on the SP WFE, and I have KerbTray running on my client.  I tried both http://mainapp and then http://altapp.xyz.local on my client, got prompted on the http://altapp.xyz.local

    KerbTray on my client shows a ticket for HTTP/mainapp.xyz.local@xyz.local and a ticket for HTTP/altapp.xyz.local@xyz.local

    The NetMon shows this header when doing the http://mainapp: "HTTP:Request, GET /Pages/default.aspx, Using GSS-API Authorization"

    The NetMon shows this header when doing the http://altapp.xyz.local: "HTTP:Request, GET / , Using GSS-API Authorization"

    Both of those HTTP requests seem to indicate Kerberos (Authorization: Negotiate; ThisMech: KerberosToken; encryption type: RC4-HMAC)

    I'm not yet sure I can see why it's prompting me on the altapp.  Still looking.

    Monday, July 29, 2013 3:34 PM
  • Here's a note that I don't believe I stated before:  A couple of the abc.com domain users traveled to our site, and when they login to our SharePoint with http://altapp.xyz.local using their domain user account (abc\user) while in our building, they are not prompted for login...yet anyone internal here (xyz\user) gets prompted on http://altapp.xyz.local.
    Thursday, August 01, 2013 5:52 PM
  • is altapp.xyz.local or *.xyz.local in the Local Intranet zone?

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, August 01, 2013 5:53 PM
    Moderator
  • Yes, I have both altapp.xyz.local and *.xyz.local in the Intranet Zone on my machine.  The abc.com users were prompted until altapp.xyz.local was put in the Local Intranet Zone, but then auto-authentication worked fine for them after that.
    Thursday, August 01, 2013 5:55 PM
  • I don't feel at this time that this is a Kerberos issue, because when I encounter the prompts, there are no associated kerberos failure logs in the Event Viewer (the Kerberos events that do happen, such as the 0xd and 0xe mentioned above in the thread, happen on their own, several times, and don't seem related to accessing the web apps with user accounts).  I think this is authentication issues.  I just haven't pinpointed why yet.
    • Edited by TheMind Friday, August 02, 2013 3:31 PM
    Friday, August 02, 2013 3:29 PM
  • I would suggest using NetMon on the client and server to see how the AuthN issue is presenting itself.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Friday, August 02, 2013 5:31 PM
    Moderator
  • Here's the checklist I would go through
    - No Host header on the Web App (Only one binding in IIS and only one web app on that port#) Adding a binding in IIS by name makes it into a host header for IIS.  That's usually a problem for SharePoint if the host header wasn't originally created in SharePoint (ie. by extending the web app).
    - http://servername in the SharePoint Default Zone
    - http://something.domain.com as an AAM (non-extended) in any other SharePoint Zone
    - something.domain.com is in a DNS reachable by the client workstation and points to the SharePoint server
    - something.domain.com is added to the Local Intranet Zone of IE (or the Trusted Sites Zone of IE if the security settings have been changed to always send credentials in the background)
    - the client workstation is in an AD Forest Domain that has a Full Trust relationship with the AD domain where the SharePoint server is a member server
    - the user logging into the workstation is logging in with an account from the same domain as the workstation.

    If all those are in place then you should be able to use http://servername or http://something.domain.com to log into the SharePoint site without a credential prompt.  But http://something.domain.com will always require credentials if logging in from a non-domain workstation or if logging in via something other than IE configured as described above.

    Going back to your original post it sounds like you are creating bindings manually in IIS.  That means you are using host headers.  Other than the specific case of adding the FQDN address for a server Microsoft would always recommend adding new host header bindings by extending the Web Application.  But if you aren't using host headers it isn't necessary to add a new binding in IIS.


    Paul Stork SharePoint Server MVP
    Principal Architect: Blue Chip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Monday, August 05, 2013 8:37 PM
  • Here's the checklist I would go through
    - No Host header on the Web App (Only one binding in IIS and only one web app on that port#) Adding a binding in IIS by name makes it into a host header for IIS.  That's usually a problem for SharePoint if the host header wasn't originally created in SharePoint (ie. by extending the web app).
    - http://servername in the SharePoint Default Zone
    - http://something.domain.com as an AAM (non-extended) in any other SharePoint Zone
    - something.domain.com is in a DNS reachable by the client workstation and points to the SharePoint server
    - something.domain.com is added to the Local Intranet Zone of IE (or the Trusted Sites Zone of IE if the security settings have been changed to always send credentials in the background)
    - the client workstation is in an AD Forest Domain that has a Full Trust relationship with the AD domain where the SharePoint server is a member server
    - the user logging into the workstation is logging in with an account from the same domain as the workstation.

    If all those are in place then you should be able to use http://servername or http://something.domain.com to log into the SharePoint site without a credential prompt.  But http://something.domain.com will always require credentials if logging in from a non-domain workstation or if logging in via something other than IE configured as described above.

    Going back to your original post it sounds like you are creating bindings manually in IIS.  That means you are using host headers.  Other than the specific case of adding the FQDN address for a server Microsoft would always recommend adding new host header bindings by extending the Web Application.  But if you aren't using host headers it isn't necessary to add a new binding in IIS.


    Paul Stork SharePoint Server MVP
    Principal Architect: Blue Chip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    I believe that it was originally http://servername in the Default zone for the web app.  However, in the very beginning 3 years ago, I created an AAM http://mainapp in the default zone, and there is a binding for mainapp in IIS (I must have created that manually in IIS because SharePoint doesn't automatically create that if you don't extend, as you know).  I then created just recently http://altapp.xyz.local as an AAM in the Internet zone, and manually entered the binding to the mainapp Web App for altapp.xyz.local .

    Thus I have two different Public URLs in two different zones (Default and Internet) for this intranet (mainapp) web app, running on port 80. I also have MySite and Teams Web Apps, and both of these run on port 80 as well.

    altapp.xyz.local is DNS reachable by the client, points to the SharePoint server, is in the Local Intranet Zone of IE, the workstation is in the same domain as the SharePoint server, and my user account is in the same domain as well.

    How would I be able to get to http://mainapp and http://altapp.xyz.local without either prompting (assuming both are DNS reachable and in Local Intranet Zone), without extending a web app, using host headers as I am?

    Tuesday, August 06, 2013 1:47 AM
  • If you are going to use two different host headers then the only supported way to get them both working is by extending the web app.  The only reliable way to do two host headers on a single web app without an extended one is if the two host headers are the netbios name and FQDN form of the same name.  ie http://mainapp and http://mainapp.xyz.local.  To do what you want you are going to need to extend the web app.  I've seen it work occasionally, but its not supported and its not reliable. 

    Your other choice is to get rid of the host headers and bind in IIS based on custom IP address or port number only.  Since I assume you are using port 80 that will only work if you implement custom IP addresses for all web apps or if there isn't another web app on port 80.


    Paul Stork SharePoint Server MVP
    Principal Architect: Blue Chip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Tuesday, August 06, 2013 11:28 AM
  • Ok, I just removed the manual second AAM (altapp.xyz.local), and then extended the Web App, putting in altapp.xyz.local in the host header field, put the new site on port 80 as well, and put it in the Internet Zone.

    It created the binding automatically under it's own new IIS site, and created the Public URL automatically.  However, when I then tried to go to http://altapp.xyz.local, I got the prompts again followed by a 401.  Also, I suddenly got Access Denied on the normal http://mainapp (no prompts, just an Access Denied error message and the url was http://mainapp/_layouts....).  I removed the extended app and IIS site for the altapp, ran iisreset after that and was still getting Access Denied on normal web app.  Then, I reset the cache super user accounts and ran iisreset again, and still access denied...so I'm trying to fix that now.

    Should I not be extending the web app into the same port 80?  I don't want the users to have to type in a Port number in the URL.  Also, any clue on what I broke for access on all users by extending the app?

    Tuesday, August 06, 2013 8:09 PM